GNOME Bugzilla – Bug 696751
videodecoder: should pass through buffer offsets
Last modified: 2018-05-05 15:09:00 UTC
In 0.10.x I used the GstBuffer::offset member to retrieve the current frame number. This field is always -1 now. So how to get the frame index in my appsink? It seems occur if I use gst-libav (filesrc, decodebin, appsink). I get same behaviour in all my sample movies. In gst debug out I can sse, that the avidemux sets rhe offset correctly. but after passing through decoder this field is -1.
Should it pass through the offsets or put the frame count into the offset in any case, no matter what upstream did? I think only the last makes sense, and that (actually both) can easily be added to GstVideoDecoder.
I guess just always putting the offset on there is fine too, probably even better, but it should still honour upstream offsets. And what does it do after seeks if there wasn't an upstream offset with the first buffer? What does it do after disconts? This whole buffer offset thing is often just misleading really.
I don't know :) And how do you detect if upstream offsets are frame numbers or something complete different (e.g. granulepos)
They should always be frame numbers for video. Isn't granulepos in OFFSET_END? (though it should really be in a meta imho)
There's some weird other value in OFFSET for Ogg IIRC... but yes, it should be meta and we failed to change that in time for 1.0 :)
Does the ogg/granulepos stuff actually still matter? Doesn't oggdemux put proper timestamps and durations on buffers now?
I think it's still relevant for oggmux
True, but that's not something we need to worry about in GstVideoDecoder.
No, but upstream of the decoder puts this into the buffer offset... so re-using any offset information from upstream can be a bit tricky
I don't think we're going to fix this any time soon, sorry. Not convinced there's a great deal of value in this apart from a few very specialised formats/cases.