[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 #18 from Yongnian <yongnian.le at intel.com> 2011-01-11 02:28:26 UTC ---
(In reply to comment #17)
> (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.
That is the future possible usage, if any developer needs such feature, they
could extend current path for their purpose. It's hard for me to expect exactly
what they need and implement what they like. 
> > 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?

That is currently handled in the element gstxvimagesink, the "rendered" data
was saved for future repainting. If we completely disable stream, when
"repainting" request happens, we can only repaint the window with buffer long
long ago. Currently the frame per second for obscured sink window is set to 1
frame per second statically.

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

The QOS_OBSCURED event will be pushed to upstream elements. Not all elements
could pass through such event. Those elements which would adjust the rate of
buffer processing for such event should not push it to upstream further. So TEE
is such element. Generally only one src branch of TEE is sink element and TEE
need adjusts its buffer transmit rate to such src branch. But all other src
branches and upstream should not be impacted. 

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

Could you please give more hints on what suggesting QoS event extension would
be? To add a flag to indicate the exact QoS reason? If so, I'm afraid that many
codes might to be updated since the semantics are different. If most of others
can accept that other related codes don't need to be updated, that's fine for
all.
if (event_type == QOS_EVENT) {
   //original processing
}
==>
if (event_type == QOS_EVENT) {
    if (qos_resson == CPU_OVERHEAD) {
        //original processing
    }
    else if (qos_reason == SINK_OBSCURED) {
        //new stuffs
    }
}

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