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

[David Holm]

Arpi wrote:

>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.
>
yes, of course I'm gonna read and understand X MBs of code so you won't 
have to say rtfs again...
that will definately not be a waste of time, and users will appreciate 
me not updating stuff for a period of a month or so...

>
>
>>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.
>
ok, it'll go back in

>
>
>
>>>
>>>>+    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).
>
I think it would be confusing to call it SUBPICTURE, since a subpicture 
is something from the DVD format (RLE encoded picture consisiting of a 
16 color pallette of which only 4 colors are allowed to be used at one 
time... with control sequences and other stuff, messy thing (has nibbles 
etc))

>
>
>>>>-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.
>
It's my ISP's server, what can I do? =(


//David Holm