[FFmpeg-user] dv => mp4: deinterlace or not, and how?

sean darcy seandarcy2 at gmail.com
Sun May 8 03:43:41 CEST 2011


On 05/06/2011 03:03 PM, Baptiste Coudurier wrote:
> On 05/06/2011 11:35 AM, sean darcy wrote:
>> On 05/06/2011 01:27 PM, Baptiste Coudurier wrote:
>>> On 05/06/2011 10:02 AM, sean darcy wrote:
>>>> On 05/06/2011 12:04 PM, sean darcy wrote:
>>>>> On 05/05/2011 07:42 PM, Baptiste Coudurier wrote:
>>>>>> On 05/05/2011 04:34 PM, sean darcy wrote:
>>>>>>> On 05/05/2011 04:36 PM, Baptiste Coudurier wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 05/05/2011 01:19 PM, sean darcy wrote:
>>>>>>>>> I have an interlaced dv file. I'm transcoding it with x264 to mp4.
>>>>>>>>>
>>>>>>>>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x>   out.mp4
>>>>>>>>>
>>>>>>>>> If I just leave it like that, is out.mp4 interlaced or progressive?
>>>>>>>>
>>>>>>>> progressive. By default encoding is progressive.
>>>>>>>>
>>>>>>>>> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x>   -deinterlace
>>>>>>>>> out.mp4
>>>>>>>>>
>>>>>>>>> Here I assume out.mp4 is progressive. The ffmpeg documentation
>>>>>>>>> says:
>>>>>>>>>
>>>>>>>>> "The alternative is to deinterlace the input stream with
>>>>>>>>> `-deinterlace',
>>>>>>>>> but deinterlacing introduces losses."
>>>>>>>>
>>>>>>>> Correct, it is progressive. Use -vf yadif instead of -deinterlace
>>>>>>>> Deinterlacing may be a bit destructive, especially if the input is
>>>>>>>> _not_
>>>>>>>> interlaced.
>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> Given this note about losses, am I right we should never
>>>>>>>>> deinterlace?
>>>>>>>>> Almost never? When is deinterlacing required/better?
>>>>>>>>
>>>>>>>> You have options:
>>>>>>>> if the receiving end playback interlaced (CRT tv):
>>>>>>>> encode interlaced
>>>>>>>> else if the receiver is going to deinterlace if the file is
>>>>>>>> marked as
>>>>>>>> interlaced and you trust this deinterlacer, then you may encode
>>>>>>>> interlaced (deinterlacing will take cpu time)
>>>>>>>> otherwise you should deinterlace yourself using a good deinterlacer.
>>>>>>>
>>>>>>> Right. I knew that! Just passed right out of my mind, though.
>>>>>>>>
>>>>>>>> I suggest always deinterlace using -vf yadif if the source
>>>>>>>> content is
>>>>>>>> interlaced
>>>>>>>>
>>>>>>>
>>>>>>> Well I found http://guru.multimedia.cx/deinterlacing-filters/
>>>>>>>
>>>>>>> so I thought I'd try:
>>>>>>>
>>>>>>> -vf "yadif=3:0,mp=mcdeint=2:0:10"
>>>>>>>
>>>>>>> (dv is bottom-field first, right?)
>>>>>>>
>>>>>>> That generates a lot of perplexing output:
>>>>>>>
>>>>>>> [snow @ 0x230df40] pass:4mv changed:1384
>>>>>>> [snow @ 0x230df40] pass:0 changed:1083
>>>>>>> [snow @ 0x230df40] pass:1 changed:407
>>>>>>> [snow @ 0x230df40] pass:2 changed:147
>>>>>>> [snow @ 0x230df40] pass:3 changed:50
>>>>>>> [snow @ 0x230df40] pass:4 changed:17
>>>>>>> [snow @ 0x230df40] pass:5 changed:11
>>>>>>> [snow @ 0x230df40] pass:6 changed:2
>>>>>>> [snow @ 0x230df40] pass:7 changed:1
>>>>>>> [snow @ 0x230df40] pass:8 changed:1
>>>>>>> [snow @ 0x230df40] pass:9 changed:1
>>>>>>> [snow @ 0x230df40] pass:10 changed:1
>>>>>>> [snow @ 0x230df40] pass:11 changed:2
>>>>>>> [snow @ 0x230df40] pass:12 changed:2
>>>>>>> [snow @ 0x230df40] pass:13 changed:2
>>>>>>> [snow @ 0x230df40] pass:14 changed:0
>>>>>>> [snow @ 0x230df40] pass:4mv changed:1864
>>>>>>
>>>>>> This is some debug messages, ignore them.
>>>>>>
>>>>>>> I realize the filter comparison is from five years ago, and yadif may
>>>>>>> have changed significantly since then. Does mcdeint still add
>>>>>>> anything
>>>>>>> to yadif?
>>>>>>
>>>>>> I think nothing has changed much since then :)
>>>>>>
>>>>>
>>>>> Now I've tried yadif=1:0. As I understand it, this is "bob"
>>>>> deinterlacing - field doubling (each field becomes a frame) - with
>>>>> spatial and temporal weaving.
>>>>>
>>>>> But the output is strange:
>>>>>
>>>>> [yadif @ 0xfbd9c0] mode:1 parity:0
>>>>> .........
>>>>> frame=38981 fps= 15 q=-1.0 Lsize= 624133kB time=1300.60
>>>>> bitrate=3931.2kbits/s dup=0 drop=38979
>>>>>
>>>>> There's a "drop" for each input frame. I'd understand this for yadif=0,
>>>>> where (as I understand it) 2 fields are combined into 1 frame. But
>>>>> yadif=0 shows _no_ drops.
>>>>>
>>>>> sean
>>>>
>>>> Ran it with yadif=0:
>>>>
>>>> [yadif @ 0x1d359c0] mode:0 parity:0
>>>> ........
>>>> frame=38980 fps= 16 q=-1.0 Lsize=  622885kB time=1300.57
>>>> bitrate=3923.4kbits/s    s
>>>> video:622275kB audio:0kB global headers:0kB muxing overhead 0.097974%
>>>> frame I:166   Avg QP:16.67  size: 50398
>>>>
>>>> No drops. And the resulting file size is approximately the same. But
>>>> shouldn't the yadif=0 file be ~1/2 the size of the yadif=1 file? That
>>>> is, 2 fields are becoming 1 frame, so 1/2 the number of frames. Or is
>>>> x264 just compressing the related "bob" frames so effectively?  Or am I
>>>> misunderstanding this entirely?
>>>>
>>>> But I still don't get why yadif=1 drops a frame for each input frame.
>>>
>>> No, when using mode 1, please read the documentation:
>>>     * 1: send 1 frame for each field
>>>
>>> You are outputting 2 frames for one field. If you want no drop you need
>>> to double the frame rate.
>>>
>>
>> Lost. let me go back to basics. I've got an interlaced input with 38980
>> "frames". But each of these frames is of 2 fields - each half the size
>> of a progressive frame. And ~60 (59.94) fields are shown each second.
>>
>> For yadif=0, 2 fields are combined into 1 frame. So with my input, I
>> should get the same number of "frames". The framerate would be to ~30
>> (29.97) frames per second.
>>
>> For yadif=1, each field is reconstructed into a frame. "send 1 frame for
>> each field" . So I have twice the number of "frames", and each frame is
>> a full size progressive frame. And the framerate should now be ~60??
>>
>> So if I use yadif=1 with a standard 29.97 frame rate, half the frames
>> are discarded. Which means there's no benefit to yadif=1!
>>
>> You'd need to set -r 59.94, and there'd be few if any players for your
>> clip!
>>
>> Am I getting closer?
>>
>> Why would anyone ever use yadif=1 "bob" deinterlacing?
>
> You can do 1080i25 to 720p50 for example, but I'm sure there are other
> usage since the feature is there.
>
Now here's an interesting result, at least to me!

The output from:
ffmpeg -i $INPUT -an  -vcodec libx264  -preset slower -tune film   \
    -vf "yadif=0:0,hqdn3d" -r 29.97 -crf 17 -threads 0 $1.m4

680394195 May  6 12:47 JulyPlay-crop-yadif0-hqdn3d.mp4

And from:
ffmpeg -i $INPUT -an  -vcodec libx264  -preset slower -tune film   \
   -vf "yadif=1:0,hqdn3d" -r 59.94 -crf 17 -threads 0 $1.m4

697669397 May  7 20:57 JulyPlay-crop-yadif1-hqdn3d.mp4

These are 1990 vhs tapes. Since I'm uploading to blip.tv, I'd like the 
best I can do, even at the expense of encoding time.

Therefore the cost (in terms of file size) of encoding with x264 a 
stream from yadif=1 (with twice the frames of yadif=0) is less than 3% 
(698meg v. 681meg).

If blip.tv can deal with 59.94 framerates, I'm better off using yadif=1, 
-r=59.94.

BTW, all the examples I see have denoising after deinterlacing. 
Shouldn't that be reversed: -vf="hqdn3d,yadif". Wouldn't it be better to 
lower the noise before you deinterlace?

sean



More information about the ffmpeg-user mailing list