- 03 Mar, 2008 16 commits
-
-
Rémi Duraffort authored
-
Rémi Duraffort authored
-
Rémi Duraffort authored
-
Rémi Duraffort authored
If mac users can test ... (evenif it's really simple)
-
Faustino Osuna authored
-
Faustino Osuna authored
-
Pierre d'Herbemont authored
-
Pierre d'Herbemont authored
-
Jean-Baptiste Kempf authored
-
Pierre d'Herbemont authored
-
Pierre d'Herbemont authored
-
Pierre d'Herbemont authored
-
Jean-Baptiste Kempf authored
-
Christophe Mutricy authored
-
Christophe Mutricy authored
-
Ilkka Ollakka authored
and doesn't seem to affect any regression on demuxing.
-
- 02 Mar, 2008 24 commits
-
-
Pierre d'Herbemont authored
-
Pierre d'Herbemont authored
-
Pavlov Konstantin authored
-
Mark Moriarty authored
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>
-
Rémi Denis-Courmont authored
Assume RTP converys video (which is fine for MPEG-TS), as we cannot know if it's only audio anyway. Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>
-
André Weber authored
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>
-
Rémi Denis-Courmont authored
but NOT from var_OptionParse(). Rationale: At a shallow level, this breaks the command line use badly. At a deeper level: We still do security enforcement in var_OptionParse(). In practice, the config chain strings are always coming from (part of) the value of string configuration variable, which is parsed by var_OptionParse(). Hence, as long as these variables are all tagged as "unsafe", only trusted input can ever reach config_ChainParse(). There are other (intractable?) issues with checking configuration chain strings: First, we would also need to check the module name in front of the {var1=val1,...} stuff. Second, some modules parse their configuration chain manually, i.e. they don't call config_ChainParse() and sometimes do not register their variables as configuration items (e.g. the sout duplicate module). If you have a super-duper idea on how to improve this, you're welcome, but in the mean time... Signed-off-by: Rémi Denis-Courmont <rem@videolan.org> Vaguely-acked-by: Pierre d'Herbemont <pdherbemont@free.fr>
-
Jean-Paul Saman authored
-
André Weber authored
But its still very time critical, because paout gets sometimes empty so that aout_OutputNextBuffer(..) doesn't deliver new audiobuffers, sometimes it happens - that these buffers arrive very late for output. Reasons: -changed CPU load, (extra running application, also fast forward seeking and and jumping may lead to this situation.) Enhancement #897: added an option to let the user choose is prefered audio device. (needs restart of VLC to get applied)
-
Jean-Paul Saman authored
Signed-off-by: Jean-Paul Saman <jpsaman@videolan.org>
-
Jean-Paul Saman authored
Signed-off-by: Jean-Paul Saman <jpsaman@videolan.org>
-
Jean-Paul Saman authored
Don't leak memory when filling in p_stream->p_decoder_specific_info for subtitles. The p_stream->p_decoder_specific_info pointer was already allocated just before checking for VLC_FOURCC('s','u','b','t'). The fix moves the non-subtitles case to an else. Signed-off-by: Jean-Paul Saman <jpsaman@videolan.org>
-
Jean-Paul Saman authored
-
André Weber authored
This reverts commit 9438646c. wrong file in my list I'am sorry, and wrong file modes
-
André Weber authored
(but its still critical because it happens - aout_OutputNextBuffer(...) has no buffers available - sometime the output doesn't know until some ms before the last block has finished to play! so each little disturbtion of the CPU or load change leads to studdering/hickups) #897 enhancement: give the use the option to choose its prefered audio device, instead of useing Windows default
-
Pierre d'Herbemont authored
-
Pierre d'Herbemont authored
-
Rémi Duraffort authored
-
Rémi Duraffort authored
-
Pierre d'Herbemont authored
-
Rémi Denis-Courmont authored
This only affects people still not building from subdir. Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>
-