[gstreamer-bugs] [Bug 638891] New QoS event encouraging degraded rendering when window is obscured

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #22 from Yongnian <yongnian.le at intel.com> 2011-01-20 06:26:10 UTC ---
(In reply to comment #17)
According to your review feedback, I revised the modification as below:
1. avoid introduction another new QOS event. Add one field/parameter to
indicate the reason why QOS event is generated. In order to backward
compatibility, the new API has suffix as "_full" which is required to provide
new paramter "reason". For the original API without "_full" is still kept as
the wrapper to new full API. 
2. the future extension for stream source selection by stream quality is added
as well as one of the QOS reason in QoS event. But the specific QOS event
generation and processing are not implemented (leaving for the developers who
need it in future)
3. Others kept the same, the complexcity in GSTTEE cannot be reduced, since it
need handle whether one src path can use degraded rate of buffer for rendering
while others can use normal rate of buffer for rendering. If you have better
idea, please help raise it and it will be appreciated!

> (In reply to comment #16)
> > I discussed this with David Schleef
> > (http://sourceforge.net/mailarchive/forum.php?thread_name=20101213042030.GA20961%40cooker.entropywave.com&forum_name=gstreamer-devel)
> > at gstreamer developer forum. Two ways are possible: a specialized QoS event
> > (proportion=0.0) or a new QoS event.
> That's not what david suggested, he suggested an extension, not a new event.
> Why is the proportion=0.0 not sufficient for you?
> > We think the second way is better: 1) many codes might be updated for such special proportion for prior way;
> How would that work? what would they do? What would they do differently from
> QOS ?
> > 2) the semantic is different from original QoS event which is only impacted by CPU overhead to disable stream;
> That is true, maybe suggesting that current QOS is not the right approach. Or
> maybe suggesting that a QOS extension is needed.
> > 3) it might be extended to new usage scenario to select stream with different quality.
> That would be better served with a stream selection mechanism, IMO.
> > As why we cannot completedly disable the
> > stream, sink element still needs "render" the invisible window for future
> > re-painting request (window system doesn't hold previously rendered data).
> How would that work? what is the element supposed to do? How many frames per
> second is acceptable?
> > For the last question, the element of TEE is reducing the rate of buffer
> > processing when it sees QOS_OBSCURED event, but it cannot push such event to
> > upstream elements further for its funtionality.
> I thought the point was to reduce the amount of unneeded processing done by
> decoders. Is it that you only forward the event when all branches of tee
> received the event?
> What I see here that you want to add an event to instruct upstream element to
> reduce the rate of data processing. This is exactly what QOS does. Maybe you
> simply want to add a flag to QOS to tell it that the rate reduction is not
> because of realtime performance problems?

-- 
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.