GNOME Bugzilla – Bug 383014
generate a clock and correct timestamps when incoming buffers are untimestamped
Last modified: 2010-02-09 10:14:19 UTC
This is quite a large patch. I can split it down if people want.. 1) Adds a property to allow gstffmpegdec to generate a clock when it has untimestamped incoming buffers (i.e. there was no clocked transport) 2) for untimestamped buffers, generates a clock from the framecount and frame duration as ffmpegdec->picture->pts isn't reliable 3) Removes duplicate initial keyframe checking from gst_ffmpegdec_chain
Created attachment 77817 [details] [review] gstffmpegdec-add-clock-and-fix-timestamps-for-untimstamped-streams.diff
a clock in a decoder? can you give a use case? Also there is no clock in PAUSED so the element should return ASYNC an participate in PREROLL.
I admit the usecase is obscure - its for streamed raw mpeg4 (ie, as I said in the inital comment, no clocked transport). There is code in gstffdec to support this use case already, this just makes it work ;) I'll fix up the patch as requested.
Any news on this?
I'm afraid I haven't had time to look at this again. The change mentioned by Wim should be pretty straight forward though.
As I can see no open question left (besides "any news on this?), I'll reopen this one. I'd say to either accept this issue as a bug and set to NEW or to decide to not consider this issue as a bug and close as WONTFIX.
Rob, could you give us the bigger picture here ? What upstream elements are you using ? What are you receiving the stream from ? There are many use-cases where you would actually do the timestamping upstream.
Closing because no additional information was provided.
Hum, looks like I missed that last question, though tbh I don't have that info to hand any more. As I recall the situation was raw mpegts packets in raw multicast UDP packets. Hence the need for the clock to come from the mpegts stream. The stream was from a commercial networked mpeg encoder. Reopening as additional information was provided ;)
(In reply to comment #9) > Hum, looks like I missed that last question, though tbh I don't have that info > to hand any more. As I recall the situation was raw mpegts packets in raw > multicast UDP packets. Hence the need for the clock to come from the mpegts > stream. The stream was from a commercial networked mpeg encoder. > > Reopening as additional information was provided ;) And closing again because mpegtsdemux can provide a clock nowadays ;) Or would you need this for other formats too? Should every decoder/demuxer provide it's own clock based on the internal timestamps? I'd say your situation was wrong, you should better use rtp or something like that for the UDP packets :)
I think if mpegtsdemux can provide the clock, thats the best solution. If you have an mpegts stream you really shouldn't need to get a timestamp from the surrounding transport.