Re: [xine-devel] video out driver capabilities ignored?

[Guenter B. <bar...@we...>]

hallo michael,

> > > On further investigation it would seem that the only decoder that
> > > pays any attention to the video out capabilities is w32codec. Does
> > > this mean that the other decoders are broken? Or is it up to the
> > > video out driver to do the conversion (which doesn't seem to be the
> > > right solution)? Or perhaps some magic should happen somewhere such
> > > that the frames are converted if there is a mismatch between
> > > decoder and video.
> > >
> > > On a somewhat related note is there any reason why frame format is
> > > limited to YUY2/YV12? Would it not make sense to allow at least
> > > some kind of RGB format?
> >
> > this has never been really defined but as a rule of thumb all video
> > out divers are expected to handle planary yv12 and if possible also
> > yuy2. adding more formats would complicate things without much
> > practical benefit as most decoders output yv12, very few output yuy2
> > and even fewer output other formats - those seem to be mostly older
> > codecs used in older stream formats with low resolution so it is no
> > problem to convert the frames to one of the yuv formats on the fly
> > for output.
> 
> Maybe we should rethink that in the context of post plugins. Most of 
> them operate on RGB colorspace, because YUV is not metric. Adding 
> additional constants for other frame types should not be the problem. 
> What would be needed is a general frametype conversion routine.
> 
> I imagine any frame processing plugin (post or output) checking, if it 
> can handle the frametype of incoming frames natively and if not, call a 
> utility funtion xine_convert_frame(vo_frame_t *, int target_type) which 
> would do the conversion.
> This would make things easier:
> * decoders and post plugins can output in their native colorspace
> * post plugins and output plugins can automatically handle all
>   frametypes supported by xine_convert_frame()
> * no unneeded conversions would occur

not that easy to do as you cannot overwrite the image data since some
decoders need the data as refernce frames so you'd need to upgrade the
frame allocation mechanism - lot of work imho. personally i'd try to
concentrate onn yv12, my current plan is that this will be the only
colorspace supported in enix

cheers,

   guenter

--
"Has anyone had problems with the computer accounts?"
"Yes, I don't have one."
"Okay, you can send mail to one of the tutors ..."
                -- E. D'Azevedo, Computer Science 372