GNOME Bugzilla – Bug 675866
[0.10] playbin2 doesn't preroll with a certain mkv with truehd or dts audio es
Last modified: 2013-04-20 20:25:14 UTC
ftp://test4711:test4711@82.149.226.170/Super8_part.mkv this file won't preroll when trying to play it with playbin2 with git or 0.10.36 cf. to slomo neither with 0.11
i have a feeling the problem is not the truehd audio stream but rather the dts one. i have another file on that ftp showing the same issue: ftp://test4711:test4711@82.149.226.170/mkv%20Problem%2018.05.2012%20OliO/geht%20nicht%20seit%20OE%202.0_2.mkv
Testing with the second video, to have one issue at a time: Using playbin2 with the audio flag off, the video plays fine. The ffmpeg DCA decoder doesn't like the data and errors out. ffplay and VLC play the file with no audio either. I guess GStreamer should error out instead of hanging waiting for preroll, but that may break existing streams where errors happen in the middle of a stream. A possible way out would be to only error out when no buffer was pushed yet, but that doesn't feel quite right either.
Vincent, "geht nicht seit OE 2.0_2.mkv" prerolls and played correctly with gstreamer 0.10.35 also I get sound when playing with vlc 2.0.1 (even though it's very quiet winter ambient only, barely audible) another point is, that we're not using any actual software decoder for the dts, but a hardware sink element instead which will just about eat any frame supplied, so i suspect the problem to be something other than the dcadec
Indeed, with full volume I do hear faint sound in VLC :) Then I guess there are at least two issues then.
i tried git bisecting to find the exact revision which introduced the problems but that's near-impossible because three seperate packges (core, base and good) are involved. generally speaking, it works ONLY with core&base = 0.10.35 and good =0.10.30. if any of the packages gets updated to a newer release, playbin2 playback seizes to preroll. intermediate git revisions can't really be tested because by the looks of it, the api changed too much in between. another thing we found out is that dcaparse behaves differently in the old release, we had: dcaparse gstdcaparse.c:343:gst_dca_parse_check_valid_frame:<dcaparse0>[00m possible sync 7ffe8001 at buffer offset 0 dcaparse gstdcaparse.c:199:gst_dca_parse_parse_header:<dcaparse0>[00m dts sync marker 0x7ffe8001 at offset 0 dcaparse gstdcaparse.c:218:gst_dca_parse_parse_header:<dcaparse0>[00m frame header: fc3c7db277020d3b dcaparse gstdcaparse.c:359:gst_dca_parse_check_valid_frame:<dcaparse0>[00m got frame, sync 7ffe8001, size 2012, rate 48000, channels 6 dcaparse gstdcaparse.c:369:gst_dca_parse_check_valid_frame:<dcaparse0>[00m resyncing; checking next frame syncword dcaparse gstdcaparse.c:391:gst_dca_parse_check_valid_frame:<dcaparse0>[00m next sync out of reach (96 < 2028) baseparse gstbaseparse.c:2248:gst_base_parse_chain:<dcaparse0>[00m valid frame of size 2012 at pos -1 in the new one though: dcaparse gstdcaparse.c:345:gst_dca_parse_check_valid_frame:<dcaparse0>[00m possible sync 7ffe8001 at buffer offset 0 dcaparse gstdcaparse.c:201:gst_dca_parse_parse_header:<dcaparse0>[00m dts sync marker 0x7ffe8001 at offset 0 dcaparse gstdcaparse.c:220:gst_dca_parse_parse_header:<dcaparse0>[00m frame header: fc3c7db277020d3b dcaparse gstdcaparse.c:361:gst_dca_parse_check_valid_frame:<dcaparse0>[00m got frame, sync 7ffe8001, size 2012, rate 48000, channels 6 dcaparse gstdcaparse.c:371:gst_dca_parse_check_valid_frame:<dcaparse0>[00m resyncing; checking next frame syncword dcaparse gstdcaparse.c:382:gst_dca_parse_check_valid_frame:<dcaparse0>[00m didn't find second syncword baseparse gstbaseparse.c:2398:gst_base_parse_chain:<dcaparse0>[00m finding sync, skipping 4 bytes baseparse gstbaseparse.c:2374:gst_base_parse_chain:<dcaparse0>[00m marking DISCONT dcaparse gstdcaparse.c:341:gst_dca_parse_check_valid_frame:<dcaparse0>[00m no sync, skipping 2721 bytes baseparse gstbaseparse.c:2398:gst_base_parse_chain:<dcaparse0>[00m finding sync, skipping 2721 bytes baseparse gstbaseparse.c:2361:gst_base_parse_chain:<dcaparse0>[00m not enough data available (only 3 bytes) baseparse gstbaseparse.c:2476:gst_base_parse_chain:<dcaparse0>[00m chain leaving we seem to never get any data from the parser
Plays fine for me now after some patches to the video library and the x11 sinks.
dcaparse puts a DISCONT on all outgoing buffers because the input contains an extension substream header. It doesn't understand this header and so it skips it and causes a resync + DISCONT. The discont causes the sink to not align the samples which cause small clicks and pops.
ftp://test4711:test4711@82.149.226.170/Super8_part.mkv refuses to preroll with git from today
This prerolls fine for me with git master and the 1.0 branch, both in push mode and in pull mode. It's unlikely it will ever get fixed in 0.10 if it's still a problem there, sorry. Closing.