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

v4l2 capture dependence on audioset
by Jesse Allen 08 Mar '06

08 Mar '06

What's the status of this patch? http://mplayerhq.hu/pipermail/mplayer-dev-eng/2006-February/040744.html

2 1

MPlayer coverity scan
by Ismail Donmez 07 Mar '06

07 Mar '06

Hi, Coverity has scanned many open source programs and mplayer is one of them. Any mplayer developer can register and check for the found problems. Please see http://scan.coverity.com/ . Also note that mplayer has less reports compared to xine ;-) Regards, ismail

2 2

LamaBox First Contact
by potappel＠lamabox.com 07 Mar '06

07 Mar '06

Dear Mplayer Team, We are using mplayer in our LamaBox, try Google ;-) We like to donate and need support. Is this possible? Best Regards, Martin Potappel potappel(a)lamabox.com www.lamabox.com

3 2

old CVS repositories
by Diego Biurrun 06 Mar '06

06 Mar '06

Hi, I'm converting the old CVS repositories to Subversion one by one. I have already converted homepage, uha, vesautils, mndiff, nut, homepage and today skins. Still missing are mplayerosx (should be finished this week), ffmpeg and main. There are a few old CVS modules where we need to decide if they are worth converting, namely 0_90 g2 installer obsolete test You can get them with cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/mplayer co <module> Let me know what you think. Diego

5 10

http stream basic auth base64_encode() fix
by Jeff D'Angelo 06 Mar '06

06 Mar '06

So that it conforms to RFC 2045: <http://jeffdangelo.org/patches/> MPlayer-1.0pre7try2.http_basic_auth_base64_encode.patch MPlayer-cvs-main-20060228.http_basic_auth_base64_encode.patch The two patch files are the same patch, but diffed against each of MPlayer-1.0pre7try2 and today's main CVS copy, libmpdemux/http.c version 1.34; both work equally well with the line offsets. These were done diff -r -u, let me know if you prefer -c format. Tested successfully against an Icecast 2.2.0 server (Otto Audio Jukebox). Let me know if you need anything else. -- Jeff

4 5

Re: [MPlayer-dev-eng] http stream basic auth base64_encode() fix
by Jeff D'Angelo 06 Mar '06

06 Mar '06

On Tue, 28 Feb 2006, Jeff D'Angelo wrote: > On Tue, 28 Feb 2006, Dominik 'Rathann' Mierzejewski wrote: > > > On Tuesday, 28 February 2006 at 19:15, Jeff D'Angelo wrote: > > > On Tue, 28 Feb 2006, Dominik 'Rathann' Mierzejewski wrote: > > > > > > > On Tuesday, 28 February 2006 at 18:15, Jeff D'Angelo wrote: > > > > > So that it conforms to RFC 2045: > > > > > > > > > > <http://jeffdangelo.org/patches/> > > > > > MPlayer-1.0pre7try2.http_basic_auth_base64_encode.patch > > > > > MPlayer-cvs-main-20060228.http_basic_auth_base64_encode.patch > > > > > > > > > > The two patch files are the same patch, but diffed against each of > > > > > MPlayer-1.0pre7try2 and today's main CVS copy, libmpdemux/http.c version > > > > > 1.34; both work equally well with the line offsets. These were done diff > > > > > -r -u, let me know if you prefer -c format. > > > > > > > > We prefer -u, thanks. > > > > > > [...] > > > Password was so chosen, so that: > > > > > > a) total number of characters (username, ':', password) % 3 = 1, thus > > > the basic auth base64 encoding would end in two '=' chars > > > > > > b) '?' and '>' chars were placed at end of base64 encode input > > > octet tripplets so that I could demonstrate the '+' and '/' > > > characters in the encoding > > > > > > Let me know when you are done testing. > > > > I can confirm that with this patch, authentication does indeed work with > > that server, while it doesn't without it. > > > > However, using http://user:pass@url/ syntax still doesn't work. Could you > > look at that, while you're at it? > > It seems the '>' is being mangled, perhaps by something doing a URL > encode. I'll take a look tonight. Yes, this is actually a different bug. I believe the patches I and Reimar suggested fix the base64_encode() bug for all cases. It was the url_new() function in libmpdemux/url.c as called by open_s1() in libmpdemux/http.c, which converts the url string (be it passed on the command line or in a .pls file) into a URL_t struct that also passes the username and password through url_escape_string() while they are still in the URL. Chars such as '>' are URL encoded to chars like '%3E'. No attempt is made to decode them. My first instinct was to pull them out of the URL before the encoding process. I figure only the part of the URL after the first slash (filepath, query, etc) need the encoding in any sane case; can't imagine any scheme (protocol) that would need it, nor DNS or IP (v4, v6) that would need it either. However, after reviewing RFC 2396 section 2.4.2, it sounds as it may be best to leave them encoded in the URL and then decode them as they are pulled out to keep to the spirit of the RFC. The enclosed patch file decodes the username and password before adding them to the respective members of the URL_t type struct that is returned from url_new(). Certainly there may be more efficient ways of doing this, such as passing the length of the part of the url string (e.g. the int len and len2 vars on lines 87 and 102 after patch) into url_unescape_string() to avoid the temp vars. I can provide a patch for that too if that or another way is preferred. The "yortwer" account mentioned earlier is still active and you are still welcome to test against it. With this patch, the following cases appear to work fine (tested against the Icecast server and while retrieving "static" media from an Apache server): 1) when either, both or neither of the username and/or password contain characters that would be encoded in a URL, e.g. "?a0>Belo" 2) when either, both or neither of the username and/or password contain characters already encoded in a URL, e.g. username "%79ortwer" 3) when the password is a null string: a) http://username:@host/ b) -playlist playlistfile.pls containing http://username:@host/ c) -user username -passwd '' 4) when the password is not present: a) http://username@host/ b) -playlist playlistfile.pls containing http://username@host/ c) -user username A packet sniff revealed the proper username:password pair encoding each time and the servers responded favorably. Let me know if there's anything else you'd like from me. Thanks. -- Jeff > > I've checked the relevant RFC and it looks like your patch is correct. > > > > I'd say it's good to commit as long as you remove your name from the > > comments. Don't worry about attribution, it'll go into the CVS log. > > No prob. Just new to the protocol :). > > <http://jeffdangelo.org/patches/MPlayer-cvs-main-20060228.http_basic_auth_ba…> > has been updated. > > > And since this fixes half of http://bugzilla.mplayerhq.hu/show_bug.cgi?id=390, > > it will probably be mentioned in the ChangeLog as well. > > > > > Thanks for the quick response! > > > > You're welcome. > > > > R. > > > > -- > > MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ > > There should be a science of discontent. People need hard times and oppression > > to develop psychic muscles. > > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > > > > _______________________________________________ > > MPlayer-dev-eng mailing list > > MPlayer-dev-eng(a)mplayerhq.hu > > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng > > > > _______________________________________________ > MPlayer-dev-eng mailing list > MPlayer-dev-eng(a)mplayerhq.hu > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng >

2 1

mplayer/mencoder audio pts support
by John Koleszar 05 Mar '06

05 Mar '06

Hi all, Continuing along the lines of Corey's dwStart support, I think this issue has broader scope on the decode side of things. I've yet to find a way to handle files that have these kind of delayed streams in pts based containers (asf in my case, will probably be an issue with nut too). I've played with the autosync stuff, and I've hacked around with some of the audio delay code similar to the dwStart support, and I can't get the behavior I expect. My guess is that it's not really a sync issue (ie, hypothetical metric audio_samples/frame is correct & constant) just the streams are played offset by a constant amount. Overspeeding the video isn't an acceptable way to make up this large of an offset. The dwStart behavior seemed like the right route to go, but I couldn't make it work. Maybe I just had the semantics wrong, so if that should do what I want, please say so. Specifically, the first video packet in my file has a pts of 5s and the first audio packet has a pts of 9s. The proper behavior for this file would be to start the video immediately, and then start the audio after 4 seconds. Yes, I know this is a contrived example, and it's obviously not common (at least with delays on this order of magnitude) in the wild. Best real world use case I can imagine is short voice-overs with long periods of silence in between. However contrived this example is, I want it to play properly, and am willing to put the work in to fix it. I wanted to get some discussion going on this list to make sure I fix it correctly. Can pts be relied upon to be valid from all demuxers? Or is pts not the way to go? Comments/caveats/suggestions accepted... Thanks.. John

3 2

dwStart and what mencoder generates
by Michael Niedermayer 04 Mar '06

04 Mar '06

Hi a file generated with mencoder ... -ovc copy -oac copy -audio-delay 10 -o test.avi doesnt look good at all, the packets are not interleaved correctly, they are 10sec appart ... note, mencoder might be a few weeks behind cvs ... -- Michael

3 5

fbdev and odd width
by Alan Curry 03 Mar '06

03 Mar '06

If a video has an odd width, vo_fbdev and vo_fbdev2, when centering it on the screen, use a starting position that is on an odd byte, halfway between pixels. Try it in 16bpp for most impressive demonstration. -vf scale=199:-2 -vo fbdev -vm -fbmode 640x480-60 -bpp 16 "The colors, children!" -- Prof. Frink This patch guarantees that the starting position for the image is a multiple of fb_pixel_size by switching the order of the /2 and the *fb_pixel_size Index: libvo/vo_fbdev.c =================================================================== RCS file: /cvsroot/mplayer/main/libvo/vo_fbdev.c,v retrieving revision 1.93 diff -u -r1.93 vo_fbdev.c --- libvo/vo_fbdev.c 17 Feb 2006 03:49:33 -0000 1.93 +++ libvo/vo_fbdev.c 2 Mar 2006 22:22:44 -0000 @@ -1005,8 +1005,9 @@ return 1; } - center = frame_buffer + (out_width - in_width) * fb_pixel_size / - 2 + ( (out_height - in_height) / 2 ) * fb_line_len + + center = frame_buffer + + ( (out_width - in_width) / 2 ) * fb_pixel_size + + ( (out_height - in_height) / 2 ) * fb_line_len + x_offset * fb_pixel_size + y_offset * fb_line_len; mp_msg(MSGT_VO, MSGL_DBG2, "frame_buffer @ %p\n", frame_buffer); Index: libvo/vo_fbdev2.c =================================================================== RCS file: /cvsroot/mplayer/main/libvo/vo_fbdev2.c,v retrieving revision 1.8 diff -u -r1.8 vo_fbdev2.c --- libvo/vo_fbdev2.c 17 Feb 2006 03:49:33 -0000 1.8 +++ libvo/vo_fbdev2.c 2 Mar 2006 22:22:44 -0000 @@ -280,8 +280,9 @@ } } - center = frame_buffer + (out_width - in_width) * fb_pixel_size / - 2 + ( (out_height - in_height) / 2 ) * fb_line_len; + center = frame_buffer + + ( (out_width - in_width) / 2 ) * fb_pixel_size + + ( (out_height - in_height) / 2 ) * fb_line_len; #ifndef USE_CONVERT2FB if (!(next_frame = (uint8_t *) realloc(next_frame, in_width * in_height * fb_pixel_size))) {

2 1

Hangs when calling mplayer by using java (getruntime.exec())
by Shinye Shinye 03 Mar '06

03 Mar '06

I don't know why the mplayer will hangs after a few sec when i use java getRuntime.exec() to call the mplayer. Anyone can help?? I am using Red hat 9 shrike

4 5