VideoLAN Wiki - User contributions [en]

VideoLAN Team

2007-08-17T17:43:46Z

Ipkiss: Updated my entry

This page is intended to help to know who's who.

You don't have to have a SVN write access to put your name here. If you hang out frenquently on irc or on the forum write your name here.

(should probably be merged with http://www.videolan.org/team/index.html )

'' You can add yourself to the list following alphabetical order.''

{|
|+ VideoLAN Team
! align=left width=200 | Real name !! align=left width=100 | IRC Nick !!align=left width=100| SVN login !! align=left width=100 | wiki login !!align=left width=100 | Forum login !!
|-
| Filippo Carone || littlejohn || littlejohn || ? || ?
|-
| Rafaël Carré || funman || funman || [[User:Funman|Funman]] || funman
|-
| Antoine Cellerier || dionoea || dionoea || [[User:Dionoea|Dionoea]] || dionoea
|-
| Jerome Decoodt || DiDjCodt || djc || ? || ?
|-
| Rémi Denis-Courmont || courmish || courmish || ? || ?
|-
| Pierre d'Herbemont || pdherbemont || pdherbemont || [[User:Pdherbemont|Pdherbemont]] || pdherbemont
|-
| Damien Fouilleul || Quovodis || damienf || [[User: Quovodis|Quovodis]] || ?
|-
| Samuel Hocevar || sam || sam || ? ||
|-
| Jean-Baptiste Kempf || j-b || jb || [[User:J-b|J-b]] || j-b
|-
| Pavlov Konstantin || thresh || thresh || [[User: Thresh|Thresh]] || thresh
|-
| Felix Paul Kühne || feepk || fkuehne || [[User:Fkuehne|Fkuehne]] || feepk
|-
| Bernie Purcel || ? || bitmap || ? || ?
|-
| Jean-Paul Saman || jpsaman || jpsaman || [[User: jpsaman|jpsaman]] || jpsaman
|-
| Clément Stenac || zorglub || zorglub || ? || ?
|-
| Olivier Teulière || ipkiss || ipkiss || [[User:Ipkiss|Ipkiss]] || ipkiss
|}

Talk:Simple Preferences

2007-02-14T08:03:23Z

Ipkiss:

I though that this was about "simple prefs". We don't need to replicate the whole tree structure and include options which 99.9% of the users don't use or understand.
In my opinion, simple prefs should look like firefox's preferences: several tabs/categories (less than 10) with about 5 to 20 options each.
[[User:Dionoea|Dionoea]] 15:02, 12 June 2006 (CEST)

* ffmpeg-hq ? -- Is this out of place? I can't find it in this context -- [[User:DJ]]. It's currently not in video, but codecs, but we are free to put whatever we want wherever. [[User:Zorglub]]. Isn't that going to get kinda confusing? [[User:DJ]]. Nope :) [[User:Zorglub]] Given that it's not in that context either and the only thing that's close is FFmpeg's -- "Post processing quality", I believe you have just proven my point. You maybe free to do what you want, but is it prudent and or wise, or can others understand it? :) -- [[User:DJ]]

I will agree with the basic premise, VLC needs a simple preferences menu. But if you can't see the current tree of simple preferences as they exist presently how can you have the discussion as to include them or not? There also maybe a few that are not now in the simple preferences that should be or a few that best be handled in a different way or done away with entirely. But how can you see them to be able to relate to them or know out of context? Plus the fact that you will never be sure that you have reviewed them all and the new simple preferences will go through several changes while the end user is still confused and or ends up locking down the advanced options. -- [[User:DJ]] I disagree we all work enough with VLC to know the preference menu almost by heart and have VLC installed to check if needed (and that differ between OS and build). Now, with every thing, how do you see which pref is to be included in "the simple preferences" ?!? [[User:Xtophe|Xtophe]] Considering you know it so well you should realize, only the simple preferences are here. -- [[User:DJ]]

Perhaps going through the tree and marking everything that can't or shouldn't be changed would make it easier to see and find things. -- [[User:DJ]]

I'm not trying to be presumptuous here, but if you can't see the current representation of the simple preferences how can you know which ones to include or exclude for an understandable discussion with a reasonable end result? [[User:DJ]]

User Prefs for multiple instances of VLC playing different streams---where is it? How do I activate it? I've checked forums and docs but so far no luck...--[[User:Ddaniels|Ddaniels]] 09:34, 21 January 2007 (CET)
:Anybody? I'm trying to get a video show going for a friend's party and having multiple streams was a big part of the visuals... VLC used to be able to do it...--[[User:Ddaniels|Ddaniels]] 19:25, 23 January 2007 (CET)

Were hotkeys omitted voluntarily? [[User:Ipkiss]]

What about module specific options? For example, the wx-embed option can be considered as a simple preference. [[User:Ipkiss]]

Talk:Simple Preferences

2007-02-14T08:03:07Z

Ipkiss:

Talk:Simple Preferences

2007-02-14T08:00:48Z

Ipkiss:

Talk:Simple Preferences

2007-02-14T07:59:45Z

Ipkiss:

Simple Preferences

2007-02-14T07:57:27Z

Ipkiss: /* Now, proceed */

<span style="color:red;font-size:30pt;">See discussion please</span> (lets try to keep this page readable :) )

== Read this first ==

The current preferences use a tree that matches the vlc internal mechanisms.
The new preferences don't have to use this tree. We can use whatever we want. My first thought is a 1-level sorting, with the main topics displayed with images on the left pane and preferences pages on the right pane.

We can select preferences items one by one, we don't need the full pages that are currently used

VLC definitively needs a "simple" preferences window. Here is a list of some of the settings which would be needed:

== Now, proceed ==

(?) = to be decided

* Audio
** Enable Audio
** Default audio volume
** Use S/PDIF when available
** Force detection of Dolby surround
*** Filters
**** Equalizer
***** Equalizer preset
**** Headphone effect
**** Volume normalizer
**** Parmetric equalizer
*** Output modules (?) -- Disagree. Only needs to be modified in case of problems -- [[User:Zorglub]] --> It's still one of the options which many people have to change, having it handy will be useful -- [[User:DJ]]. If we show it up, we should only include really useful modules, like DirectX/Waveout only for aout under windows. Don't show file and dummy for instance [[User:Zorglub]] . I agree with last remark [[User:J-b|J-b]]
*** DirectX Audio output -- It'd be best to not have any "module specific" option in these simple prefs. We could have an "Output device" option ... which could be shared by each of the audio output modules. -- [[User:Dionoea]]. Very hard to do. Much simpler is to ask for all of them to show. Only those compiled in will show up. Very easy. [[User:Zorglub]]
**** Output device
*** Visualizations

* Video
** Enable video output
** Full screen video output
** Skip Frames (?) -- Agree [[User:J-b|J-b]]
** Overlay video output
** Always on top
** Video snapshot directory
** Video snapshot format
** aspect ratio (?) -- Disagree. Is a seldom used function -- [[User:DJ]].
** Windows decorations (?) -- Agree [[User:J-b|J-b]]
*** Video filters
*** Output module -- Disagree. Only needs to be modified in case of problems -- [[User:Zorglub]] --> It's still one of the options which many people have to change, having it handy will be usefull -- [[User:Dionoea]] I agree with dionoea [[User:J-b|J-b]]
**** Image file
**** Open GL
**** DirectX
***** Name of desired display device
***** Enable wallpaper mode (?) -- Agree [[User:J-b|J-b]]

* Input / Codecs
** Audio language
** Subtitle language
** DVD device -- IMO, the devices should be detected and listed in the Open dialog box. And if really needed, the options would still be in the full preferences. They could also be remembered from one session to the other -- [[User:ipkiss]]
** VCD device
** Audio CD device
** UDP port -- err ... what does that mean ? -- [[User:Dionoea]] Means nothing here [[User:J-b|J-b]]

* Stream output
** Keep stream output open -- That shouldn't be in the prefs but in the stream configuration wizards and dialogs -- [[User:Dionoea]] Is there basic cases where we don't want to keep it open. I would be to changed the default to true in libvlc -- [[User:Xtophe|Xtophe]]. Has been changed.

* Advanced
** Allow only one running instance
::This allows users to use more than one VLC player at a time.
** Allow only one running instance when started from file (?) -- i kind of agree with ipkiss that this option shouldn't exist anyway ... i guess that i'll remove it and change the default value for "Allow only one running instance". People who want more than one instance can change the prefs -- [[User:Dionoea]].. NOoooo please don't. Current behaviour is optimal (but we certainly don't want to show this in simple prefs) ! [[User:Zorglub]] -- No too [[User:J-b|J-b]]
** Enqueue items to playlist when in one instance mode

* Playlist -- Do these options really need to be in the prefs ? couldn't we just leave them in the playlist dialog/main controller and remember the state when quiting ? -- [[User:Dionoea]]. These options are indeed useless here. Just add change_autosave() on them [[User:Zorglub]] Is it already done ? [[User:J-b|J-b]] Already done on OSX (by myself) and QT4 (by zorglub) for sure, needs checking in wx. [[User:Fkuehne|feepk]]
** Play files randomly forever
** Repeat all
** Repeat current item
** Play and stop

* Interface
** Language
** Show advanced options -- This is "Complex preferences" specific so it shouldn't be in the "simple prefs" -- [[User:Dionoea]]

** ffmpeg-hq ? -- Is this out of place? I can't find it in this context -- [[User:DJ]]. It's currently not in video, but codecs, but we are free to put whatever we want wherever. [[User:Zorglub]]. Isn't that going to get kinda confusing? [[User:DJ]]. Nope :) [[User:Zorglub]]

* Subtitles
** default encoding
** size
** color
** font

* HTTP proxy
* HTTP caching -- why would we only include http caching and not all other caching options ? -- [[User:Dionoea]] Because that's almost the only one people will really want to change. We might want to add MMS. [[User:Zorglub]]

[[Category:VLC GUI]]

VoutRework

2007-02-06T12:30:49Z

Ipkiss: /* Misc */

= Draft design for the vout rework effort =

[[VoutReworkUserRequirements]]

[[VoutReworkOrganization]]

== Overall architecture ==

The current system (one vout_thread_t per window) will be splitted

* vout_core that manages all vout instances and windows. also takes care of vout_filters (wall, clone)
* vout_window object per displayed window. provides a "region for vout_renderers" to draw in.
* vout_render that renders the actual video, text and image

== OSD and subpictures ==

We need to be able to display them either:

* At video resolution, for DVD subtitles (on the "render")
* At screen resolution (text subtitles, OSD control) (on the "output")
** This will also allow us to draw subtitles outside of the video rendering
** Probably needs specific code for each vout

At the moment, subpictures have very annoying timing constraints. subpictures should be timed either on the stream (for subpictures) or absolute, from the vout_core
(for subfilters)

We should create two seperate systems. a vout_render level system which basically draws extra things into the region provided by vout_window. This can be both text, images and possibly even video. Material should be drawn in the resolution of the provided region, instead of the resolution of the main video. It should be seperate from the spu streams. However it should be possible to feed SPU based material to the vout_render system instead of the normal SPU stream pipeline and vice versa.

Comments from Gibalou: I agree overall but be aware that rendering on the vout window can be quite tricky. For instance on platforms which only support 1 overlay (already used by the video), we will have to constantly refresh the OSD (to handle resizing / refreshing of the vout window).
For this reason I would suggest we keep this feature as simple as possible and only make it support displaying of subpictures (subpicture_t/subpicture_region_t).

== Filters ==

Make a clean separation:

* vout_filters should not be the same as real vouts anymore (will come from the split)
Comments from Gibalou: they don't really need to be changed since they alreday don't create any window.
* pic_filter
** Currently called video_filter2, should be renamed
** Works on a single pic buffer
** Can be streamed
Comments from Gibalou: video_filter2 is not just about 1->1 picture conversion. It is actually designed to work on video and could for instance allow for temporal de-interlacing, inverse telecine, etc... So it really is a video_filter and not merely a pic_filter.

Two big areas of work to be able to integrate video_filters into the vout core will be:

- Proper support for direct-rendering.
Some filters won't actually modify the video frames directly (eg. auto-cropping) or will do in-place modifications so they will need to be able to allocate their pictures from the next filter in the chain and pass it on to the previous filter when requested. In short, picture allocation needs to be reviewed so it is done in an optimized way.

- Dynamic modification of the filter chain.
Again this is tricky because the decoder (which does direct-rendering) will be using pictures allocated from the filter. If this filter changes or is removed, we will need a way replace the pictures in use by the decoder. That could be done by having a mechanism that progressively replaces the picture buffers used by the decoder by indirect buffers and when non of the direct buffers are in use anymore then we switch the filter.
That will be a lot better then the current way of stopping/starting the decoder.
* subpicture_filter

== Modularization of specific calls ==

For many of the operations we need, OS specific calls exist (OpenGL, Quartz, DirectX). This should be modularized, with a native "C" fallback.
OS specific calls are often faster.

There should be only one module for all the calls, if possible. The best module would be loaded by the vout_core singleton, and function pointers set up for each of the functions we need. perhaps a vout_Control type could take care of all these things in the vout_renderer.
paramaters that should be handled this way are at least: alignment, AR, crop, pad

Comment from Gibalou: AR, crop (and soon pad) are already implemented in the vouts (see below). Alignment is also already supported and is only about placing the vout subwindow (frame or whatever you call it) into the main window.

== Misc ==

* Vout plugins (that provide vout windows) should allow reusing a vout by reusing it. This would much improve the experience)
* Vout windows must have a flag to tell if they are "main" or "helper" (audio visualization, ...). Helper vouts should get no OSD (if another vout is present) and should not "steal" the accelerated vout"
* cropping and padding (do at OS level, but provide a core call to set it up and configure) '''=> Done'''
* vout windows should indicate if they are on a 4:3 or 16:9 screen (we can calculate this trough resolution). Note that this can change, because a window could be moved from one screen to another. Use callbacks. '''=> Why would you want to know the AR of the screen ? Aren't you confusing with the PAR ? This information could be used by the core to facilitate selection of cropping/padding etc for instance 4:3 display on a 16:9 screen. you might want to crop the top/bottom or stretch the view by default. Especially when you are also gonna add padding for subtitle rendering for instance, this information might become useful.
* better hotkeys integration: need hotkey module redesign to act on selected vout and relevant input instead of the first we find
* pseudo-hotkeys: ability to move the window by clicking on the video and dragging it (in particular for borderless windows).
* interaction between interfaces and embedded vouts: if the vout window is moved and/or resized (due to a hotkey), how to notify the interface (skins engine in particular)?
'''

== cropping padding functionality ==

* add padding in order to display subs under the video. what if we have a 4:3 movie in a 4:3 screen? do we create blackbars to the left and right sides? do we crop a part of the video ???
* 4:3 cropping to 16:9 (in order to remove blackbars at top and bottom
* 16:9 cropping to 4:3 (in order to remove blackbars left and right side)
* 4:3 to 16:9 (AR correction)
* 16:9 to 4:3 (AR correction)
* AR Freeform
* Support Moviescreen AR? (2.39:1 or 1.85:1)
* More info on AR: http://en.wikipedia.org/wiki/Aspect_ratio_(image)
* If we let the window provider pass/calculate the AR of the display, then we can even do some of this automatically if the uses desires.
* cropping should have priority over padding. Then we can first crop blackbars, then add padding for subs.
* coordinate specified cropping and padding

Comment from Gibalou: AR / Cropping (and soon Padding) has already been reworked and is now handled directly in the vout module (makes sense since cropping and resizing are supported by most sane graphic APIs).
All this is controled from the core by setting the relevant parameters in vout_format_t.
Now, what could be done is to add extra logic (eg. in video_filters) to do some clever things like auto-cropping, etc... All they need to do is to modify video_format_t to change the final cropping/padding/AR.

Intellectual Property

2006-12-16T15:26:18Z

Ipkiss: s/licence/licence/g

== Code Copyright ==

Most of the copyright of the projects and software belongs to [http://www.videolan.org/team/ Videolan's team] and to the [http://trac.videolan.org/vlc/browser/trunk/AUTHORS authors].

Some files are naming some other copyrights and authors. If you need, check them all in the latest [[SVN]].

== License ==

'''VideoLAN''' produces free software projects under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License].
The License is under the COPYING file of the SVN and all the tarballs.

== Redistribution / Copying ==

You can redistribute, copy and modify any GPL software, including VideoLAN's, but you have to conform to the LICENSE, which is mainly that you have to provide the source code and use a LICENSE compatible with the GPL. If you don't understand, please check this article about
[http://en.wikipedia.org/wiki/GPL GPL on Wikipedia].

===[[FAQ]]===

== Names / Trademark ==
The official name of the project is '''VideoLAN'''.

The official name of [[VLC]] is '''VLC media player'''. It used to be called ''VideoLAN Client'', but this is not true anymore.

''VLC'' is the familiar name of '''VLC media player'''.

The soppera-cone is the official icon of the program. http://download.videolan.org/images/goodies/cone-soppera10-moyen.png

The official names of [[VLS]] are '''VLS''' and '''VideoLAN Server'''.

Talk:0.9.0PlaylistTODO

2006-05-22T17:09:03Z

Ipkiss:

Playtree text string formating:

I would like to have more control about the text formating of the playtree object - currently there is a leading path string and no author, playtime, aspect ratio, codec field available in Skins2.

this is a big problem if it comes to professional playback in cinema environments where you have to know what comes next in parts of seconds without an mistake...

would be delighting to discuss solutions to this...

nw42

:How would you do see that?
:In fact, there are several options. For example, there could be a popup menu when right-clicking on a playlist item (like in the wxWidgets interface). Or the columns of the control could be adapted, to show different information (obviously, this would have to be made configurable, as different people would not be interested in the same fields).
:My preference goes for the first option, which is easier to implement :)

:ipkiss

DefaultSkinRequirements

2006-03-14T07:48:44Z

Ipkiss: /* Optional elements */

== General requirements ==

* Be sobre, so as to fit in all environments
* No real need for a big "VLC" or "VideoLAN" text/logo
* Original design, not copied from something existing

== Mandatory elements ==
* Main window
** Play/Pause
** Stop
** Next
** Previous
** Slider
** Volume
** Time display
** DVD buttons (do we want them to be shown all the time ? -- of course not)
** Playlist button
* Playlist
** Playlist (use <Playtree>)
** Add button
* Video window

== Optional elements ==
* Equalizer
* Playlist
** Random, loop buttons
** Or : submenu
* Video window
** Fullscreen button
* Miniature mode

DefaultSkinRequirements

2006-03-14T07:48:33Z

Ipkiss: /* Optional elements */

DefaultSkinRequirements

2006-03-14T07:44:58Z

Ipkiss: /* General requirements */

DefaultSkinRequirements

2006-03-14T07:44:04Z

Ipkiss: /* Mandatory elements */

== General requirements ==

* Be sobre, so as to fit in all environments
* No real need for a big "VLC" or "VideoLAN" text/logo

== Mandatory elements ==
* Main window
** Play/Pause
** Stop
** Next
** Previous
** Slider
** Volume
** Time display
** DVD buttons (do we want them to be shown all the time ? -- of course not)
** Playlist button
* Playlist
** Playlist (use <Playtree>)
** Add button
* Video window

== Optional elements ==
* Equalizer
* Playlist
** Random, loop buttons
** Or : submenu
* Video window
** Fullscreen button