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

[sean darcy]

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.

sean