File is too big to attach, please get from http://foolip.org/gst/hanoi.m2ts and put on http://gstreamer.freedesktop.org/media/ if you want to keep it forever.

Playing this file in Totem, editing it with PiTiVi or e.g. using a decodebin(2) pipeline seems to cause mpegtsdemux to be used. mpegtsdemux sets the "audio/x-eac3" caps for the audio stream, which is only handled by ffdec_eac3. However, ffdec_eac3 is dropping the beginning of the audio which causes the whole thing to out of sync about 500ms (crushing my dream of using PiTiVi for this).

The following pipeline works: gst-launch filesrc location=hanoi.m2ts ! ffdemux_mpegts name=demux ! queue ! ffdec_h264 ! ffdeinterlace ! ffmpegcolorspace ! autovideosink demux. ! queue ! ffdec_ac3 ! audioconvert ! autoaudiosink

Decoding is too slow, but if you use a similar pipeline to transcode into e.g. Ogg, the resulting file is in sync.

Now, I've debugged a bit in gst-ffmpeg when using ffdemux_mpegts, stepping through these lines in ac3_parser.c:

    if(hdr->bitstream_id <= 10) {
        /* Normal AC-3 */
...
    } else {
        /* Enhanced AC-3 */

For this input, the Normal AC-3 path is taken (hdr->bitstream_id was 4). The net result is that 

mpegtsdemux, however, identifies it as audio/x-eac3 around gstmpegtsdemux.c:731 This causes ffdec_eac3 to be used, which for whatever reason chops off the beginning of the stream as described above.

I don't know if this really is an E-AC3 stream and if it happens to be a valid AC3 stream at the same time. As far as I can tell, the real bug could be any of:

1. FFMPEG's E-AC3 decoder is broken
2. mpegtsdemux isn't sending all the data needed to ffdec_eac3
3. this is really an AC3 stream and we mpegtsdemux needs to inspect the stream more closely before deciding between audio/x-ac3 and audio/x-eac3
4. ffdemux_mpegts should have higher rank than mpegtsdemux

If mpegtsdemux is "fixed" as in my "patch", gst-launch filesrc location=hanoi.m2ts ! mpegtsdemux name=demux ! queue ! ffdec_ac3 ! audioconvert ! autoaudiosink also cuts of the beginning of the sound. It really looks like mpegtsdemux isn't sending the whole stream, or something.

Created attachment 150759 [details] [review]
this is not a real patch, just to show exactly what I did to make it possible to link mpegtsdemux with ffdec_ac3 for this particular file

isn't this a dup of Bug #605904 ?

No, that bug is about *not* detecting when it should be, while this is about something that looks like E-EAC3 but should really be decoded by ffdec_ac3, it appears. I tried the latest git including the fix for #605904 to confirm that the problem remains.

Review of attachment 150759 [details] [review]:

Rejecting since this isn't a serious patch.

Update: Further debugging seems to indicate that the real bug is 2. mpegtsdemux isn't sending all the data needed to ffdec_eac3

If I tweak the caps to allow linkage, this pipeline drop the beginning of the audio:

gst-launch -v filesrc location=hanoi.m2ts ! mpegtsdemux name=demux ! multiqueue ! ffdec_ac3 ! autoaudiosink

This one however, does not:

gst-launch -v filesrc location=hanoi.m2ts ! ffdemux_mpegts name=demux ! multiqueue ! ffdec_ac3 ! autoaudiosink

The decoder is the same and the only difference is the demuxer, so I'm guessing mpegtsdemux isn't delivering the same data as ffdemux_mpegts.

Can some change the title of the bug accordingly, and set the bug to confirmed?

Do you know what's difference in the output of ffdemux_mpegts? Does this also fail with the new mpeg ts demuxer (tsdemux) in gst-plugins-bad?

works fine with tsdemux. Shall we close this ?

> works fine with tsdemux. Shall we close this ?

We should close it once it's handled fine by decodebin/playbin2 with whatever element gets autoplugged IMHO.

Setting to NEW as we apparently haven't reached the FIXED state yet and there's no open non-developer issue.

Works fine with playbin2/totem and tsdemux. Closing