[vlc-devel] Some thoughts and questions about vout

brezhoneg1 brezhoneg1 at yahoo.fr
Wed Nov 12 17:50:30 CET 2008

This email is intended to give you some feedbacks about vout and ask a
few questions. Hopefully, it will help enhance vlc still further. 

1- By default, vlc changes in size, whenever a new input is started.

As a user, I would rather see vlc be confined within boundaries already
set up. When it comes to HD video, it can be really annoying, since
today's PC screens may be unlikely to play them back at full resolution.
vlc then starts a window far greater than screen size. We can of course
launch vlc with options e.g vlc --width=400 --height=300 to work out the
problem. But, for user without knowledge of vlc numerous options, first
feeling may not be so great.

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?

2- Seamless transition between inputs in fullscreen mode

This one is a real issue. Playing back a whole playlist in fullscreen
mode should be considered a basic feature. Yet, today's implementation
makes transition really ugly (it flashes back to desktop). This was a
big issue on the forum a few weeks ago. This is the kind of detail that
makes me think of vlc as a Ferrari vs. a regular car. (Very
technology-oriented, but some everyday basic details may be overlooked a

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?

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.

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

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

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?

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.

Comments welcomed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_source_reuse_vout.diff
Type: application/octet-stream
Size: 4949 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20081112/15681803/attachment.obj>

More information about the vlc-devel mailing list