GNOME Bugzilla – Bug 661063
[discoverer] - Fail to detect correct number of streams
Last modified: 2013-07-18 11:02:31 UTC
I have two .mkv files with h264 video and AC3 audio. The small one (created with GStreamer) I can remux to MPEG TS now, with the latest fixes from Thiagoss and Vincent. However I also got a large MKV file from a bittorrent, and that fails with a GStreamer encountered a general stream error. Attaching GST_DEBUG log, can also provide the 1.5GB file as needed. The 1.5G file plays fine in Totem.
Debug log: http://www.linuxrising.org/files/misc/mkvts.log.bz2
Did some further testing. Seems h264 remuxes fine (if I choose to re-encode the audio), it is the AC3 remuxing that messes up. If I re-encode the audio, the process seems to work fine.
Tried doing the reverse remux and once again the ac3parser seems to be the troublesome element. Making this an ac3parse bug.
Adding latest email exchange between me and Thiago Here's the problematic part from the logs (it seems) gst_capsfilter_transform_caps:<capsfilter5> input: audio/x-ac3, framed=(boolean)true, rate=(int)48000, channels=(int)6, gst_capsfilter_transform_caps:<capsfilter5> filter: audio/x-ac3, framed=(boolean)true, channels=(int)2, rate=(int)48000 gst_capsfilter_transform_caps:<capsfilter5> intersect: EMPTY The caps set to the capsfilter contain channels=2, while the demuxer is trying to push a buffer with channels=6 on the caps. Going to debug further. If you have any tips of how transmageddon sets that caps, it would be helpful. -- Thiago Weird, because I don't know if you seen it, but Transmageddon reports to the file as having two audio channels. Looking at the code in transmageddon.py, I put in some print statements and discoverer reports back 2 channels on that file, the information I get from discoverer is what I use to create the remuxing caps. Now that I know the issue I might be able to work around it, but obviously discoverer should not report 2 channels on a 6 channel file. Christian
gst-discoverer-0.10 test.mkv Analyzing file:///home/cschalle/Download/test.mkv No accelerated IMDCT transform found Done discovering file:///home/cschalle/Download/test.mkv Topology: container: Matroska video: H.264 audio: AC-3 (ATSC A/52) Properties: Duration: 1:01:35.200000000 Seekable: yes Tags: audio codec: AC-3 audio language code: und video codec: H264 container format: Matroska bitrate: 384000
gst-discoverer-0.10 -v test.mkv Analyzing file:///home/cschalle/Download/test.mkv No accelerated IMDCT transform found Done discovering file:///home/cschalle/Download/test.mkv Topology: container: video/x-matroska video: video/x-h264, level=(string)3.1, profile=(string)high, codec_data=(buffer)0164001fffe100186764001fac34e4014016e8400000fa40002ee023c60c658001000568eeb2c8b0, stream-format=(string)avc, alignment=(string)au, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)24000/1001 Codec: video/x-h264, level=(string)3.1, profile=(string)high, codec_data=(buffer)0164001fffe100186764001fac34e4014016e8400000fa40002ee023c60c658001000568eeb2c8b0, stream-format=(string)avc, alignment=(string)au, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)24000/1001 Additional info: None Width: 1280 Height: 720 Depth: 0 Frame rate: 24000/1001 Pixel aspect ratio: 1/1 Interlaced: false Bitrate: 0 Max bitrate: 0 Tags: taglist, video-codec=(string)H264, language-code=(string)en, container-format=(string)Matroska; audio: audio/x-ac3, framed=(boolean)true, channels=(int)2, rate=(int)48000 Codec: audio/x-ac3, framed=(boolean)true, channels=(int)2, rate=(int)48000 Additional info: None Language: und Channels: 2 Sample rate: 48000 Depth: 0 Bitrate: 384000 Max bitrate: 0 Tags: taglist, audio-codec=(string)"AC-3\ audio", language-code=(string)und, container-format=(string)Matroska, bitrate=(uint)384000; Properties: Duration: 1:01:35.200000000 Seekable: yes Tags: audio codec: AC-3 audio language code: und video codec: H264 container format: Matroska
It looks like the AC-3 stream has one 2-channel frame at the beginning, and then it switches to 6 channels. Could be a bug in ac3parse of course, but might be an artefact of transmuxing from mpeg-ts/ps to mkv.
That sounds reasonable, since it is a DVB rip, it probably was in MPEG-TS first, and it wouldn't surprise me if the commercial break is mostly in stereo, and they managed to catch 1-frame of that break :)
Shall we close this bug because it's a broken file ?
Let's close it. Not really sure what we can do better here.