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

[PATCH] vo_udp.c udp streaming support
by Dirk 07 Mar '02

07 Mar '02

Oooops.. forgot the "[PATCH]" in the subject.. This is the first hack and was only tested with Linux so far... everything belongs to main/libvo/ of current CVS version... just start mplayer -vo udp movie and (for example) mtvp udp:1234 and you'll see what it does.. port 1234 is still hardcoded via #define in libvo/vo_udp.c... Dirk =================================================================== RCS file: /cvsroot/mplayer/main/libvo/Makefile,v retrieving revision 1.30 diff -u -r1.30 Makefile --- Makefile 9 Feb 2002 01:30:35 -0000 1.30 +++ Makefile 7 Mar 2002 11:22:10 -0000 @@ -3,7 +3,7 @@ LIBNAME = libvo.a -SRCS=aspect.c aclib.c osd.c font_load.c video_out.c vo_null.c vo_pgm.c vo_md5.c vo_mpegpes.c x11_common.c vo_yuv4mpeg.c $(OPTIONAL_SRCS) img_format.c sub.c +SRCS=aspect.c aclib.c osd.c font_load.c video_out.c vo_null.c vo_udp.o vo_pgm.c vo_md5.c vo_mpegpes.c x11_common.c vo_yuv4mpeg.c $(OPTIONAL_SRCS) img_format.c sub.c OBJS=$(SRCS:.c=.o) ifeq ($(VIDIX),yes) Index: video_out.c =================================================================== RCS file: /cvsroot/mplayer/main/libvo/video_out.c,v retrieving revision 1.42 diff -u -r1.42 video_out.c --- video_out.c 22 Feb 2002 18:00:38 -0000 1.42 +++ video_out.c 7 Mar 2002 11:22:10 -0000 @@ -66,6 +66,7 @@ // // Externally visible list of all vo drivers // +extern vo_functions_t video_out_udp; extern vo_functions_t video_out_mga; extern vo_functions_t video_out_xmga; extern vo_functions_t video_out_x11; @@ -159,6 +160,7 @@ // &video_out_odivx, &video_out_pgm, &video_out_md5, + &video_out_udp, &video_out_mpegpes, &video_out_yuv4mpeg, #ifdef HAVE_VESA

1 0

[PATCH] DOCS/bugreports.html
by Diego Biurrun 06 Mar '02

06 Mar '02

Hi Gabucino and team! I just finished "porting" Daniel Egger's version of bugreports.html. The patch has no cosmetic changes to HTML tags and should satisfy your requirements. It is basically your version of the file with Daniel's text and my corrections. Please apply this patch. Let me know if you want any modifications. Regards Diego

1 0

Re: [Mplayer-cvslog] CVS: main/libmpcodecs vd_qtrpza.c,1.1,1.2
by Roberto Togni 06 Mar '02

06 Mar '02

On 2002.03.06 16:25 Arpi of Ize wrote: > Update of /cvsroot/mplayer/main/libmpcodecs > In directory mplayer:/var/tmp.root/cvs-serv28832 > > Modified Files: > vd_qtrpza.c > Log Message: > optim :) > > Index: vd_qtrpza.c > =================================================================== > RCS file: /cvsroot/mplayer/main/libmpcodecs/vd_qtrpza.c,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- vd_qtrpza.c 2 Mar 2002 22:08:19 -0000 1.1 > +++ vd_qtrpza.c 6 Mar 2002 15:25:10 -0000 1.2 > @@ -60,7 +60,7 @@ > } > > qt_decode_rpza(data, len, mpi->planes[0], sh->disp_w, sh->disp_h, > - ((mpi->imgfmt&255)+7)/8); > + mpi->bpp/8); I think it can give problems with BGR15 modes: 15/8 = 1, while BGR15 takes 2 bytes. It should be (mpi->bpp+7)/8. Probably adding 1 would be enough, but 7 is worst case. > > return mpi; > } > Ciao, Roberto

2 2

Patch for hiding subtitles
by Alexandr Kara 06 Mar '02

06 Mar '02

Hello, I am sending a patch to show/hide subtitles during movie playback. I do this using the new configurable key bindings and didn't add a default binding, so if anyone doesn't want to use it, it does no harm to him. Have a nice day, Alexandr Kara

2 1

First example for documentation in DocBook/SGML
by Daniel Egger 06 Mar '02

06 Mar '02

Hija, as requested and promised here's a first DocBookised version of bugreports.html in SGML. While it is perfectly valid DocBook and will compile fine with the DocBook tools and Jade this is not quite optimal code as it's not making use of much markup yet. I just wanted to toss it out because I've got a flu and didn't want to wait you for too long. -- Servus, Daniel

1 0

solved: wrong aspect ratio with xv driver
by Nilmoni Deb 06 Mar '02

06 Mar '02

Hi all, I have found a solution to the fullscreen mode problem with xv driver (when compiled with --enable-gui but not run with gui). This problem has been reported in: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2002-March/005887.html http://mplayerhq.hu/pipermail/mplayer-dev-eng/2002-March/005932.html Here is the patch -> --- libvo/vo_xv.c Tue Mar 5 22:54:59 2002 +++ libvo/vo_xv.c.new Tue Mar 5 23:01:04 2002 @@ -37,6 +37,7 @@ #include "fastmemcpy.h" #include "sub.h" #include "aspect.h" +#include "../mplayer.h" #include "../postproc/rgb2rgb.h" @@ -495,7 +496,7 @@ current_buf=0; #ifdef HAVE_NEW_GUI - if ( vo_window != None ) + if ( vo_window != None && use_gui) { mFullscreen=0; dwidth=mdwidth; dheight=mdheight; The above patch works during runtime for both gui and no-gui. thanks - Nil

3 3

Fwd: solved: wrong aspect ratio with xv driver (fwd)
by Felix Buenemann 05 Mar '02

05 Mar '02

---------- Forwarded Message ---------- Subject: solved: wrong aspect ratio with xv driver (fwd) Date: Tue, 5 Mar 2002 12:36:04 -0500 (EST) From: Nilmoni Deb <ndeb(a)ece.cmu.edu> To: Felix Bnemann <removed private email> Hi Felix, I tried to post this to the list but it hasn't appeared there yet. Is something wrong with the mail server ? thanks - Nil ---------- Forwarded message ---------- Date: Tue, 5 Mar 2002 11:40:56 -0500 (EST) From: Nilmoni Deb <ndeb(a)ece.cmu.edu> To: mplayer-users(a)mplayerhq.hu Subject: solved: wrong aspect ratio with xv driver Hi all, This is a followup of my post in http://mplayerhq.hu/pipermail/mplayer-users/2002-March/011747.html The following is a portion (see line numbers on the left) of libvo/vo_xv.c . 497 #ifdef HAVE_NEW_GUI 498 if ( vo_window != None ) 499 { 500 printf("mFullscreen=%d flags=%d vo_window=%d\n",mFullscreen,flag s,vo_window); 501 mFullscreen=0; 502 dwidth=mdwidth; dheight=mdheight; 503 if ( ( vo_dwidth == vo_screenwidth )&&( vo_dheight == vo_screenh eight ) ) 504 { 505 mFullscreen=1; 506 dwidth=vo_screenwidth; 507 dheight=vo_screenwidth * mdheight / mdwidth; 508 } 509 } 510 #endif I have added line 500 for debugging. The output of that is: mFullscreen=1 flags=1 vo_window=4194305 which shows the correct value of mFullscreen for the xv driver with "-fs" option. The part where it goes wrong is in line 501. Since I compiled with gui enabled, this ifdef is active. But I am *not* running mplayer with gui ('mplayer -gui') which means this ifdef block should not be executed in this case. The solution is to check if the gui window has been created and use that as a check. In short the line: 498 if ( vo_window != None ) should be replaced by something like: 498 if ( vo_window != None && gui_window != None) where gui_window is the window of the gui interface (I don't know what the exact name of that variable is so I can't call it a patch yet). I did a quick hack (commented line 501) and the problem of wrong aspect ratio with xv driver in fullscreen mode immediately vanished. This proves the problem is somewhere there. thanks - Nil ------------------------------------------------------- -- MfG, Felix

2 1

skipped frames problems
by Charles Henrich 05 Mar '02

05 Mar '02

in raw capture mode (and I've seen it in divx mode when inserting zero len packets into the queue) the playback will not actually play the frame but instead show what appears to be random memory locations. Arpi, I tried the patch you suggested, but it still fails. I'e uploaded a 3 frame test file skippedf.avi that you can play with -loop to see the problem.. -Crh Charles Henrich henrich(a)msu.edu http://www.sigbus.com:81/~henrich

1 0

demuxer demux
by Arpi 05 Mar '02

05 Mar '02

Hi, Is it in CVS and working? I mean, is it already possible to play video from file A, and audio from file B and have them synced? I thought it's already done, but just read on mplayer homepage that it's not available !???.; A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu

2 1

Re: [PATCH] Development (Was: Clean up demuxers)
by Daniel Egger 05 Mar '02

05 Mar '02

Hija, since many people bitched about broken threads (hey, what about bitching about the unkosher no-CC: rule?) I subscribed to the list and thus this is the last broken mail from me here. <lots of bitching skipped> > it may help on few specific architecture (non-x86) in inner loops, Yes, it does. Quite a lot in fact since many have some sort of decrement and jump if non-zero mnemonic which is quite efficient. > but the return value (flag, can be -1, 0 1) of demuxer read is not the place > where changing it to unsigned help... I see. Didn't realise that it can be negative also. Why's that BTW? > but why shoudl we put it into cvs??? > if you wnat to find referers, change it in your tree. If it makes you happy I'll stick to that. > i still say: placing static arrays in header files is a VERY BAD IDEA. > also gcc says tat, yo ushould know :) Has it's uses, but in this case you're right. > the way you used is bad, it's a bit better than switch(){} but if we change > it, then change it to the right solution: single function pointer set by > demux_open. Iff you can find a good place where you can setup the pointer it's okay. I've to dig more through the source though to find one without loosing flexibility wrt alternative implemenations. > we won't accept cosmetics patches. so if you can't do more, don't do. > if you don't like indenting or other views of current source, it is YOUR > problem. everyone ha sits coding style, and we won't accept patches changing > it. We're not talking about STYLE here. Code like: if(! IS_RUNNING(config)) { if(strcasecmp(opt,"vcd") == 0) { char* s; if(!param) return ERR_MISSING_PARAM; s = (char*)malloc((strlen(param) + 6 + 1)*sizeof(char)); sprintf(s,"vcd://%s",param); entry = play_tree_new(); play_tree_add_file(entry,s); free(s); } else if(strcasecmp(opt,"dvd") == 0) { is a punishable offense in a few countries. If you cannot accept cleanup to such a evil (and probably buggy - I wouldn't even dare to run a checker when I see this) codefragment it's probably not the right project to participate for me. That's what I was talking about in the first place. > and renaming variables is really not welcomed. it makes impossible to > replace demuxer.c with older version, or even merge with developers > branches. it's simply codmetics change and won't be allowed here. So you have troubles using development tools? Say it so and I might be able to live with that. Otherwise this is simply FUD. > ... and when you want to call type=2 demuxer's read you cann array[2]. > insteda, why don't you set up a single function pointer when opens teh > demuxer (so demuxer type=2 could set ptr=ptr2, type=5 set ptr=ptr5 etc). > i'm sure it's faster than indexing an array and THEN referencing the func ptr Yes, you're right. It's pretty clear now; just had troubles to grok your language, sorry. It's not necessarily faster BTW, but then again my statement above applies here. Albeu wrote: > Critics are in the other thread (if we can call this a thread), I agree at 100% with > Apri and I try to say the same thing about how you should do. Explain ? Here : > typedef int (demx_fill_buffer_func*)(demuxer_t* demux, ....other args....); > struct demuxer_t { > ...... > demux_fill_buffer_func fill_buffer; > demux_seek_func seek; > ...... > } > Then in demux fill : > demuxer->fill_buffer(demuxer,ds); Got it. The problem I originally had still applies though: To make this (or mine) code work I had to equalise the parameters of all functions which means additional parameter tossing even for demuxers which don't need them and thus unnecessary overhead. Ideally there should only be one pointer which is passed over to the demuxers to not loose performance and keep it clean but therefor I would either need to add an additional pointer to demuxer_t which carries the stream_t (or whatever it is called) or the other way round but I've no idea which way is better or if it's even possible to derive one from the other; The code suggests that this is possible for a few demuxers because they already do it but if someone can enlighten me, I'd be really grateful. -- Servus, Daniel

20 110