Log in

View Full Version : Video track demuxed by eac3to is not identical to tsmuxer and xport output


PowerGamer
11th January 2010, 21:12
I have done some testing with demuxing video tracks from .m2ts files from a few Blu-ray disks: main movie track from Tinkerbell, largest bonus film from the same disk and Mike's New Car from Pixar Short Films Collection. All video was in h264/AVC, 1080p24 /1.001 format. Each video track was demuxed by each of the following programs: eac3to, tsmuxer, xport, Blu-Ray Demuxer Pro (http://dvd-logic.com/bddemuxerpro.php). Files produced by last 3 programs were byte-identical. In case of Mike's New Car eac3to also produced the same byte-identical .h264 video file. But in case of two other movies eac3to produced different video files:

Tinkerbell main movie:
eac3to file size: 16 845 863 552 bytes
other programs: 16 876 200 309 bytes
bytes start to mismatch at 000EC3FC offset.

Tinkerbell bonus movie:
eac3to file size: 1 361 242 778 bytes
other programs: 1 362 859 162 bytes
bytes start to mismatch at 00000D98 offset.

Why eac3to video output is not byte-identical to the output of other programs in 2 out of 3 cases? Is there some bug in eac3to that produces incorrect video output?

setarip_old
12th January 2010, 02:20
Hi!

You'd probably fare better, regarding responses, if you request that a moderator move your thread to the"Audio" sub-forum here...

Ghitulescu
12th January 2010, 09:08
.... a moderator move your thread to the"Audio" sub-forum here...

You are the first to mention the word AUDIO in this thread :confused:

setarip_old
12th January 2010, 09:17
@Ghitulescu

Numerous references to "eac3to" (Primary thread for which is in the "Audio" sub-forum), and/or senility, I guess...

Ghitulescu
12th January 2010, 09:28
Returning to the OT:

I assume that (it's my assumption, not a fact) some streams are padded with NULL packets to artificially increase the bitrate (maybe to prevent buffer underflow, you know like Min Bit Rate in encoders); so some demuxers get rid of the useless packets, some others do keep them in.

Try to run the bigger files through a "Packet cleaner" (makeMKV, the other demuxers etc.) and you'll end, if I were correct, with the same length.

PowerGamer
12th January 2010, 22:41
After googling out http://akuvian.org/src/x264/ITU-T_H264.pdf.gz I determined what is the difference between eac3to video file and video file of other programs. Apparently eac3to have removed all NAL units that contained filler data RBSP (upon removing those NALs from video file demuxed by tsmuxer/xport/Blu-rayDemuxer the result become byte-identical to the eac3to output).

That answers the question I asked when I created that thread but rises another question that probably will be better to ask in another subforum: http://forum.doom9.org/showthread.php?t=152051