[MPlayer-dev-eng] *SUGGESTED* libvo2 patch

[Arpi]

Hi,

> >>+	case IMGFMT_MPEGPES: return("MPEG-PES");
> >>+	case IMGFMT_MPEG12: return("MPEG-(1/2)");
> >>
> >what's the diff between mpegpes and mpeg12 ? i think they are the same.
> >
> you add headers to your mpegpes packets, and run mpeg2_decode_data on it 
> in dec_video, this isn't necessary for dxr3 boards, and eat unneccessary 
> cpu cycles... I guess disabling mpeg2_decode_data if vo = dxr3 would be 
> enough...
RTFS again. or ask before doing silly things.
no, no decode was called for it. decode_headers was called for getting
correct timing info (for progressive mpeg2 streams).
it is no more needed as i added such code to libmpdemux recently.

> But I remembered the last time I made alternations outside of libvo2, so 
> this time I thought I'd stick to ./
?

> >> 
> >>-// return true if surface is in fast system ram, false if slow (video?) memory
> >>-// USED for storing mpeg2 I/P frames only if it's fast enough
> >>-#define VO2CTRL_QUERY_SURFACE_FAST 0x101
> >>-
> >>-// return true if surface is direct rendered, false if indirect (copied first)
> >>-// Note: it's usually same as VO2CTRL_GET_SURFACE_SPEED, except for some
> >>-// special cases, when video card does the copy from video ram (opengl...)
> >>-// USED for deciding external double buffering mode (using 2 surfaces)
> >>-#define VO2CTRL_QUERY_SURFACE_DIRECT 0x102
> >>-
> >>-// Get the upper hardware/Driver limitation (used for double buffering)
> >>-#define VO2CTRL_GET_MAX_SURFACES 0x103
> >>-
> >>
> >
> >why did you removed these?
> >they are used by my under-devel buffering engine...
> >
> I didn't remove them, I moved them to the bottom of the file, because 
> there might be LOTS of VO2CTRL_ stuff, in which case developers would 
> have to scroll a long way down to read the vo2_handle_t struct 
> implementation etc
> 
> >
> >
> >> typedef struct vo2_info_s
> >>@@ -43,7 +24,7 @@
> >>     unsigned char* img[3];  // pointer to frame/planes
> >>     int stride[3]; // strides (bytes per line) for frame/planes
> >>     int format; // RGB / BGR / YUV_PACKED / YUV_PLANAR
> >>-    int bpp;  // bits per pixel (15/16/24/32) or YUV fourcc
> >>
> >why?
> >
> isn't it pretty clear in format?
not. format may be yuv modes and for fast calculating stuff it's usefull to
have bpp extracted. it was for speed optim, and to avoid having big switch()
in drivers.

> or is the bpp fussy in IMGFMT_RGB24 (to take one)
it's simple in rgb modes but there are non-rgb too.


> 
> >
> >
> >>+    void* priv; /* Device private data, don't use globals! */
> >>
> >:))))))) (see my prev mail)
> >
> >>+// Save and load device options, if load returns NULL set to default
> >>+int vo2_save_devoptions(void);
> >>+int vo2_load_devoptions(void);
> >>
> >???
> >
> The device options struct is a bit complex to say the least, the benefit 
> is it's completely versatile.
> I though implementing a few handlers for it would make it easier for 
> developers (the options struct is a sigsegv trap to say the least to an 
> inexperienced programmer, if I implement handlers for it that can be 
> avoided)
heh.

> >>+//Query the overlay mode (used for osd and sub)
> >>+#define VO2CTRL_QUERY_OVERLAY 0x141
> >>
> >i think you should get a better name for it (subpicture?)
> >
> well, it is an overlay, are you asking what a subpicture is or are you 
> suggesting _SUBPICTURE for a name?
later.
we usually call the yuv/rgb overlays (hardware overlays over the
framebuffer) as overlay, and call the 'overlay over the overlay' to
subpicture (subtitles/osd).

> >>-static vo2_handle_t* new_handle(){
> >>+static vo2_handle_t* new_handle( priv_t *handle )
> >>
> >see my prev-(N+1) mail
> >
> yes, I made a new post after reading that one where I pointed out that 
> my new_handle modifications should be removed, perhaps my f*cking 
> mailserver hasn't manage to deliver that one yet...
:)
you really should change mailserevr... your is too slow.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu