March 2006 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] tv color controls
by Alban Bedel 27 Mar '06

27 Mar '06

Hi, currently the tv color controls can't be really used interactivly. Their is some commands to change them but they are not bound by default, and it is imho a bit awkward to have 2 different set of controls. So here is my take at the problem. This patch first add a function to the tv api to query the current color settings and fix tv_set_colors_options() to give a correct return value (and not success in all case). Then it fix the v4l input to avoid rounding problems when converting from the internal v4l range (0/65535) to mplayer's range (-100/100). Currently the v4l driver use a 2nd order polynomial to convert the contrast value, that seems totaly useless and it would make the back conversion a pain. So i changed it to use the same linear approximation as all the other color controls. Finnaly it add the needed code to the color control property and a bunch of options to control the behaviour. -notv-colors disable the whole thing giving the old behaviour. -notv-contrast, -notv-hue, etc disable single controls, this can be needed if the card/driver is buggy or too limited (like v4l who can't report that it doesn't support a specific control). Albeu

3 10

[PATCH] [RFC] rename default skin directory
by Diego Biurrun 27 Mar '06

27 Mar '06

Hey, I've always disliked the fact that gmplayer looks in subdirectories named 'Skin' for skins. Capitalized names feel very non-Unixish to me and it's a bit misleading as well, since the directory can contain multiple skins and not just one. So the attached patch changes this behavior in a backwards-compatible fashion. It's not very elegant, but tested to work. Comments, thoughts? Diego

4 8

[PATCH] libmpdemux/aviprint.c printf --> mp_msg
by Diego Biurrun 27 Mar '06

27 Mar '06

Hi, While cleaning up some of the trees I have lying around I stumbled across this printf to mp_msg conversion I had done a long time ago. Are the MSGT_ and MSGL_ I chose OK? Scheduled for commit during the next week. Diego

3 8

[PATCH] Faad update
by Roberto Togni 27 Mar '06

27 Mar '06

Hi Attached patch faad_update.diff syncs our internal faad copy with faad2 CVS snapshots from 20060915. No changes involving the files that we are using were applied to faad cvs before the license change on 20050201. After the license accident the main changes are a fix for a crc somewhere in bits.h and some DRM changes in decoder.c. Main changes: - added files drm_dec.c and drm_dec.h for DRM (Digital Radio mondiale) - removed all the unused sse coded - some cosmetics - added a case for fft128 - many changes to HCR (Huffman Code Reordering for AAC spectral data, related to error resilience) - some changes in huffman.c for LAV (Largest Absolute Value) - SBR fixes - some changes to fixed-point code The second attached file (faadchanges) is a cleaned-up patch that includes only the functional changes (no cosmetics, no sse removal, no header id update for unchanged files, ...). This probably does not even apply, use it for review only. It works for me, please review and test it. Ciao, Roberto

4 7

[PATCH] Fix real a/v sync
by Roberto Togni 26 Mar '06

26 Mar '06

Hi. This fixes a/v sync for all my broken samples, and did not break some others i tested. Real a/v sync should be done on timestamps, not on video framerate. Please test it, i plan to apply it soon Ciao, Roberto

2 3

[PATCH] vidix makefile and paralle build
by Alban Bedel 26 Mar '06

26 Mar '06

Hi all, their is a little quirk in the vidix Makefile that make parelle build suboptimal. First problem is the DO_MAKE macro, it call make on all subdirs. The problem is that this is done in a shell loop, so make can't detect that the job is another make. As their is only one subdir that macro seem pretty useless, so i simply removed it. Another pb is the 'all' rule where DO_MAKE is used as target preventing building the library and the drivers in parallel. The patch add an extra rule to build the drivers and put it as prerequisite for "all". The same thing could be done for the other rules but it's probably not really worse the kludge in the makefile. Albeu

2 5

[PATCH] OSD tinting for vo_gl
by Tomas Janousek 26 Mar '06

26 Mar '06

Hello, my friend asked me if it's possible to change the OSD color. I found that the osd is stored in greyscale, so I wrote a tinting patch for one particular vo. Maybe someone is interested in it. Greetings, -- .--------- Tomáš Janoušek a.k.a. Liskni_si ---------. : NOMI team, developer, http://tomi.nomi.cz/ tomi(a)nomi.cz : ' JID:liskni_si@jabber.cz, ICQ#161807083, tel:+420608876277 '

3 7

[PATCH] libavcodec/libpostproc not cleaned
by Derek E. Lewis 26 Mar '06

26 Mar '06

As the subject states, libavcodec/libpostproc is not cleaned during a distclean, leaving around *.a and *.o files. This is bad for those of us that share a single MPlayer source tree between multiple architectures (and it's just annoying, period), as the build will try and link against those *.a and *.o files in libpostproc, which were built for a different arch. I talked briefly with Diego in #mplayerdev, and we agreed that the MPlayer Makefile would be a good place to clean libavcodec/libpostproc from. The PARTS variable looks like an adequate place to throw it. I'm still wondering if this is not an ffmpeg issue, though? Derek E. Lewis dlewis(a)solnetworks.net http://riemann.solnetworks.net/~dlewis

3 4

h264+aac in lavf mp4
by Erik Slagter 26 Mar '06

26 Mar '06

Hi, Just, asking, is putting h264 and aac in mp4 using the lavf muxer mp4 supposed to work at the moment, or maybe it's known broken? Some additional info: when I try this, the resulting file plays only audio in mplayer, video says: "Error while decoding frame". I must admit this an improvement since Michael's audio chunk patch, because the audio now works. If I do exactly the same, but choose avi as container, all is OK... I was testing with b frames forced to 0, btw. Afaik there is an issue with the lavf muxer and b frames, are there more known issues in this area?

8 42

Please add 0x2033504D in ffmp3 codecs.conf file
by Andrea Palmatè 25 Mar '06

25 Mar '06

Since it work correctly, it is possible to add 0x2033504D into codecs.conf? Thank you Andrea Palmatè http://www.amigasoft.net

3 3