GNOME Bugzilla – Bug 628284
[rsvgdec] all buffer timestamps are set to zero
Last modified: 2011-08-23 08:21:28 UTC
When the framerate specified in the caps is zero (such as when a variable framerate source is used), rsvgdec sets all buffer timestamps to zero. I believe a more correct behavior would be to forward the existing buffer timestamps (and durations) in this case. I have attached a patch with the proposed fix.
You forgot to attach the patch :) But yes, timestamps from upstream should always be preferred, not only in the 0/1 framerate case. Only if upstream provides no timestamps, rsvgdec should provide its own.
Created attachment 169046 [details] [review] patch
However, if upstream timestamps are always preferred then perhaps more comprehensive changes are required. Thanks for investigating this anyway.
Do you have a test file at hand by any chance?
Created attachment 169578 [details] Test case for 628284 This example demonstrates that rsvgdec does not forward buffer timestamps and durations. If you remove rsvgdec from the pipeline, the timestamp and duration pass unscathed.
Comment on attachment 169046 [details] [review] patch yes, this won't work in most cases. it would require to always have a timestamp the correct way to do this would be, to keep track of the upstream timestamps (if any) by something like gst_adapter_get_prev_timestamp() and something similar for the duration.
Another variation of this bug is, when there are no upstream time-stamps but a framerate. Example: gst-launch -v multifilesrc location="%05d.svg" ! "image/svg,framerate=30/1" ! rsvgdec ! fakesink rsvgdec changes the framerate, duration and all timestamps to 0
It seems that the SVG data can come im multiple buffers. When this is so, it is not clear what timestamps make the most sense. My first guess would be from the timestamp of the first buffer to the end time of the last buffer, but then this would add quite some latency, as the output buffer can only be pushed when the last buffer comes in, but with a timestamp from the past (from the first buffer).
Created attachment 194123 [details] [review] rsvgdec: use input buffer timings if possible SVG data may come through multiple buffers, so keep track of the timestamp of the first buffer, and use it in preference.
Note that I needed https://bugzilla.gnome.org/attachment.cgi?id=194122 as librsvg crashes with the python test case above.
Review of attachment 194123 [details] [review]: Looks good except: ::: ext/rsvg/gstrsvgdec.c @@ +393,3 @@ + if (GST_BUFFER_DURATION_IS_VALID (buffer)) + end += GST_BUFFER_DURATION (buffer); + GST_BUFFER_DURATION (outbuf) = end - GST_BUFFER_TIMESTAMP (outbuf); You should set the duration to GST_CLOCK_TIME_NONE if no framerate is provided and the input buffer has no duration either
Created attachment 194210 [details] [review] rsvgdec: use input buffer timings if possible SVG data may come through multiple buffers, so keep track of the timestamp of the first buffer, and use it in preference.
Created attachment 194212 [details] [review] rsvgdec: use input buffer timings if possible SVG data may come through multiple buffers, so keep track of the timestamp of the first buffer, and use it in preference.
commit e323efc35345f8cc4942fd2598a08d97aeb023f0 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Thu Aug 18 13:21:18 2011 +0100 rsvgdec: use input buffer timings if possible SVG data may come through multiple buffers, so keep track of the timestamp of the first buffer, and use it in preference. https://bugzilla.gnome.org/show_bug.cgi?id=628284