[vlc-devel] [LONG] Some thoughts and questions about vout

[brezhoneg1]

Ok, I surrender!

I guess this vout recycling scheme wasn't removed just to make users
enrage! If stability was at stake, that's a point.

About vlc_object_find (being deprecated and yet so widely used), is
there any guideline to figure out how to do things the new/right way?
Without these guidelines, one can but feel helpless about all those
FIND_ANYWHERE which prevent promising new libvlc api to deliver its true
value!

Erwan10

-----Message d'origine-----
De : vlc-devel-bounces at videolan.org
[mailto:vlc-devel-bounces at videolan.org] De la part de Rémi
Denis-Courmont
Envoyé : mercredi 12 novembre 2008 20:30
À : vlc-devel at videolan.org
Objet : [vlc-devel] Re: [LONG] Some thoughts and questions about vout

Le mercredi 12 novembre 2008 18:50:30 brezhoneg1, vous avez écrit :
(...)
> Question: Why not have vlc take existing video widget width and height
> as default. And maybe create a --original-size if one really wants to
> start a movie at full resolution on the desktop?

The video output recycling was stripped out due to its fundamentally not

thread-safe (and hence crash-prone) design. It's not trivial (nor 
super-human) to bring it back, but nobody's bored this far.

But frankly, I don't want my VLC to use the resolution of the previous
video 
blindly. That makes no sense to me.

> 2- Seamless transition between inputs in fullscreen mode
> ---------------------------------------------------------
(...)

Same cause.

> 3- Today's situation :
> ---------------------
>
> To my amazement, I realized vlc0.8.x had a vout re-use implementation
> that still exists in vlc0.9.x and vlc1.0.0 (desactivated because of
some
> thread-safe reference handling).
>
> Question: Any plans to re-work it in a near future?

See above.

> 4- Question I am puzzled about:
> ------------------------------
>
> In vlc0.8.x implementation, width, height and chroma had to match
> between new input and existing vout for re-use to succeed. This is why
> vout reuse was kind of temperamental.

No. Race conditions were the driver for its removal.

The same could be said of the audio output, and would explain glitches, 
although that only happens with crappy audio hardware.

> My understanding is that :
> --> width and height should not be an issue (window resizing doesn't
> require a new vout, right ?)

I don't know the vout architecture much, but I think it _does_ require a
new 
vout instance. At least with the current video output architecture.

> --> chroma is most often detected by the vout driver (see xvideo in
> x11/xcommon.c) and chroma conversion is already managed entirely in
the
> vout thread. Resetting chroma shouldn't be a problem?

Same thing.

> Question: Why such stringent restrictions on those width, height and
> chroma parameters?

First and foremost, nobody has (re)written the code.

> I tried to resuscitate late vlc0.8x implementation and ignore these 3
> restrictions (see patch attached). My tests were successful (done on
> Linux, not sure I tested every possible case). Actually, it seemed too
> simple to be true (one function added to video_output.c to reset the
> thread based on existing CleanThread and InitThread functions). Is
there
> anything I missed?

Probably. If it's using vlc_object_find(), you most probably loose.
If it's using unpaired vlc_object_release() you definitely loose.

> A last comment, there may be situation where reusing vout can be a
> complex thing ?? (vout-filter ?). If so, why not create a --vout-keep
> the same way as there is already a --sout-keep. Functionally speaking,
> the same issue is at stake; Allowing a resource to be kept from one
> input to the other and make it optional.

--sout-keep is there because we could not come up with a way to always
pick an 
acceptable behavior. I am against adding a _configurable_ --vout-keep, 
because I see no reason one would want to disable a _working_ video
output 
recycling scheme.


While we're on the video output problems...

In the mean time, another major user-perceived problem surfaced. The way
we 
cleanup VLC is fundamentally incompatible with embedded video output:
1/ remove all interfaces (including the embedded video),
2/ remove playlist, VLM, terminate all inputs,
3/ remove any leftover video output.

Since the video output depends on the embedded video, this deadlocks (or

crashes). But we need to destroy the playlist after the interfaces,
since the 
interfaces assume the playlist is always there. And with the playlist
there, 
there is no way to safely destroy video outputs when the playlist is
alive.

Of course, we could probably fix this somehow, with extra "intermediary"

cleanup stages. But this is not trivial at all, I'm afraid.

And yeah, I reached 100 lines - now I can use [LONG].

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary