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

Fri May 6 21:03:25 CEST 2011

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.

-- 
Baptiste COUDURIER
Key fingerprint          8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                           http://www.ffmpeg.org