4:2:0 to 4:2:2 conversion
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. Thanks Mangesh
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.
I told you, if you do this to interlaced video without special care you'll ruin it!! I have no idea how to do what you want with ffmpeg. Using mencoder it's easy.. Rich
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?
I have no idea how to do what you want with ffmpeg. Using mencoder it's easy..
Rich
-- Michel Bardiaux Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41
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, img_convert will butcher interlaced video IIRC [...] -- Michael
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. 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? Do I need to apply the deinterlace filter first? Richard also mentionned (I think) that when it comes from a BT878, 420P is broken. So, same question w.r.t. YUV422P. And if lavc butchers the image, please you or Richard tell me exactly what, then maybe I will be able to fix it.
[...]
-- Michel Bardiaux Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41
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..
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.
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.
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.
So, same question w.r.t. YUV422P.
Same thing applies.
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). The problem is that ffmpeg (afaik) has no interface for using it this way, so you'd need to write your own program or use mplayer/mencoder which already does this (and with much faster code). Rich
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
On Thu, May 12, 2005 at 11:09:08AM +0200, Michel Bardiaux wrote:
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?
It doesn't know whether the video is interlaced or not.
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.
What you're calling the comb effect is simply the fact that you're putting two pictures together than don't go together. Deinterlacing effectively just throws away one of the two, or blurs the two together so you can't tell they don't go together.
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).
Not sure what you mean.
BTW does this apply to every version of bttv?
Probably, yes. The hardware does not support 4:2:0, so in order for the driver to support it, it would have to resample in kernelspace (very stupid idea).
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?
No, this would just be minor misalignment. Notice that your description of the problem has nothing to do with interlacing. Again, read the short paragraph I wrote above. BTTV's fake 4:2:0 is missing a whole field of chroma.
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?
BTTV's 4:2:2 video is exactly right.
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?
No, becuase the image resample code in lavc is not optimized at all. No work has to be done to extract or re-merge them. You just do it in place with stride arithmetic. Rich
On May 12, 2005, at 11:33 AM, Rich Felker wrote:
On Thu, May 12, 2005 at 11:09:08AM +0200, Michel Bardiaux wrote:
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.
What you're calling the comb effect is simply the fact that you're putting two pictures together than don't go together. Deinterlacing effectively just throws away one of the two, or blurs the two together so you can't tell they don't go together.
That's bob/weave and it's stupid. The only remotely usable way to deinterlace is to shift the lines of one field into the other as neccessary. One deinterlacing method I've never seen described anywhere is to double the framerate instead. That's ofcourse wasteful, but with todays computers doubling the framerate is doable (it's just the output, the decode is still regular rate). Essentially you would convert e.g. 60i to 60p by only updating the new field (and perhaps dimming the previous field to simulate cathode ray phosphor fading). Anyone tried this? That should be as close to perfect as possible if the source is actually TV-sampled (and not pull-downed). /Roine
On Thu, May 12, 2005 at 12:03:11PM +0200, Roine Gustafsson wrote:
One deinterlacing method I've never seen described anywhere is to double the framerate instead. That's ofcourse wasteful, but with todays computers doubling the framerate is doable (it's just the output, the
It's not wasteful at all, it's the only correct way. And mencoder can do it -- see vf_tfields. Rich
So... I've sucessfully compiled ffmpeg-0.4.9-pre1, whole package. test run ffserver without make install (so i don't mess up current) from src-dir i get: Floating point exception using ffmpeg 0.4.9 with 0.4.8 doesn't work and probably aint suppost to What's wrong? Best regards $0 _______________________________________________________ Skicka gratis SMS! http://www.passagen.se
participants (6)
-
dalias＠aerifal.cx -
mangeshsk＠gmail.com -
mbardiaux＠peaktime.be -
michaelni＠gmx.at -
roine＠users.sourceforge.net -
runlevel_4＠passagen.se