April 2014 - MPlayer-dev-eng - lists.mplayerhq.hu

Homepage skin download issue
by Ingo Brückl 09 Sep '15

09 Sep '15

Yesterday, I updated hwswskin to 1.3, but it still isn't downloadable. Is the generation of the skin download tarballs working? Ingo

3 8

[PATCH] mencoder slang vobsub fix
by Edward Batutis 09 Sep '14

09 Sep '14

Hi, This is my very first patch for mplayer/mencoder. This patch allows mencoder -slang <lang> <some video file> -vobsub <some sub/idx path> ... to select a language from a SUB/IDX combination. For example: mencoder -slang en /movie/my.avi -vobsub /movie ... where /movie contains a my.sub and my.idx. This will select language 'en' from the idx/sub. Without this patch you always get subtitle zero, whatever it may be. Why this wasn't fixed long ago - who knows. Mplayer does the right thing. Not mencoder. =Ed

2 4

[PATCH] Fix key_down_event SEGFALT
by spunit262 . 04 Sep '14

04 Sep '14

I discovered by messing around that using key_down_event with a large random value (ex SPACE | MP_NO_REPEAT_KEY) can cause a segfalt. I found the problem to be that isprint is only defined for values in the range of an unsigned char and the value EOF. The patch adds a simple check before isprint in mp_input_get_key_name to make sure the value is in isprint's range.

2 1

Danish translation ought to be renamed
by Ingo Brückl 14 Aug '14

14 Aug '14

Does anyone mind me renaming the Danish translation from help_mp-dk.h to help_mp-da.h and protocolling this in the Changelog? (AFAICS, there are no dependencies to be considered.) There is no ISO 639-1 language code "dk", Danish is "da". Ingo

2 2

[PATCH] use correct type of timestamps when recording from v4l2, fix #2176
by Jarek Czekalski 10 Jun '14

10 Jun '14

Mencoder should detect whether timestamps used by v4l2 come from monotonic or realtime clock. This is important for Linux kernels >=3.10. Details in bug report #2176 [1] Patch for stream/tvi_v4l2.c against r36970 attached. [1] https://trac.mplayerhq.hu/ticket/2176

2 2

[patch] RT subtitle timestamp parsing buggy
by hhaamu＠gmail.com 27 May '14

27 May '14

Hi The subtitle parser for .rt subtitles fails on hh:mm:ss and hh:mm:ss.ff type of timestamps and generally thinks they should all be displayed on the 0-second mark. This only happens when there is no 'end' attribute for the subtitles. For example, the following lines <time begin="01:39.40"/><clear/> It's different now. <time begin="00:02:14.7"/><clear/> Look... parse to [1]: 01:01:39.04 01:01:41.01 {~} It's different now. 00:00:02.00 00:00:08.00 {~} Look... The code is a long chain of sscanf() functions. There are two issues at play here: 1) sscanf sets a1, a2 etc even when the whole line does not match. The lines that try to parse begin/end tags will partially match and set those variables, leading to faulty timestamps. The variables should be reset to zero after each match attempt. 2) The line that tries matching for mm:ss timestamps actually matches more than it is supposed to. The mm:ss.ff and hh:mm:ss.ff lines are never run. Attached is a minimal patch that fixes these two issues. (It moves the problematic match downwards and resets the variables as necessary.) Other concerns relating to the surrounding code: 1) the 'len' variable sits completely unused and can be removed. 2) the timestamp calculation lines (a1*360000+a2*6000+a3*100+a4/10) assume that the fourth value parsed (a4) is in milliseconds. This assumption does not hold: the subtitle files I have are marked in tenths of a second. I'm not sure it can be fixed without rewriting the parsing code. [1] Incidentally, the -dumpjacosub option creates a dumpsub.jss file rather than the dumpsub.js file promised on the man page.

3 5

[PATCH] Expunge printf from vidix/
by Arne Bochem 17 May '14

17 May '14

While tracking down a case of "-really-quiet isn't really quiet" in #mplayer yesterday, I noticed that most vidix related code uses printf instead of mp_msg. The attached patch gets rid of printf in favour of mp_msg. It also adds proper module attribution to a few messages in vidix/ that were missing it (e.g. in vidix/drivers.c). Caveats: Most messages are MSGL_STATUS. This could use some more thought, but it should be an improvement anyway. Also, I can't really test the vidix code, but it compiles and I don't really see how this could have broken anything. Regards, Arne Bochem

3 4

[PATCH] mencoder: detect end of audio stream while encoded data still buffered
by Kieran Clancy 10 May '14

10 May '14

Changes to mencoder introduced by r36905 (2014-02-24; mencoder: Finish encoding only when audio and video reached EOF.) introduced a regression when using mp3lame and possibly other audio encoders. This was first reported by Alexander Roalter on mplayer-users: https://lists.mplayerhq.hu/pipermail/mplayer-users/2014-March/087288.html $ mencoder -msglevel all=6 -o out.avi -oac mp3lame -ovc lavc input ... (works normally until the end of the audio stream, but after the end of the video stream, an endless loop of messages begins:) ... ds_fill_buffer: EOF reached (stream: audio) ds_fill_buffer: EOF reached (stream: video) ds_fill_buffer: EOF reached (stream: audio) ds_fill_buffer: EOF reached (stream: video) ... After running a debugger, I found that the new code introduced by r36905 assumes that mux_a->buffer_len == 0 on end-of-stream, but it is often not the case for mp3lame (and probably other codecs). Due to technicalities in the way LAME works, it may generate a partial audio frame before the input stream ends, and mencoder lacks the architecture to request that audio codecs in this situation complete their partial frames on end-of-stream. I suspect other audio codecs have the same issue. In any case, the fix turned out to be very simple; there is no need to assume that mux_a->buffer_len is zero on end-of-stream. Even if there is outstanding data in mux_a->buffer, end-of-stream means it will never be muxed into the output because dec_audio() will not provide any more data for aencoder->encode(). Kieran Clancy --- mencoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

3 20

Fix libmpcodecs inline asm on ICL
by Matt Oliver 03 May '14

03 May '14

This is a patch to enable intel compiler on Windows to compile the libmpcodec inline asm functions. It is based of similar work previously done in FFmpeg (and in fact was initially posted there) and extends some previous patches that were applied to libmpcodecs a few months ago. This is required to compile ffmpeg under icl with asm and was previously posted (probably incorrectly) on the ffmpeg mailing list but im now posting it here in the correct location. Matt

2 5

Problems with flicker in AVIs using Intel Indeo (RT21) codec
by Mats Peterson 30 Apr '14

30 Apr '14

Hello. I have noticed that MPlayer causes heavy flicker when playing AVIs encoded with the Indeo (RT21) codec. A sample file is available at http://alicja.homelinux.com/~mats/stuff/INDEO2.AVI. Mats -- Mats Peterson http://alicja.homelinux.com/~mats/

1 1