May 2010 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] add support of compression algorithm 3 in mkv demuxer
by Alexander Beregalov 02 Jan '12

02 Jan '12

Specs from http://www.matroska.org/technical/specs/ : ContentCompAlgo The compression algorithm used. Algorithms that have been specified so far are: 0 - zlib, 1 - bzlib, 2 - lzo1x, 3 - Header Stripping. ContentCompSettings Settings that might be needed by the decompressor. For Header Stripping (ContentCompAlgo=3), the bytes that were removed from the beggining of each frames of the track. I have such file, it works for me. | + A track | + Track number: 2 | + Track UID: 2 | + Track type: audio | + Lacing flag: 1 | + Default flag: 1 | + Codec ID: A_AC3 | + Content encodings | + Content encoding | + Content compression | + Algorithm: 3 (header removal) | + Settings: length 2, data: 0x0b 0x77 See an attachment. Please comment.

7 21

New SSL certificate on mphq
by Måns Rullgård 09 Oct '10

09 Oct '10

The old, expired SSL certificate on https://mphq has been replaced. SHA1 Fingerprint=3E:95:E8:B4:E0:3F:EB:AD:5B:43:AD:7F:FA:26:CA:B5:2C:1B:AF:62 -- Måns Rullgård mans(a)mansr.com

2 1

[PATCH] Network synchronized playback using UDP
by Jason Holt 08 Sep '10

08 Sep '10

I hacked in a simple mechanism to synchronize playback between multiple instances of mplayer over a network. The master sends a UDP datagram to announce its position in the video each time it plays a frame. The slaves check to see if they're within epsilon of the master. If they are, they just advance by a frame. If not, they seek to where the master is. This works out nicely because I can dynamically tweak frame rate, seek and pause on the master and the slaves all follow along. The patch is not compliant with your coding standards. Before I do that work, I wanted to make sure it's a patch you're interested in, and see if you have any particular guidance on things I should move or change.

10 78

[PATCH] Fixing dvd:// support
by Olivier Rolland 02 Aug '10

02 Aug '10

Hi, Here are 3 patches to fix some issues in stream_dvd.c : - The first one fixes the incorrect assumption that the number of chapters of a DVD title is equal to the number of cells. - The second one improves seeking by chapters. The current code seeks to the starting position of the chapter. From this position, it then tries to figure out the starting cell. This is completely suboptimal and error prone since the starting cell can be directly deduced from the chapter. - The third one improves seeking by position. The current code takes the angle into account. This is a mistake since the position is independent of the angle. Please, apply the patches in order. Regards, Olivier

4 7

[PATCH] Coreaudio patches (audio device selection and deprecated functions)
by Adrian Stutz 12 Jul '10

12 Jul '10

Hello list, The ao_coraudio output has an issue on 10.6, loosing it's audio output whenever plugging/unplugging headphones. I was investigating the issue when I noticed a lot of deprecated functions in ao_coreaudio. The first patches replace those functions with their newer ones (which is pretty straight-forward because the functionality didn't change). I decided to split out repeated tasks into separate functions (like getting an array from the API) to simplify the code. Some of the functions where deprecated in 10.5, most in 10.6. All new functions are available in 10.4, which IIRC is the minimum requirement elsewhere already. coreaudio_1_UInt32_printf.diff > Change printf placeholders of UInt32 variables to PRIu32 (gcc was complaining about these) coreaudio_2_replace_deprecated_functions.diff > Replace all deprecated function calls with their new counterparts coreaudio_3_int_to_UInt32.diff > Correct use of int instead of UInt32 in two places The new functionality allows to select an audio device by its id, while the default and 0 selects the default device. It also sets the selected device as the current device, which makes ao_coreaudio correctly switch devices when default device is selected and changes. Selecting a specific device will stick to it. coreaudio_4_device_id_option.diff > Add the new option and correctly handle setting the default / a specific device. I wasn't able to actually verfiy SPDIF output apart from checking it produces noise on regular speakers so it would be great of someone could test that! Greetings, Adrian

7 21

[PATCH] mpg123 input decoder, for real now.
by Thomas Orgis 30 Jun '10

30 Jun '10

Hi, this is the current version of the mpg123 patch, including quite some preprocessor switchery to explore different variations of operation. I expect that to vanish after we settled on the best variant. It has been suggested that this version be merged and improved inside MPlayer SVN. The default setup is meant to work with any released mpg123 version since 1.x, while switching on of the callback API needs mpg123 1.12 (on and on x86-64 either a svn snapshot of mpg123 or disabling of _FILE_OFFSET_BITS). The current performance of mp3lib and mpg123 is under investigation, with funny effects on either side... hopefully we can settle that in the not too distant future. Alrighty then, Thomas.

2 1

[RFC][PATCH]removing gmplayer
by Anton Khirnov 12 Jun '10

12 Jun '10

Hi, i think it's time to finally remove gmplayer. It's ugly and unmaintained and apparently no devs even use it. People who ask for help in #mplayer are always just told to use SMPlayer or some other frontend. Also it seems that most its users simply don't know that there are other (much better) options than gmplayer. I'm attaching a patch that removes it, except for the 'svn rm gui/' part, because it'd make the patch too big. Comments? Anton Khirnov

10 20

[PATCH] x264encopt accepts x264 preset/tune/profile , noturbo
by Micha 11 Jun '10

11 Jun '10

Hello everyone, i came across the problem, that the option "b_pyramid" in -x264encopts led to an abort of mencoder when using the very high quality options from the mplayer documentation. something like: subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b When i asked in the channel why this is, i acknowledged that mencoder is lacking not only the new semantics of b_pyramid, but also new x264 features like presets and tunes. According to the steps mentioned in x264.h I changed the code in x264enc_set_param() to set default settings by accepting presets/tunes and, (new) ignore the turbo setting for the 1st pass in multi-pass mode if the new option "noturbo" is specified. Otherwise the "turbo" options are automatically set by libx264. It's not very much, but I think this complies to the libx264 interface. There are probably more points in this code to be reconsidered, but I just wanted to provide a working version to use presets. Please take into account, that this is my first contribution and that I, most likely, made some formal errors and/or wrote poor C code. The patch also includes some changes for the english manpage with some notes on presets/tunes and the change of turbo to noturbo. But this should seriously be made by someone who knows what he or she is talking about (like the section for b_pyramid) and not by me :) Cheers, Michael

3 7

removing libmpcodecs/vf_rbg2bgr.c
by Attila Kinali 11 Jun '10

11 Jun '10

Moin, As with -vf yuy2, -vf rgb2bgr seems to be superceeded by sws a long time ago. As it does use sws internal sysmbols (like vf_yuy2.c) which prevents compilation with ffmpeg as shared lib, we propose to remove it too. Patch attached Attila & Reinhard

7 16

Really nasty quick hack for making mp3lib faster...
by Thomas Orgis 11 Jun '10

11 Jun '10

Hi, the discussion about the upcoming mpg123 patch brought some funky performance issues to the light, namely the mp3lib internal code changing performance when changing the ad_mpg123.c code. We've seen something like that before in mpg123 ... this is an accidental alignment issue. Recap of the issue: One version of libmpcodecs/ad_mpg123.c caused that measurement (Linux/x86-64, Core2Duo P8600): mplayer-svn$ for i in mpg123 mp3; do echo $i; time ./mplayer -ao pcm:file=/dev/null -quiet -ac $i ../../convergence_-_points_of_view/*.mp3 > /dev/null ; done mpg123 real 0m6.173s user 0m6.107s sys 0m0.051s mp3 real 0m5.823s user 0m5.769s sys 0m0.042s Another version triggered that: mplayer-svn$ for i in mpg123 mp3; do echo $i; time ./mplayer -ao pcm:file=/dev/null -quiet -ac $i ../../convergence_-_points_of_view/*.mp3 > /dev/null ; done mpg123 real 0m6.195s user 0m6.127s sys 0m0.048s mp3 real 0m6.372s user 0m6.306s sys 0m0.050 Now... there is an easy hack to keep mp3lib's performance high: Make the static memory in there aligned to 64 bytes. mplayer-svn$ perl -pi -e 's:aligned$\d+$:aligned(64):g' mp3lib/*.c And observe: mplayer-svn$ for i in mpg123 mp3; do echo $i; time ./mplayer -ao pcm:file=/dev/null -quiet -ac $i ../../convergence_-_points_of_view/*.mp3 > /dev/null ; done mpg123 real 0m6.200s user 0m6.146s sys 0m0.040s mp3 real 0m5.818s user 0m5.770s sys 0m0.039s Nifty, eh? My changes in other parts of the mplayer binary apparently caused accidental increase in alignment of some data structures. Now I only need to revisit mpg123 again to see if we still have something left to do in that direction. We already align dynamic memory at 64 bytes, but there may still be some optimization left to do. Especially since we really got some improved SSE2 code going on there that should show some benefit from mp3lib. And now ... I'll leave you to wonder about what other codecs might be affected by that;-) Alrighty then, Thomas.

2 2