GNOME Bugzilla – Bug 582679
MPEGTS demuxer struggles with M2TS file
Last modified: 2011-05-20 12:39:41 UTC
Sony and Panasonic has defined a MPEG TS variant called AVC HD. Usually using m2ts or mts as the suffix. The demuxer stalls on first image of this file. Link here: http://www.edi.org/test.MTS
As I understand it, handling this format requires reordering incoming packets using the timestamps provided in the extra 4 bytes attached to each MPEG-TS packet. The ffmpeg demuxer handles it OK.
Actually, our demuxer handles it OK too, it just seems that the stream is too difficult for my CPU to decode - a short clip of 1920x1080p that only shows maybe 5 of the frames. gst-launch filesrc location=test.MTS ! mpegtsdemux ! ffdec_h264 ! fakesink -v shows that it is decoding the frames, albeit with some error warnings from ffdec_h264.
Hmm, weird cause, it plays for me with mplayer, but stops right away with totem
The ffmpeg demuxer seems to produce a slightly better playback - which might indicate the mpegtsdemuxer has higher overhead. Otherwise - it looks like mplayer just does a better job at getting more frames onscreen.
I realised last night that I should have used this pipeline for testing: gst-launch filesrc location=test.MTS ! mpegtsdemux ! queue ! ffdec_h264 ! queue max-size-buffers=3 ! xvimagesink The extra queue between the decoder and the sink is important for allowing the decoder to get as many frames as possible decoded. With that pipeline, I see it decoding a lot more, but it's not correct - there's corruption in the output video. ffdemux_mpegts doesn't have the same corruption. Adding h264parse in front of ffdec_h264 doesn't help.
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 490819 ***