July 2003 - MPlayer-G2-dev - lists.mplayerhq.hu

pre37 released
by Arpi 27 Jul '03

27 Jul '03

Hi, http://mplayerhq.hu/~arpi/g2/mplayer-G2-preview37.tar.gz pre37: - vf_madei: config support, blurring (noise removal) before motion detection - IPB codecs in AVI container resulting bad PTS order fixed - libmpeg2 crash at seek fixed (but no I frame / keyframe search yet) - mpeg demuxer: using ds packet for ES video, support for layer 1, 2 audio - mp3lib: layer-1 support (backport from main) - vo_fbdev.c, with v-synced triple buffering support - DOCS/video.txt A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

1 0

Question for Arpi :)
by Andriy N. Gritsenko 26 Jul '03

26 Jul '03

Hi there! Could you point me to detailed description of new VF API? I don't want to make mistakes so I want description of all API functions. :) Anyway it will be good to have all API described, not only libvo and cfg in DOCS but all APIs. :) With the best wishes. Andriy.

3 8

New libao2
by Anders Johansson 25 Jul '03

25 Jul '03

Hi, I've been working on the new audio I/O library a bit. Can't get the sync to work, but I will continue to work on it. I will also implement the new config system (not done yet). Anyway just wanted to show what I have done to see what you think of it. The source I have been working on is from version 33 (I think). down load it from: www.watri.org.au/~ajh/mplayer-g2-newaio.tar.gz Cheers, //Anders

3 6

Fwd: Re: 2.4.20 matrox_crtc2.c bug (ioctl FBIOPAN_DISPLAY)
by Arpi 24 Jul '03

24 Jul '03

--------- Forwarded message --------- From: "Petr Vandrovec" <VANDROVE(a)vc.cvut.cz> To: Arpi <arpi(a)thot.banki.hu> Subject: Re: 2.4.20 matrox_crtc2.c bug (ioctl FBIOPAN_DISPLAY) On 24 Jul 03 at 3:49, Arpi wrote: > > return -EINVAL; > > if (con == m2info->currcon) > > matroxfb_dh_pan_var(m2info, var); > > dsp->var.xoffset = var->xoffset; > > dsp->var.yoffset = var->yoffset; > > > > like driver does everywhere else. > > :) > > I assume you'll submit this patch to mainstream kernel... Maybe... > > For 2.6.x you can do FBIO_WAITFORVSYNC ioctl, as I finally took Syrjala's > > patch, extended it to handle both CRTC and put into the driver. > > I know his patch, but it makes apps blocking until vsync arrives. > It may work for multithreaded apps (blocking only the display thread), > but for mpalyer (which runs in single thread) it's just eating cpu :( if (!fork()) { ioctl(FBIO_WAITFORVSYNC); ioctl(FBIO_PANDISPLAY); exit(0) ;-) I'm not sure how fast it is... > > Supporting FB_ACTIVATE_VBL for setting videomode is impossible (due to > > connection to the tty subsystem), but if you can find somewhere (or if > > you can persuade me that API author thought it that way) > > that FB_ACTIVATE_VBL should be looked at for panning too, then it is > > definitely (very) simple to extend 2.6.x matroxfb to do that. > > The strange thing is, that both vidmode setting and panning behaves like > FB_ACTIVATE_VBL set for crtc2, and behaves like FB_ACTIVATE_VBL unset > for crtc1. I gues sit's only a (or a few) bits in register programming, > i'll try to find it when i re-read g400 register docs for crtc2 yuv support. page 4-75, CRTC1: When accessing the three-part startadd field, the portion which is located in CRTCEXT0 must always be written; it must always be written after the other portions of startadd, which are located in CRTCC and CRTCD). The change of start address will take effect at the beginning of the next horizontal retrace following the write to CRTCEXT0. Display will continue at the next line, using the new startadd value. This arrangement permits page flipping at any line, with no tearing occurring within the line. To avoid tearing between lines within a frame, software can poll either vcount or the vretrace field of INSTS1, or use the VSYNC interrupt to update CRTCEXT0 between frames. page 4-143, CRTC2: All the addresses programmed in the 2nd CRTC address generator must be aligned on an 8 quadword boundary (the 6 LSBs set to '000000'). All these address registers are double-buffered. This means that, the addresses written in these registers become effective after the beginning of the next vertical blank. At this point, the programming values written during the drawing of a frame will only affect the next frame, therefore, no tearing occurs. So CRTC1 reloads address at the end of line, CRTC2 at the end of frame. No way around it for CRTC2, but we can emulate VBL reload for CRTC1. I'll do that. More work :-( Petr

1 0

reducing/simplifying codebase
by Arpi 22 Jul '03

22 Jul '03

Hi, Imho we should consider removing of some included libraries from g2: - libmpdvdkit - it doesnt differ from libdvdcss/libdvdread nowdays (originally it was created to include several patches and bugfixes not present in official libdvdcss/libdvdread) - libmpeg2 - it's quite broken, at least it cannot handle seeking at all and is already patched to hell to work at all work mplayer... Also when we port things from g1, we should consider - dropping .raw font support, imho freetype alone is enough. - libdha / vidix shouldnt be included, but support the vidix.sf.net release instead - dropping xvid_vbr.c/divx4_vbr.c, last evrsins of divx5/xvid/lavc have its own 2pass API functions, no need for external control anything left out? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

7 9

OSD, again :)
by Alban Bedel 21 Jul '03

21 Jul '03

Hi, The system is based on what i called "osd display". The display role is to manage draw/clear of the various objects currently attached to the display. Once a display is configured then you just feed it with some mp_image and it will draw the objects. The "osd display" doesn't do any drawing/clearing. It just take care of what have to be done, draw are handled by the object themself, and clear by a callback. The system make the drawing/clearing decisions upon the "buffer type". The display itself have a buffer type but it's also possible to define some area with a different buffer type. There is 3 buffer types : TEMP : We never clear it, everything is redrawn at every frame STATIC : We need to clear it if it change but we don't need to redraw it at every frame. LOCKED : This forbid drawing. So TEMP is the movie area, STATIC the black bands and LOCKED is for IP/B, PRESERVE, etc. The osd filter is just like expand (should have took it ;) But by default the filter will use LOCKED area for IP/B so you won't see anythig unless you either expand enouth or use force=1 (wich then allow DR only on TEMP). The osd object need freetype (with freetype-config for the build). So you also need to pass it a font name. Use something like: -vop osd=force=1:objs=test=font=/path/to/your/font and you should see some text comming from the right :) Ok, this is "just some experiment", feedback appreciated :) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs.

3 6

new idea for vo parent-child, xover etc.
by Arpi 20 Jul '03

20 Jul '03

Hi, Albeu implemented vo_xover, nice. Although at least half of that code si generic and sould be duplicated to every parent-capable vo drivers. Not a big deal, easy to move out to separate file or vo core. But what about OSD? We should be able to do tricks, like render osd to the key color, without antialiasing but in hi-res it doesnt really matter, and still looks better than 320x200 antialieased subs upscaled (together with the video window) to 1024x768 for example. Also we could render antialiased subs bellow the image (when widescreen). Of course all this can be done with the xover approach, by adding new controls etc, but why to do that, if we can do it easier: Let's allow vf_vo2 to control 2 vo in a special way, ie. parent and chield. It could open vo_x11 to draw a window with colorkey, osd etc, and open vo_mga to display overlay to translated coords retrieved from vo_x11 (unfortunatelly we need a special control to get absolute window position... or put that info to the vo struct, like win_x, win_y) So, actually vo_x11 doesn't even know about vo_mga, and vice versa. It allows us to do mroe vo combinations without extra support code in them, and do tricky osd rendering, adding black bars without using more YUV memory (when window and overlay aspect differs) and so on. Since controls like RESIZE_DEST come from teh vf layer, vf_vo can send it to both vo drivers, it's not problem. Any comments? Maybe i'm wrong and lots some important point making this impossible? Looks way too simple and easy :) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

2 1

OSD
by Alban Bedel 19 Jul '03

19 Jul '03

Hi, I worked a bit on OSD. Here is my current work. Comment are welcome :) Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs.

1 1

[PATCH] vo_tdfx_vid.c and vo_xover.c
by Alban Bedel 19 Jul '03

19 Jul '03

Hi all, i implemented $SUBJ. A few comments : tdfx_vid I included my current tdfx_vid driver because i used some stuff wich are not yet commited to the main cvs driver. I tried a new "sleep" method. I discussed it a bit yesterday with Arpi on IRC. The idea is to suppress the sleep before show_frame and give show frame the delay needed before the frame must be displayed (in other words the time that would have been spent sleeping). Then in show_frame the banshee is setup to do the flip at the right time (in fact after a given number of V-Sync). So instead of sleeping the player can contiue. In my test i get a good cut down on CPU by using this. A 640x272 clip uselly need ~80% of the CPU, need only ~55% with this method. This is according to top so it's not a so good measurment, but still. xover This is not completly ready. It mostly work (with tdfx_vid) but i must say i have been confused by VOCTRL_RESIZE_DEST. Quoting libvo2.txt : --- VOCTRL_RESIZE_DEST: Asks the driver to redefine (move/resize) the display area. The parameters passed in a int[4] array: x,y,w,h. -1 means unchanged. --- So i thought that this would be the position of the window/overlay on the screen. But then in x11_helper.c i found : --- case VO_EVENT_MOVE: mp_msg(MSGT_CPLAYER,MSGL_V,"vo-event: moved to %d x %d\n",x,y); // dont do that, we're moving the window, not the picture inside the window! // { int tmp[4]; // tmp[2]=tmp[3]=-1; tmp[0]=x; tmp[1]=y; // vo->control(vo,VOCTRL_RESIZE_DEST,tmp); // } --- So it then seemed that this control was intended for something else ? Anyway i uncommented this and used the control for overlay resize/move. If this control is really intended for another use, wich one should i use ? A new one ? Albeu -- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs.

2 7

released: pre36
by Arpi 19 Jul '03

19 Jul '03

Hi, pre36: - new filter: vf_madei, a motion-adaptive deinterlacer - fastmemcpy.h/memcpy_pic() fixed for stride>width+16 - cvs up: libavcodec+vd_ffmpeg - ( ) escaping support into subconfig parser (patch by Albeu) - tdfx_vid + vo_tdfx ported (Albeu) - vo_xover (worx with tdfx_vid and mga_vid) (patch by Albeu) - VO_BUFFER_FLAG_SLEEP: usleep() done by the vo (patch by Albeu) - vo_mga: VOCTRL_RESIZE_DEST support A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

1 0