GNOME Bugzilla – Bug 609408
[mpegpsdemux] Produces wrong timestamps
Last modified: 2012-06-18 16:37:29 UTC
I have a file saved from a IP camera through http using wget. It plays fine with mplayer but not with GStreamer. Receiving the live stream with GStreamer have the same effect than playing it from a file.
The file exceeds 1MB and cannot be attached, here it is in megaupload. http://www.megaupload.com/?d=SBT0HFEP
Seems to be a problem with mpegpsdemux, it produces incorrect timestamps: /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "event ******* E (type: 102, GstEventNewsegment, update=(boolean)false, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, start=(gint64)73257000000000, stop=(gint64)-1, position=(gint64)57109740300000;) 0x1120b80" Setting pipeline to PLAYING ... New clock: GstSystemClock /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8192 bytes, timestamp: 20:20:57.000000000, duration: none, offset: -1, offset_end: -1, flags: 33) 0x7f66800011c0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8192 bytes, timestamp: none, duration: none, offset: -1, offset_end: -1, flags: 1) 0x7f66800012c0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 7764 bytes, timestamp: none, duration: none, offset: -1, offset_end: -1, flags: 1) 0x7f66800013c0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 5168 bytes, timestamp: 4:29:07.339700000, duration: none, offset: -1, offset_end: -1, flags: 1) 0x7f66800011c0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 5172 bytes, timestamp: 4:29:07.379700000, duration: none, offset: -1, offset_end: -1, flags: 1) 0x10cb6c0" ffdec_h264 then drops all frames except the ones without timestamps because they're before the configured segment.
*** Bug 609520 has been marked as a duplicate of this bug. ***
ffdemux_mpeg shows the same timestamp errors.
Does anyone still have this file?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!