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

[Rémi Denis-Courmont]

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