From: James S. <jst...@gm...> - 2003-01-31 13:47:35
|
Hi, I'm trying to get vidix working with a G200, however I've come up against a problem: Even if VO_CAP_YV12 is not included in the driver capabilities, frames with XINE_IMGFMT_YV12 are still being sent to the driver. I'm not particularly familiar with the xine source and so don't really know where I should be looking to fix this. James. |
From: James S. <jst...@gm...> - 2003-01-31 15:48:30
|
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? James. On Friday 31 Jan 2003 13:35, James Stembridge wrote: > Even if VO_CAP_YV12 is not included in the driver capabilities, frames with > XINE_IMGFMT_YV12 are still being sent to the driver. I'm not particularly > familiar with the xine source and so don't really know where I should be > looking to fix this. |
From: Guenter B. <bar...@we...> - 2003-01-31 16:42:30
|
hallo james, > 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. 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 |
From: James S. <jst...@gm...> - 2003-01-31 17:14:37
|
On Friday 31 Jan 2003 16:41, Guenter Bartsch wrote: > 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. Ok, I will implement conversion in the driver for those cards that only support 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. I agree that there is little need to output any of other endless variations of yuv formats that seem to exist. But how about RGB? For example using goom with xshm results in two conversions which seems a little suboptimal. If may look at this myself a little way down the line if no one else is interested. James. |
From: Michael R. <mr...@us...> - 2003-01-31 18:25:49
|
Hi James, Hi guenter, > > 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 Michael -- printk(KERN_WARNING "%s: Short circuit detected on the lobe\n", dev->name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c |
From: Guenter B. <bar...@we...> - 2003-01-31 19:39:07
|
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 |
From: Michael R. <mr...@us...> - 2003-01-31 22:01:00
|
Hi guenter, > > 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 Can't we acquire a fresh frame during the conversion, write the new frame data to it, send it on and throw the old one away (by calling its free())? Michael -- Never trust a programmer who is carrying a screwdriver. |
From: Guenter B. <bar...@we...> - 2003-01-31 22:15:38
|
hallo michael, > > 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 > > Can't we acquire a fresh frame during the conversion, write the new > frame data to it, send it on and throw the old one away (by calling its > free())? uohm, that would reduce the number of available frames by 50% and you'd have to allocate frames for the new colorspace (allocated memory for yuv420 is not enough to hold rgb32, for example) cheers, guenter -- DeVries's Dilemma: If you hit two keys on the typewriter, the one you don't want hits the paper. |
From: Guenter B. <bar...@we...> - 2003-01-31 21:47:27
|
hallo james, > > 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. > > I agree that there is little need to output any of other endless variations of > yuv formats that seem to exist. But how about RGB? For example using goom > with xshm results in two conversions which seems a little suboptimal. If may > look at this myself a little way down the line if no one else is interested. it sure does, but rgb is a lot of different formats (15,16,24,32 bit with rgb in various endianess and ordering variations 8-}) - at least personally i'll stay away from that pandora's box as far as i can - but of course don't let me stop you, if you think you have a nice way to handle this, feel free to prove me wrong ;) cheers, guenter -- DeVries's Dilemma: If you hit two keys on the typewriter, the one you don't want hits the paper. |
From: Miguel F. <mi...@ce...> - 2003-02-01 12:08:37
|
Hi Guenter, James, On Fri, 2003-01-31 at 19:46, Guenter Bartsch wrote: > it sure does, but rgb is a lot of different formats (15,16,24,32 bit > with rgb in various endianess and ordering variations 8-}) - at least > personally i'll stay away from that pandora's box as far as i can - but > of course don't let me stop you, if you think you have a nice way to > handle this, feel free to prove me wrong ;) just to say that i agree with guenter here. i think we should try to keep things simple unless we have a very good reason to change it. goom output BGR-32 on little endian and RGB-32 on big endian, so it's unlikely that data will pass unconverted just because the driver accepts some sort of rgb variation. also, you must consider that you have _basically_ (1) two approaches to write your color conversion code: either convert every input to a common format and then to the output (slower), or convert it directly input->output. implementing the former won't be much different that what we have now (we can say that two common formats are currently accepted: yv12 and yuy2). implementing the later is quite some work, because the number of conversion routines increases with input*output. although i must admit that i don't consider myself to have much knowledge on this issue, imho, we can have better use to our programming time... :) regards, Miguel (1) emphasis on "basically"... i'm not saying that these are the only two approaches, mixed alternatives are surely possible. |