Rich Felker wrote:
On Wed, May 11, 2005 at 06:36:32PM +0200, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Wednesday 11 May 2005 16:47, Michel Bardiaux wrote:
Rich Felker wrote:
On Wed, May 11, 2005 at 11:53:20AM +0530, Mangesh Kulkarni wrote:
Hello, What should be the change in following command to convert 4:2:0 planar to 4:2:2 packed?
ffmpeg -s 720x576 -f rawvideo -pix_fmt yuv420p -i src.yuv -s 720x576 -f rawvideo -pix_fmt yuv422p dst.yuv
Specify yuv422 for output, not yuv422p.
I told you, if you do this to interlaced video without special care you'll ruin it!!
You mean, img_convert is broken?
yes, use the swscaler from mplayer/mencoder,
Cant do that, its GPL (and ISTR there was talk about changing it to LGPL, any news on that?)
img_convert will butcher interlaced video IIRC
Richard makes a lot of noise but not much info.
Well then let me try to give some info..
For which I am grateful.
I just found I had asked a related question some month ago, never got a clear answer: assume I have an YUV420P image, 768x576, 2 interlaced fields, what do I with lavc to zoom it down by 2?
Treat the two fields as two independent, unrelated images and scale each one down by 2.
OK. Now, is there a reason why lavc does not do that, or was it just a Q&D?
Do I need to apply the deinterlace filter first?
If you want to deinterlace, you can do this instead. However deinterlacing throws away roughly half the content of the video.
Sometimes my encoded movies show the infamous 'comb' effect (strong motion between the 2 fields). This of course could be due to the bttv, see below. I thought (mistakenly maybe) that the deinterlace filter was intended to compensate for the comb effect.
Richard also mentionned (I think) that when it comes from a BT878, 420P is broken.
Yes, if you capture "4:2:0" video from bttv, you'll get a 768x576 luma plane which contains both fields (correct), and two 384x288 chroma planes (u and v) which contain a single field, the top one. The bottom field of chroma data will be totally missing.
ITIYM the U and V values average 2 pixels from the top field (since the image size coming from bttv is correct). BTW does this apply to every version of bttv?
So, same question w.r.t. YUV422P.
Same thing applies.
You lost me there. Maybe an example? Assume 4 pixels in the Y plane, as follows: YA YB YC YD For 420P the U should be (UA+UB+UC+UD)/4 (possibly a smarter filter of course) but bttv returns (UA+UB)/2. Right? For 422P we should have (UA+UB)/2 and (UC+UD)/2, right? Your answer could be interpreted as meaning bttv returns (UA+UB)/2 *twice*. Is that so? Then, is there *any* format that isnt broken in bttv? Or is there a patch somewhere?
And if lavc butchers the image, please you or Richard tell me exactly what, then maybe I will be able to fix it.
It's not that lavc butchers it. If you use lavc's image resampling independently on fields it's just fine (except for being very slow).
Why *very* slow? Because of the overhead of extracting the fields then merging them again?
The problem is that ffmpeg (afaik) has no interface for using it this way, so you'd need to write your own program
I might do that, but the bttv thing has to come first, otherwise I'll be working on a wrong basis.
or use mplayer/mencoder which already does this (and with much faster code).
Cant: GPL, and we have our own grabber application (we need 24/7 operation, and ideal MPEGs of exactly 1 minute)
Rich
-- Michel Bardiaux Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41