AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2007-05-12, 01:23   Link #801
checkers
Part 8
*IT Support
 
 
Join Date: Jul 2006
Location: Western Australia
Age: 26
Send a message via MSN to checkers
Well really, CPUs aren't going to get that much faster, there are just going to be more of them. Threading optimisations I would expect to be platform independant.
checkers is offline   Reply With Quote
Old 2007-05-12, 07:34   Link #802
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
Quote:
Originally Posted by checkers View Post
Well really, CPUs aren't going to get that much faster, there are just going to be more of them. Threading optimisations I would expect to be platform independant.
True, although I didn't mean faster MHz terms alone, I mean faster on the whole by any means be it more cache, more cores, new instruction sets or whatever, as opposed to the Cell which is not upgradable and a few years down the line, it will start to pale in comparison with some CPUs (I guess, I don't know much about the Cell or how "advanced" it is, so take that with a pinch of salt).

Threading optimisations may benefit regardless of platform, but I think anymore than that is a waste of time IMO (eg. specially recoding parts to make better use of Cell, when that time could be spent tweaking other aspects - as you know pengvado and the other devs are all very busy).

Basically what I'm saying is that I don't think it's worth the time rewriting parts of the program specially for a machine that will never get any faster, whereas optimisations for x86 etc will benefit people now, and down the line in years to come.

It may even be a simple job, then again it may require almost a complete rewrite; programming not my area so I can't and won't say. If it is a small job, then I guess you might as well, but I can't see the point in investing a decent amount of time for the PS3, unless it really is head and shoulders above any CPU out there currently.

I wish we could have faster cores instead of just more though :/ There is only so much you can do with multithreading.

I did come across a Japanese site once with encoding results for Cell; does anyone have the site out of interest?
__________________
Zero1 is offline   Reply With Quote
Old 2007-05-12, 07:50   Link #803
martino
makes no files now
 
 
Join Date: May 2006
Quote:
Originally Posted by Zero1 View Post
I did come across a Japanese site once with encoding results for Cell; does anyone have the site out of interest?
Do you mean the link from this post that xat posted?

EDIT: Actually, I think I've seen another site than that, but they were using mencoder. I wish I could find it now, it was quite interesting.
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"

Last edited by martino; 2007-05-12 at 08:01.
martino is offline   Reply With Quote
Old 2007-05-12, 10:31   Link #804
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
Yes, that's the one, so thanks to xat for that. Didn't mean to claim it as my find; I forgot that xat had linked to this site, but I came across it at doom9 the other day when I was just checking stuff out:
http://forum.doom9.org/showthread.ph...012#post997012
__________________
Zero1 is offline   Reply With Quote
Old 2007-05-12, 12:22   Link #805
Eeknay
Gendo died for your sins.
*Fansubber
 
 
Join Date: Dec 2005
Was fooling aroud on AVSForum and saw this thread and this post. High bitrate HD h264 caps without modification seem to play straight off. Interestingly m2ts works as well so any decrypted AVC/MPEG2 BD could be whacked on there or a network drive and play fine. But VC1 doesn't. :/ Someone in the thread mentions a post by a support dude saying that MKV could be implemented and work, but on another model. (No ASS support either but SRT is there of course)

Only somewhat relevant but I thought it was nice to see these sorts of things start to hit the market.
Eeknay is offline   Reply With Quote
Old 2007-05-12, 14:05   Link #806
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Aha!

One mystery is solved. From the mouth of akupenguin himself (the author of x264 (mostly)):

http://forum.doom9.org/showthread.ph...577#post996577

So, whereas Zero1's chart about profiles and levels above seems to be true, it seems like there are "certain restrictions" to where and how p4x4 blocks can be used which x264 does NOT check for. That's why megui doesn't let you set the level to 4.1 AND set p4x4 macroblock searching on at the same time. It's more about the specific workings of x264 than the standard itself.


Which is crappy news, since all my previous encodes used that feature . Well, we'll just need to see if this is more a precaution about extreme circumstances or one which is not really the case. More info is needed.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-05-12, 17:07   Link #807
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
Well I know I always bang on about doing things to spec, but I don't see why a player would refuse or have problems playing back a level 4 encode using p4x4, if the player is supposedly capable of HP@4.1.

I'm sure there is good reason to it, perhaps just stops the video getting that little bit too complex in the higher levels when the bitrates start to rocket; but for the purpose of fansubs that use a low bitrate in comparison to what 4 and 4.1 cover; I don't see why it should be an issue. IMO it's not breaking spec to play such a file, merely bending. After all, you are telling the player that it's high profile and uses features X, Y and Z, and is level 4 which supports up to A x B resoltion at C frames per second.

Well to put it another way, I don't think (or hope) that hardware players will be intelligent enough to think, "This looks like a level 4 encode but has p4x4, therefore I won't play it"

For instance it implies that up to level 3 may have p4x4, but level 3.1 may not. Now one of the differences between level 3 and 3.1 is bitrate; 10mbps vs 14mbps max respectively. Are you telling me that a hardware player will play a 720x480 encode with p4x4 if the bitrate is no higher than 10mbps, but suddenly becomes allergic to it if the bitrate is 14mbps, despite the fact that the player is capable of 20mbps (or 50mbps for level 4.1) at 1080p? I don't think so.

If you have two identical encodes both using p4x4 but only bitrate being the difference, then in theory one should play and one should not. The only way the player would know would be the level specified in the bitstream, but if those were purposely set the same, it would not know; so in this case I think it has to try and decode it or not regardless of level specific limitations on encoding tools/features.

I think taking the profiles and levels so seriously as to make a player refuse certain encodes because of what it says in the bitstream is silly. They should be used as a guide as to what the software or hardware is capable of, and as a guide as to the complexity or features used/required by an encode, but not to restrict encodes that the player may be perfectly capable of.

If you ask me, it's a stupid grey area. Profiles should define the tools and levels the complexity of the scene; not mixing both by saying, "Well if this encode is such a bitrate, you aren't allowed to use this partition type, but under that bitrate is fine". Maybe I'm far out on that, but that's my opinion right now.
__________________
Zero1 is offline   Reply With Quote
Old 2007-05-12, 18:24   Link #808
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Zero1 View Post
Well I know I always bang on about doing things to spec, but I don't see why a player would refuse or have problems playing back a level 4 encode using p4x4, if the player is supposedly capable of HP@4.1.

I'm sure there is good reason to it, perhaps just stops the video

... blah blah blah (long Zero post)
Well, no need. I've been reading the official h.264 specs (more like, decoding them), and have gotten the official answer from akupenguin himself:

http://forum.doom9.org/showthread.php?t=125734

To translate the answer so non super nerds can understand it, basically there is a limit of 16 total motion vector calculations per 2 consecutive macroblocks for level 3 and HIGHER. That seems backwards, with the higher levels being more restrictive, but that's what's in the specs, read 'em for yourself.

Right now, x264 doesn't check for this issue when encoding at all. So, for example, say you have 2 p4x4 blocks in a row. That's 16+16 = 32 total subblocks, which each could theoretically have a motion vector needed to be calculated for it. Of course, some of the sub blocks could be skip blocks (i.e. no mv needed), so it's not like every sequence of 2 p4x4 macroblocks would violate the spec. Plus, even a p8x8 followed by a p4x4 could violate it (16+4 = 20).

But, like akupenguin said, this is more a total calculation burden issue, and since p4x4 is so rare it amortizes over the entire frame, i.e. in the real world going over this limit wouldn't affect total decoding time much. But technically it WOULD violate the level specs.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-05-12, 23:19   Link #809
xat
Senior Member
*Fansubber
 
Join Date: Dec 2005
Quote:
Originally Posted by Zero1 View Post
I don't know about you guys, but I'd prefer to see more quality tweaks and x86 optimisations before wasting time with PS3.

PS3's hardware will never change, so you are stuck with a set CPU speed; however with a nice optimised x86 build, CPUs are always getting faster and you will feel the improvements for years to come.

I also doubt you will get the full potential of the PS3 too, since Sony seem to like locking down their hardware.
It's probable that we'll never get GPU access. What we do have access to, however, is the SPEs and the PPE - those are core to decoding h264 content through the PS3, and are the ones that can be harnessed for (potentially a lot of) encoding performance. It hasn't really been done yet, and that Japanese x264 site/blog does detail the first happenings in that area. I agree the optimizations for this should be done by an independent or otherwise dedicated group (rather than the actual devs), but I also think there's the possibility for Cell to seriously surpass the performance of today's (and possibly the future's) general purpose CPUs -- in the kinds of calculations dealt with in encoding and the like, anyway. I'm sure there are exceptions.

The problem is how to get there. To my understanding, the cell requires a bit of a different philosophy to program for, stressing throughput over simplicity (in code). See here:
Quote:
On a Pentium 4 HT running at 3.4 GHz, this algorithm is able to check 24-million edges per second. On the Cell, at the end of our optimization, we achieved a performance of 538-million edges per second. This is an impressive result, but came at the price of an explosion in code complexity. While the algorithm in Listing One fits in 60 lines of source code, our final algorithm on the Cell measures 1200 lines of code.
I'd hate to have to maintain that.
xat is offline   Reply With Quote
Old 2007-05-15, 04:35   Link #810
martino
makes no files now
 
 
Join Date: May 2006
Recently I became somewhat interested in the ISO standard, and I'd quite like to know whether VFR MP4 files can be played on standalone devices, like the XBOX360, PS3 and so on. Therefore I have encoded one of the files that were lying around on my drive. Here's the link to it. It contains a read me file too.

I'd be really glad if someone could try that out on their device. So far it has been reported to play correctly in QuickTime under Mac OS. Unfortunately there was a misunderstanding between me and the person who tested it, where I thought that he had an AppleTV. However he said that as Apple claims, that whatever plays in QT works in iTunes and AppleTV too, so I'll just take his word for it then...
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"
martino is offline   Reply With Quote
Old 2007-05-15, 04:47   Link #811
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Quote:
Originally Posted by martino View Post
Recently I became somewhat interested in the ISO standard, and I'd quite like to know whether VFR MP4 files can be played on standalone devices, like the XBOX360, PS3 and so on. Therefore I have encoded one of the files that were lying around on my drive. Here's the link to it. It contains a read me file too.

I'd be really glad if someone could try that out on their device. So far it has been reported to play correctly in QuickTime under Mac OS. Unfortunately there was a misunderstanding between me and the person who tested it, where I thought that he had an AppleTV. However he said that as Apple claims, that whatever plays in QT works in iTunes and AppleTV too, so I'll just take his word for it then...
I can tell you yes without even trying it. From how I understand it, mp4 files store a timestamp with each frame, as opposed to having a list of framerates.

Framerate is actually a derived quantity for mp4s, and not stored directly anywhere (except for the header, but that's mainly for show, and isn't used in playback).
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-05-15, 20:18   Link #812
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 31
You wouldn't very well be able to make a compliant file if the standard didn't allow it :P. I think its quite obvious if the standard was implemented fully it should play the file. The question is, does it in fact work? Was the standard implemented correctly and fully or not? Though I would like to live in a perfect world where everything is done to standard, I find it more fun to know if it actually does work n_n. I've yet to see someone other then fansubs and hobby'ists work with and test VFR content as well :P. Its not as though mistakes are impossible by "the industry".

Not that I have any reasoning or theory as to how someone could support MP4 without looking at each frame's timestamp, but we've seen other standards deviated from quite easily.
Nicholi is offline   Reply With Quote
Old 2007-05-16, 15:34   Link #813
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
Quote:
Originally Posted by Nicholi View Post
BAAAAAWWWWWWWWWWWWWWWWW


However, I don't blame Nicholi for being sceptical on this occasion. You know what they say, "Around Macs, never relax."

So earlier I encoded a low res VFR MP4, and tested it on a 5th gen 30GB iPod. The verdict was that it played perfectly. I was somewhat surprised, not that the fact it played fine with the VFR, but the fact it played fine when it was hitting 1800kbps in parts. I thought the max bitrate for iPod was something like 768/1500kbps (never looked into it because portables wasn't something that interested me).

I think what Quarkboy was trying to explain is that if a device can play CFR MP4, then due to the structure of the format, it automatically qualifies as VFR capable too since to play the CFR it grabs the timestamp for each frame and holds it for said duration; the only difference with a VFR video being that these timestamps can be different for each frame, so rather than the parser reading the timestamps and holding all frames for the same duration, it reads the same timestamps and holds them for varying durations. In other words, VFR doesn't require any additional support, it's basically covered within the ability to read MP4 files or timestamps.

I think next I'll find someone with a PSP. If anyone can screw up anything, it has to be Sony in recent years.

On another note, although the idea of using Baseline profile pains me just to think I am losing out on CABAC and B-frames, one thing that softened the blow is that I found my Baseline H.264 encodes were still smaller than your regular XviD/MPEG-4 ASP (yes, B-frames) encode at Q18/Q2 respectively. I suppose it shouldn't be too surprising, but I wasn't quite sure what to expect.
__________________
Zero1 is offline   Reply With Quote
Old 2007-05-16, 20:31   Link #814
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 31
Quote:
Originally Posted by Zero1 View Post
I think what Quarkboy was trying to explain is that if a device can play CFR MP4, then due to the structure of the format, it automatically qualifies as VFR capable too since to play the CFR it grabs the timestamp for each frame and holds it for said duration; the only difference with a VFR video being that these timestamps can be different for each frame, so rather than the parser reading the timestamps and holding all frames for the same duration, it reads the same timestamps and holds them for varying durations. In other words, VFR doesn't require any additional support, it's basically covered within the ability to read MP4 files or timestamps.
Quite well aware of how the nature of timestamps and frames work in MP4. Its the same generalization in MKV. There is no stored framerate/fps for the entire video but simply timestamps for each frame. But like I said we've seen so many other things deviated from quite easily in many places. Quicktime? Hello half-working Main/Baseline Profile! Whats that...you'll fix the decoder in a few years when the next update comes out, ok!

We can obviously glean from looking at the standards what should be working, but by no means should that be the answer to the questions asked. What Quarkboy answered to me just sounded like circular logic. "1: Can VFR MP4 files be played? 2: How did you make them? 1: By following the standard. 2: Then you can play them because its in the standard." That should have been obvious in my opinion. Variable framerate MP4s are not something created outside of the standard, they are an inherent part of it.

Good to hear it works in iPod at least. I would only assume other Apple products it is likely working as well then. I would rather like to know if the knew Xbox360 update with MP4 support works with them. I braww at joo Zero!
Nicholi is offline   Reply With Quote
Old 2007-05-16, 20:39   Link #815
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Nicholi View Post
Quite well aware of how the nature of timestamps and frames work in MP4. Its the same generalization in MKV. There is no stored framerate/fps for the entire video but simply timestamps for each frame. But like I said we've seen so many other things deviated from quite easily in many places. Quicktime? Hello half-working Main/Baseline Profile! Whats that...you'll fix the decoder in a few years when the next update comes out, ok!

We can obviously glean from looking at the standards what should be working, but by no means should that be the answer to the questions asked. What Quarkboy answered to me just sounded like circular logic. "1: Can VFR MP4 files be played? 2: How did you make them? 1: By following the standard. 2: Then you can play them because its in the standard." That should have been obvious in my opinion. Variable framerate MP4s are not something created outside of the standard, they are an inherent part of it.

Good to hear it works in iPod at least. I would only assume other Apple products it is likely working as well then. I would rather like to know if the knew Xbox360 update with MP4 support works with them. I braww at joo Zero!
Well, my point was more this:

For them to NOT support VFR would seem to me to take MORE work than for them to support it. Since I always assume the hardware people do the least work possible, it would be very surprising to me if it didn't work.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-05-16, 20:48   Link #816
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 31
Quote:
Originally Posted by Quarkboy
For them to NOT support VFR would seem to me to take MORE work than for them to support it. Since I always assume the hardware people do the least work possible, it would be very surprising to me if it didn't work.
Indeed, as I said in my original post I didn't really have any idea how someone could in fact not support VFR while supporting the format. It would be rather strange. They are rather lazy though as you said, and going for the path of least resistance is usually what they do . I still think it would be a good idea to actually test said implementation rather then saying "I can tell you yes without even trying it."
Nicholi is offline   Reply With Quote
Old 2007-05-16, 21:09   Link #817
checkers
Part 8
*IT Support
 
 
Join Date: Jul 2006
Location: Western Australia
Age: 26
Send a message via MSN to checkers
Quote:
Originally Posted by Quarkboy View Post
For them to NOT support VFR would seem to me to take MORE work than for them to support it.
What would be hard about reading the first timestamp and using that for every subsequent frame?
checkers is offline   Reply With Quote
Old 2007-05-16, 22:00   Link #818
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Quote:
Originally Posted by checkers View Post
What would be hard about reading the first timestamp and using that for every subsequent frame?
Well, you'd need to read at least _2_ timestamps, right? You can't get a rate without two points to take a discrete derivative of.

Well, this is a moot point to argue over my certitude. If I had any of those devices I would love to try them out . I was just saying that I wouldn't lose sleep over it.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-05-19, 09:23   Link #819
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
Well today my Nokia N95 arrived, and naturally I wanted to put it through it's paces.

First test was to download and playback a "portable" fansub. Well actually it was a 5 minute promo, but length is irrelevant, especially since this was so high motion (to give you some indication, the original is about 57MB including ~100kbps VBR audio for an insane settings x264 encode at 704x480. The average P-frame was Q19).

This was the same VFR MP4 that played on the iPod fine, and it plays on the N95 fine. In fact fine is being generous. Despite it peaking at 1900kbps, there wasn't any sign of lag. 1900kbps is perhaps not much of a feat, but it exceeded my expectations from a phone.

Also the LCD is pretty awesome. If I could get one like this in 24" at something like a sensible price, I'd be tempted to kick my CRT into touch.

I suppose the next test will be to see if it supports main profile. Who knows; but again, I'm not expecting much.

It's pretty neat to be able to connect to a WLAN, browse the intarwebs, download and playback a video - although the ability is there; I don't think portable fansubs will happen (but seeing how some people are content with YouTube's shitty quality, anything is possible). I just love gadgets and stuff

Edit:
Just thought I'd throw in that I found a couple of opensource IRC and Bittorrent programs for it - of course it'll probably slay your battery (although I have two), but I thought it was cool anyway.

Main profile (or at least a baseline encode + B-frames and CABAC) did not work. There is another media player called SmartMovie (which I had on my old 6260) which plays MPEG-4 ASP in AVI (the old XviD AVI's we had for so long); so it'll be interesting to see if this has enough in it to play a good old 640x480 XviD encode. I may just download one using the BT client too
__________________

Last edited by Zero1; 2007-05-19 at 13:24.
Zero1 is offline   Reply With Quote
Old 2007-05-19, 18:16   Link #820
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 26
Send a message via AIM to Starks
I have two questions.

1. Why is framerate reflected in the container rather than in the video stream component?

2. Is it possible to create a raw MPEG-4 ASP stream or is bound to the container?
__________________
Starks is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 05:37.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
We use Silk.