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

[sean darcy]

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