dv => mp4: deinterlace or not, and how?

[sean darcy]

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?

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."

Is this still true?

Given this note about losses, am I right we should never deinterlace?
Almost never? When is deinterlacing required/better?

3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4

Here I assume out.mp4 is interlaced. How is this different from 1.
above? Is it different?

The FAQ mentions +alt as a flag. When should this be added? Does it hurt
to use it all the time?

sean

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

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.

I suggest always deinterlace using -vf yadif if the source content is
interlaced

> 3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4
>
> Here I assume out.mp4 is interlaced. How is this different from 1.
> above? Is it different?

Correct.

> The FAQ mentions +alt as a flag. When should this be added? Does it hurt
> to use it all the time?

+alt only applies to mpeg4 and mpeg2. It's supposed to improve
compression for interlaced content.

--
Baptiste COUDURIER
Key fingerprint          8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                           http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Henk D. Schoneveld]

On 05/05/11 22:19, 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?
>
> 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."
>
> Is this still true?
>
> Given this note about losses, am I right we should never deinterlace?
> Almost never? When is deinterlacing required/better?

It depends, as always. If the final display is a TV, which is capable to
deinterlacing, Most except 720p, which is rare, television broadcast is
interlaced.
If the final display is a computer-screen or an iPhone/AndroidPhone or
something like that, these devices don't deinterlace by themselves so
the source has to be deinterlaced, or has the deinterlace flag set at
the moment of display. Most people don't know that their computer
mplayer/vlc/WindowsMediaPlayer has an deinterlace option and will see a
very bad interlaced picture.

>
> 3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4
>
> Here I assume out.mp4 is interlaced. How is this different from 1.
> above? Is it different?
>
> The FAQ mentions +alt as a flag. When should this be added? Does it hurt
> to use it all the time?
>
> sean
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Bouke-3]

----- Original Message -----
From: "belcampo" <[hidden email]>


>  If the final display is a TV, which is capable to deinterlacing

Oi, big misunderstanding....
a good catholic (injoke) TV is NOT capable of de-interlacing.
It is capable of displaying interlaced images one field after another, thus
making pretty moving pictures.
(don't get me started about 100 Hz sets...)

Bouke


_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Mark Himsley]

On 05/05/2011 21:36, 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.

I'd like to clarify that answer.

I agree 100% that the mp4 will be encoded progressive. The problem is
that it could be badly encoding interlaced material. What I mean is, it
will be using progressive frame encoding techniques to encode a frame
that might be carrying interlaced material, which would therefore
display with comb edges on movement etc.

[...]
>> 3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4
>>
>> Here I assume out.mp4 is interlaced. How is this different from 1.
>> above? Is it different?
>
> Correct.

It is different from 1 because it encodes the two fields as temporally
different half-frames (if you don't mind my over-simplification).

In your option 1, the encoder can reduce bit-rate by
throwing-away/hiding stuff on every line of the picture, in one go.
Because interlacing works by every other line being from a different
temporal snapshot, that throwing-away/hiding could move pixels from one
temporal snapshot to another. Than can look really horrible.

In your opting 3 the encoder knows that the image is made up of the two
temporal snapshots and will not do that, but can use its knowledge that
the second snapshot may contain the same image as the first snapshot,
only with some/all parts moved, to reduce the bit-rate - by encoding the
second field as deltas from the first field.

--
Mark
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Mark Himsley]

On 05/05/2011 22:18, Bouke wrote:
>
> ----- Original Message -----
> From: "belcampo" <[hidden email]>
>
>>  If the final display is a TV, which is capable to deinterlacing
>
> Oi, big misunderstanding....
> a good catholic (injoke) TV is NOT capable of de-interlacing.

Although, there are many non-cathode-ray-tube displays that do
de-interlace (by line doubling fields), the £3500 JVC TFT monitor next
to me and the £350 Sony telly at home being just two examples...

> It is capable of displaying interlaced images one field after another, thus
> making pretty moving pictures.

but, yes that is definitely a better, if somewhat wordy, description
that sits better with my pedantic way of thinking.

> (don't get me started about 100 Hz sets...)

vile, horrid, turn it off NOW.

Do manufacturers not understand the time domain?

--
Mark
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Bouke-3]

----- Original Message -----
From: "Mark Himsley" <[hidden email]>

> Although, there are many non-cathode-ray

LOL,
You just took a good joke to the next level!
Bouke


_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[sean darcy]

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

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?

sean

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[sean darcy]

On 05/05/2011 06:32 PM, Mark Himsley wrote:

> On 05/05/2011 21:36, 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.
>
> I'd like to clarify that answer.
>
> I agree 100% that the mp4 will be encoded progressive. The problem is
> that it could be badly encoding interlaced material. What I mean is, it
> will be using progressive frame encoding techniques to encode a frame
> that might be carrying interlaced material, which would therefore
> display with comb edges on movement etc.
>
> [...]
>>> 3. ffmpeg -i file.dv -an -vcodec libx264 -b<x>  -flags +ilme+ildct out.mp4
>>>
>>> Here I assume out.mp4 is interlaced. How is this different from 1.
>>> above? Is it different?
>>
>> Correct.
>
> It is different from 1 because it encodes the two fields as temporally
> different half-frames (if you don't mind my over-simplification).
>
> In your option 1, the encoder can reduce bit-rate by
> throwing-away/hiding stuff on every line of the picture, in one go.
> Because interlacing works by every other line being from a different
> temporal snapshot, that throwing-away/hiding could move pixels from one
> temporal snapshot to another. Than can look really horrible.
>
> In your opting 3 the encoder knows that the image is made up of the two
> temporal snapshots and will not do that, but can use its knowledge that
> the second snapshot may contain the same image as the first snapshot,
> only with some/all parts moved, to reduce the bit-rate - by encoding the
> second field as deltas from the first field.
>

Thanks. Very helpful. I have realized I need to deinterlace, but now I
know what to do if I'm keeping the stream interlaced.


_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

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 :)

--
Baptiste COUDURIER
Key fingerprint          8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                           http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[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



_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

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.

--
Baptiste COUDURIER
Key fingerprint          8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                           http://www.ffmpeg.org
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Andrew Berg]

On 2011.05.05 06:34 PM, sean darcy wrote:
> Does mcdeint still add anything
> to yadif?
Yes, but unless you have a really powerful CPU, it's not worth the extra
time that it adds. It's very slow.

In any case, using Yadif to deinterlace is almost always a very good
idea. Interlaced displays are reaching their last days, and encoders do
a much better job with progressive input.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[sean darcy]

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?

sean

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Baptiste Coudurier-2]

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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Christian Ebert]

* sean darcy on Friday, May 06, 2011 at 14:35:03 -0400
> Why would anyone ever use yadif=1 "bob" deinterlacing?

To show a converted PAL source via a projector at 50 fps. The
results from yadif=3,mcdeint=2:1:10 are brilliant, really. You
just need a few days to transcode ;-)

c
--
\black\trash movie   _SAME  TIME  SAME  PLACE_
               New York, in the summer of 2001

--->> http://www.blacktrash.org/underdogma/stsp.php
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Bouke-3]

----- Original Message -----
From: "Andrew Berg" <[hidden email]>
To: "FFmpeg user questions and RTFMs" <[hidden email]>
Sent: Friday, May 06, 2011 8:07 PM
Subject: Re: [FFmpeg-user] dv => mp4: deinterlace or not, and how?


> On 2011.05.05 06:34 PM, sean darcy wrote:
>> Does mcdeint still add anything
>> to yadif?
> Yes, but unless you have a really powerful CPU, it's not worth the extra
> time that it adds. It's very slow.
>
> In any case, using Yadif to deinterlace is almost always a very good
> idea. Interlaced displays are reaching their last days,

Excuse me? Where did you get this information  about interlacing going away?
Do you have anything to backup that what you are saying is actually
meaningfull?

Sorry if i sound harsh (Trying to be so now), but IMHO, this is just plain
bullshit.
But i love to be prooven wrong.


Bouke


> and encoders do
> a much better job with progressive input.
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user 


_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Mark Himsley]

On 06/05/2011 19:07, Andrew Berg wrote:
> Interlaced displays are reaching their last days

Not true.

--
Mark
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Andrew Berg]

On 2011.05.06 04:30 PM, Bouke wrote:
> Excuse me? Where did you get this information  about interlacing going away?
> Do you have anything to backup that what you are saying is actually
> meaningfull?
>
> Sorry if i sound harsh (Trying to be so now), but IMHO, this is just plain
> bullshit.
The only bullshit is you calling me out on something I didn't say. I
never said interlacing is going away. In fact, I see it being around for
a long time (most broadcasters want to present sports and other
fast-motion content at 50 or 59.94Hz instead of 25 or 29.97Hz and still
have a "full HD" picture, and no one seems to be willing to broadcast
1080p50/60). HDTVs (and software media players sending video to an LCD
monitor) can deinterlace, so broadcasting interlaced material isn't a
huge issue. Pure interlaced displays are going away in the near future,
to be replaced by LCD monitors and HDTVs. I'm not saying everyone will
have an HDTV in the next year, but they are being replaced. As always,
there are going to be special situations where encoding interlaced is
appropriate for a non-broadcaster, but in general, progressive is the
way to go.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user