indeed, i confirm we can reproduce this bug. the problem seems to be with re-ordering the frames for clips with B frame. we will fix that soon.
-- You received this bug notification because you are a member of TI OMAP Developers, which is subscribed to ubuntu-omap4-extras-multimedia. https://bugs.launchpad.net/bugs/1024761 Title: Issues playing most video files on Pandaboard ES Status in OMAP4 Ubuntu Multimedia addons: New Bug description: I tested today the new multimedia-extras packages released yesterday and I found that I can't play correctly most video files, both MPEG-4/AVI and H.264/MP4. The most visible issue is a constant "jerkiness" of the videos, that immediately made me think of out-of- order frames. Playing the videos with the gst-launch pipeline: GST_DEBUG=3 gst-launch filesrc location=filename.mp4 ! qtdemux qtdemux0.video_00 ! h264parse ! "video/x-h264" ! ducatih264dec ! dri2videosink showed a lot of warnings in the output: 0:00:04.421264649 8902 0x147dc60 INFO GST_ERROR_SYSTEM gstelement.c:1964:gst_element_message_full:<dri2videosink0> posting message: A lot of buffers are being dropped. WARNING: from element /GstPipeline:pipeline0/GstDRI2VideoSink:dri2videosink0: A lot of buffers are being dropped. Additional debug info: gstbasesink.c(2875): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstDRI2VideoSink:dri2videosink0: There may be a timestamping problem, or this computer is too slow. Disabling sync (dri2videosink sync=false) makes the messages disappear, and the video plays smoothly again but too fast (I'd say at least 2x the expected framerate). A mailing list message I found suggested using fakesink to check the timestamps, and in fact running the pipeline: GST_DEBUG=3 gst-launch -v filesrc location=filename.mp4 ! qtdemux qtdemux0.video_00 ! h264parse ! "video/x-h264" ! ducatih264dec ! fakesink sync=true gives this: New clock: GstSystemClock /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.120000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10490" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.160000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10580" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.200000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10508" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.240000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10580" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.280000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d105f8" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.320000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10580" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.360000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10670" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.440000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10580" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.400000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10760" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.480000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10820" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.520000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d106e8" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.600000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10820" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.560000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10508" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.640000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d105f8" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (774144 bytes, timestamp: 0:00:00.680000000, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0xb5d10760" As you can see after the first few frames two out of every four frames are swapped and this goes on for the rest of the video. This happens with pretty much all my media files, mostly DVR recordings (DVB-T MPEG2 TS streams directly dumped to disk) transcoded to MP4 (usually h264 high profile encoded with x264) or AVI (usually XVID or FMP4 MPEG-4 ASP encoded with mencoder). There's another issue specific to MPEG-4 files but I'll file another report. The only videos that seem to work are a couple of MP4/H.264 files downloaded from Youtube, and checking with fakesink I can see that the timestamps increase monotonically as expected. I'm using a new installation of Precise with the TI OMAP PPA repository added to the APT sources. Please tell me if you need other information or sample files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-omap4-extras-multimedia/+bug/1024761/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~tiomap-dev Post to : tiomap-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~tiomap-dev More help : https://help.launchpad.net/ListHelp
