GNOME Bugzilla – Bug 435633
[PATCH] videorate not (fully) segment aware; causes framedrops
Last modified: 2009-03-24 15:45:57 UTC
videorate does well on a particular segment selected by a flushing seek. However, if a subsequent non-flushing seek is then performed, a (possibly large) mismatch in timestamp calculations will cause many many framedrops.
Created attachment 87489 [details] [review] Possible patch * react (more) to NEWSEGMENT * small adjustment in timestamp calculation to prevent mismatches
Created attachment 91124 [details] [review] Updated possible patch Basically same as previous patch, but updated for latest release (0.10.13)
Created attachment 91125 [details] [review] Updated possible patch Oops, immediate preceding patch contained some extra spurious diff
i can confirm the bug. I've tried to apply the patch and it fixes the problem for me. i can reproduce the bug with a pipeline like "source ! videorate ! encoder ! avimux ! filesink Then i send from source: - newsegment - some buffers inside the new segment - newsegment - some buffers inside the new segment - and so on.. in the resulting file the first segment is ok but the others are garbage (wrong timestamps, early eos).
Created attachment 97353 [details] log for a burst of buffers after a NEW_SEGMENT
Hi, strange behaviour (cf attached file 'debVideoRate.txt.gz'), two incoming buffers, the videorate sends a burst of new buffers, filling time between 0 and first buffer timestamp...
The 'debVideoRate.txt.gz' is obtained with the patch applied (2007-07-03 16:57).
The attached log (debVideoRate) actually does not show any strange behaviour, but rather illustrates videorate is doing just fine. Some commented excerpts from the aforementioned log to illustrate: -- 0:00:27.437118000 25730 0x831e3b0 DEBUG videorate gstvideorate.c:529:gst_video_rate_event:<videorate2> updated segment: time segment start=0:00:00.000000000, stop=99:99:99.999999999, last_stop=0:00:00.000000000, duration=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:23.750000000, accum=0:00:00.000000000 -- This tells videorate that buffers are to be expected with timestamp (around) 0, and that it therefore should produce nicely regular output buffers *from 0* as well. Then, the first real buffer comes in: -- 0:00:27.438789000 25730 0x831e3b0 DEBUG videorate gstvideorate.c:640:gst_video_rate_chain:<videorate2> got buffer with timestamp 0:00:23.750000000 -- This first one is not (around) 0, but actually a whole lot later. So, videorate does what it is supposed to do, and produces a burst of buffers filling the gap between 0 and the first received buffer, which it must do to produce a 'perfectly rated' stream. Videorate should not and will not produce such a burst (with the patch applied), if the NEWSEGMENT would have indicated start (around) 23.75 (as it should have in this case).
Given the currently announced imminent release cycle, could this bug be given a look. It's small, nasty for some use-cases, and patch does seem to fix things ...
*** Bug 511637 has been marked as a duplicate of this bug. ***
Ping ? Approaching the first aniversary of this bug, it still applies to CVS HEAD, and so does the patch. Is there is a particular (technical) reason for it not to be committed ? If so, it would be nice to know which one, so that it can be addressed/fixed, otherwise ...
Patch by: Mark Nauwelaerts <manauw at skynet be> * gst/videorate/gstvideorate.c: (gst_video_rate_reset), (gst_video_rate_flush_prev), (gst_video_rate_event), (gst_video_rate_chain): * gst/videorate/gstvideorate.h: React (more) to NEWSEGMENT Small adjustment in timestamp calculation to prevent mismatches Fixes #435633.
I get the same phenomena as Laurent Glayal, but can't seem to find the missing/elusive newsegment message (and will have to locally revert the patch)...