[gstreamer-bugs] [Bug 640610] basesink: QoS events are wrong in live pipelines

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=640610
  GStreamer | gstreamer (core) | git

--- Comment #12 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2011-01-26 21:54:51 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> >   The Fact is that elements that report latencies can only report latencies for
> > which they are certain (in the case of an audio/video sources how big the
> > capture buffers are, in the case of decoders how many buffers they will need to
> > buffer up before they can decode them, in the case of rtpjitterbuffer how long
> > it will delay the packets,...).
> >   Those are *known* latencies (which can be updated, but there are
> > determined/explicit formulas for calculating them based on the input). They do
> > *not* depend on cpu speed/availability.
> 
> But of course in order to calculate those latencies, the framerate is needed,
> which in the rtp example, it's not.

If you have latencies that can be calculated from the framerate, then I guess
you have to know the framerate.. Or if its something like RTP, I guess you have
to set an arbitrary deadline and drop frames if they are according to that
deadline.


> >   If you had an element that was doing some processing backed with a dsp with
> > guaranteed/constant processing time based on input, you *could* report that
> > latency (audio processing algorithms come to mind here).
> 
> Just to bring this a bit closer to reality. The DSP is not a magic box, just
> like any other CPU, it cannot know beforehand exactly how much time a certain
> input need to be processed. The best you can say (if the DSP is ruining a
> real-tile OS), is that _after_ the processing you would receive the response
> after exactly a certain amount of time. However, by _you_ I mean the GPP, which
> of course runs linux, which is not real-time and there's tons of things that
> could delay such response.
> 
> IOW; there's no way to report that latency.

For the processing/transfer latency related to the DSP, I think this is just
like any other processing latency and that the application (maybe the
platform?) should just use a higher value for the minimum_latency. Otherwise I
think Edward's approach is sound. I would call is processing_deadline or
something though or max_processing_time. Otherwise it's quite confusing if you
don't understand the internals of GStreamer's latency processing.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.