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-19, 19:12   Link #821
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 29
The container is responsible for "lining up" the frames of the various data, effectively timestamping them. If the container isn't aware of the timestamps of all the individual streams they can't be laced properly, and you might get cases where the audio is out of sync with the video. (I believe this is one of the problems with VBR audio in AVI.)
Another case where the container needs timestamps will be seeking. That operation depends heavily on the splitter-component in a playback solution, since the splitter will need to fetch data from all the different streams. If you seek forward to some timestamp (not frame number), how would the video decoder know which frame to get from the video if it couldn't ask the splitter to get the right frame for a given timestamp? Only by streaming the entire video stream until it got the right frame. The splitter is able to do that much more effectively.

Having things such as timestamps (and perhaps even absolute frame numbers) abstracted away can also greatly simplify the implementation of a decoder, again since it needs to care about less data then. You just push a compressed frame in and get an uncompressed frame out. Sometimes you need to push several compressed frames in before you can get one decoded frame out however (B-frames.) This is another shortcoming of AVI, Video for Windows assumes that one frame sent to the decoder results in one frame coming out of the decoder.


On containerless MPEG-4 ASP, I think it should be possible, but containerless video doesn't seem very attractive to me.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-05-20, 03:56   Link #822
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
Quote:
Originally Posted by Starks View Post
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?
1) It can be either; MPEG-1, MPEG-2, MPEG-4 Visual (including ASP) and H.264 store a framerate of some description in the bitstream, but it seems when you do specify a framerate/duration for a container, it overrides the framerate in the bitstream.

2) Yes, raw ASP can be encoded, and whats more encoded the way it's supposed to be (as opposed to being fucked up to compensate for AVI's limitations). In fact if anyone was going to encode ASP, I would recommend it. All you need is xvid_encraw and xvidcore.dll
Encraw - http://forum.doom9.org/showpost.php?...&postcount=637
XviDcore - http://ffdshow.faireal.net/mirror/XviD/

May or may not be of interest, but some of the earlier mobile phones and portable devices support ASP + AAC in MP4 or 3GP (MP4Box also muxes to 3GP); so if battery life is a concern, SP or ASP should do the trick at the expense of filesize.
__________________
Zero1 is offline   Reply With Quote
Old 2007-05-23, 12:16   Link #823
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 26
Send a message via AIM to Starks
Quote:
Originally Posted by Zero1 View Post
1) It can be either; MPEG-1, MPEG-2, MPEG-4 Visual (including ASP) and H.264 store a framerate of some description in the bitstream, but it seems when you do specify a framerate/duration for a container, it overrides the framerate in the bitstream.
Doesn't that indicate that the video formats do not natively support VFR through normal encoding means?
__________________
Starks is offline   Reply With Quote
Old 2007-05-23, 14:28   Link #824
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 29
A video compression codec could and should not care less about framerate, it just encodes a sequence of images in an efficient way. Any kind of framerate stored in the raw bitstream would be pure convenience for anyone crazy enough to attempt playing the bitstream. But in the end, a video codec is just something that takes sequential images as input and produces a compressed sequence of the images as output. Timing of the display of those images is left to another component in the system.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-05-26, 09:51   Link #825
zrdb
I'm Under Arrest!!
 
 
Join Date: Nov 2004
Location: Huh? Didn't know I had to be somewhere.......
Send a message via Yahoo to zrdb
First off-I'm not an encoder, although I have dabbled in it. I recently did an encode of a series I resubbed myself-the originial Dirty Pair tv series which was encoded from R2 dvds with some existing subs and some of my own. I first tried it in xvid with a file size of 250 to 300 megs keeping the ac3 audio then switched to h.264-same file sizes-video was about 30% better. I used the matstroka format. When I download fansubs if given the choice I almost always get the h.264 encodes-one thing I do that a lot of other people might not is convert them to mpeg2 dvds. H.264 almost always gives better results than xvid/divx. Again the skill of the person doing the encoding is very important.
__________________
Anime is ok-but you've gotta have time to live, too.
zrdb is offline   Reply With Quote
Old 2007-06-01, 13:01   Link #826
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
I heard it on the grapevine that PS3 now supports High Profile H.264 with firmware 1.8, but the question is, can anyone verify this? (Seems like they want to better MS' 360)

Also, though it goes without saying, please post any limitations you come up against (such as the firmware not supporting full High Profile, or just certain tools).
__________________
Zero1 is offline   Reply With Quote
Old 2007-06-01, 18:03   Link #827
Nicholi
King of Hosers
 
Join Date: Dec 2005
Age: 31
The grapevine (doom9) told me it only works when muxed into m2ts. I'm guessing you haven't read that thread? And as they say the only known m2ts muxers are commercial junk, so probably proprietary as all shit and someone would have to RE it to be in any opensource/free software ;-;.

You don't happen to live in California do you Zero1 ?
Nicholi is offline   Reply With Quote
Old 2007-06-02, 16:55   Link #828
xat
Senior Member
*Fansubber
 
Join Date: Dec 2005
Quote:
Originally Posted by Zero1 View Post
I heard it on the grapevine that PS3 now supports High Profile H.264 with firmware 1.8, but the question is, can anyone verify this? (Seems like they want to better MS' 360)

Also, though it goes without saying, please post any limitations you come up against (such as the firmware not supporting full High Profile, or just certain tools).
I've not heard this being the case. What has happened in recent time, though, is Red Kawa released an update to their transcoder (PS3 Video 9) that enables high profile avc/mkv videos to be simply remuxed into an mp4 with no video re-encoding (audio is transcoded to AAC). I'm assuming it then alters the profile flag within the bitstream to be interpreted as main@4.1.
xat is offline   Reply With Quote
Old 2007-06-02, 17:04   Link #829
martino
makes no files now
 
 
Join Date: May 2006
Nice to hear that, and what about timecodes? I doubt that it takes those into account when remuxing the stream from MKV to MP4, well, just a thought here on my side...
__________________
"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-06-02, 17:16   Link #830
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
So what we're saying is that it can play high profile H.264 if it's muxed as a transport stream, but for MP4, it only supports main profile (lol, GJ Sony, you can already decode the fucking streams, why not allow people to do so?), and we suspect the transcoding program modifies the H.264 bitstream to say it's main profile when it's really high profile, thus tricking the PS3?

If this is the case, then it really is lame sauce and Sony need to fix it.

Well I recall something about the PS3 not playing most x264 encodes because by default it tags as 5.1, but I wasn't aware of the profile trickery.

And to Nicholi: No, I didn't see that branch, it was somewhere else on the grapevine.
__________________
Zero1 is offline   Reply With Quote
Old 2007-06-02, 17:26   Link #831
xat
Senior Member
*Fansubber
 
Join Date: Dec 2005
Yeah I'm not quite sure why Sony's having the PS3 handle 4.1 exclusively. It's definitely capable of handling high profile (at very, very high bitrates at that), so I don't understand what the fuss is.

While Sony is at it they should natively support MPEG-4 ASP since that currently can't be handled without transcoding via DLNA.

Quote:
Originally Posted by martino View Post
Nice to hear that, and what about timecodes? I doubt that it takes those into account when remuxing the stream from MKV to MP4, well, just a thought here on my side...
I don't know the answer to that one myself. I'm assuming they do; don't MP4s mux erroneously (slightly shorter playback time) without timecodes provided by MKV?
xat is offline   Reply With Quote
Old 2007-06-03, 08:52   Link #832
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 26
Send a message via AIM to Starks
Just out of curiosity.

How many people here use Trellis 2 more than they use Trellis 1?
__________________
Starks is offline   Reply With Quote
Old 2007-06-03, 09:33   Link #833
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
I always use trellis 2
__________________
Zero1 is offline   Reply With Quote
Old 2007-06-03, 09:46   Link #834
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 26
Send a message via AIM to Starks
Quote:
Originally Posted by Zero1 View Post
I always use trellis 2
Any particular reason?

How much does it slow down your encoding as compared to trellis 1?
__________________
Starks is offline   Reply With Quote
Old 2007-06-03, 10:30   Link #835
martino
makes no files now
 
 
Join Date: May 2006
I use trellis 2 as well, but then I run most encodes overnight and generally don't care too much about the speed as long as it doesn't go lower than 1.4 fps for a 704x400 encode (from filtered lossless).

I don't know by how much it slows it down, but just by looking at how slow x264 is, I doubt it would be enough to make a big difference (or at least to me anyway)...

Quote:
Originally Posted by xat
I don't know the answer to that one myself. I'm assuming they do; don't MP4s mux erroneously (slightly shorter playback time) without timecodes provided by MKV?
I'll give it a try. Depending on the timecodes, but generally yes if the stream is assumed to be at 29.97 with some sections at 23.976, then if those get muxed as 29.97, then it will be shorter.
__________________
"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-06-03, 12:00   Link #836
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 27
Trellis 1, usually. Last time I used trellis 2 was on a 2 hours long live-action movie that took something like 28 hours to encode, and since then I don't use it except in special cases... (those 85 MB Night Head Genesis encodes was one such case)
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2007-06-03, 12:28   Link #837
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
I did some trellis testing long ago, and if I recall it was around a 2% bitrate savings between trelllis 1 and trellis 2.

That's about equivalent to using 8 reference frames instead of 4. But that's savings on TOP of the reference frame savings. It's goddamn slow, though.

I always use it. But I have a fast newish core 2 duo.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-06-03, 14:33   Link #838
Yumi`
Frame burner
 
 
Join Date: May 2007
On a filtered lossless source, I got a 3% compressibility win (crf20) at a speed loss of 28%. Still reasonable for me so I always use it.
Yumi` is offline   Reply With Quote
Old 2007-06-03, 14:41   Link #839
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
Quote:
Originally Posted by Starks View Post
Any particular reason?

How much does it slow down your encoding as compared to trellis 1?
I don't know, I don't go light on options for the sake of speed. A current encode I'm doing on my laptop (A64 TL60 2x2GHz, roughly equivalent to a 3800) goes around 2fps from a Lagarith. It's painfully slow, but knowing I'm getting such efficiency/quality makes it that bit more bearable.

I was actually testing threading earlier for a friend; he has written a simple x264, Nero and MP4Box GUI, and I PMed him some suggestions, one of which was to add a dialog that notifies the user that higher quality can be obtained if multithreading is not used. Naturally he asked me how much effect does it have, to which I answered, "I don't know, lol".

So I did a couple of unscientific short tests.

First test was a 60 second clip of Elephants Dream (which is a CG fanmade movie, and the source is 1920x1080 PNGs, yum), downscaled to 712x400 and cropped to 704. Both clips were encoded at Q18 or Q20 (I forget which, and the files are long gone)
Code:
01/06/2007  20:56        24,454,753 1thread.264
01/06/2007  20:33        25,413,163 threadsauto.264
So what we see here is ~935KB "loss" (or gain depending on how you look at it) depending on whether threading is used or not. For the record, I understand that --threads auto is CPUs*1.5 (so 3 threads were used). This translates to roughly 4%.

I was also doing some ME range testing on said source, and was not satisfied with the results, so I turned to anime DVD source, and I decided to test threading again. It is 704x480, 3m 38s long and full of high motion.
Code:
03/06/2007  20:22        60,642,355 q18.264
03/06/2007  20:22        63,219,458 q18-threads2.264
03/06/2007  20:23        63,369,783 q18-threads4.264
As I expected, there was a notable loss in using threads, and the loss becomes slightly greater the more threads you use. This time it's 57.8MB vs 60.3MB, which coincidentally is around 4% again.

So, does anyone feel like testing to see if the 4% holds true as a ball park figure? How about with fairly relaxed or insane settings for a full episode? If the 4% does hold true as a guide (as we use 10% gains for using CABAC over CAVLC as a guide), are you quite happy to take the hit for the speed gains (remember, the speed gains can be quite significant over using a single core), or would you simply thread input and have x264 encode on one thread and AVISynth decode on the other?
__________________
Zero1 is offline   Reply With Quote
Old 2007-06-03, 16:20   Link #840
xat
Senior Member
*Fansubber
 
Join Date: Dec 2005
What about quality difference between threads by the number (SSIM,PSNR)? Although I suppose it's a moot case since there really shouldn't be much of a perceivable difference.
xat 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 06:32.


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