[FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Katherine Frances]

Hi all,

When transcoding to H.264 from an interlaced 4:2:2 original, I always add
the flag *-pix_fmt yuv420p*, which obviously achieves two goals:
i. Chroma subsampling scheme: 4:2:2 -> 4:2:0
ii. Scan: interlaced -> progressive.

I'm interested in the *p* part of the flag. Can anyone tell me how the
deinterlacing is achieved, i.e., what filter is used here by default?
I searched around quite a lot, but couldn't find specifics on this in the
ffmpeg wiki, on the documentation, or elsewhere on the web.

This is a general question rather than particular to a certain file. But,
here I provide the encoding settings for such a file (via MediaInfo). I'm
sure how to parse them in regard to my question - for example, I don't see
any sign of *yadif*, *bwdif*, etc.

cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 /

psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 /
chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 /
bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 /
open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 /
intra_refresh=0 / rc_lookahead=40 / rc=cbr / mbtree=1 / bitrate=4872 /
ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=4872
/ vbv_bufsize=4872 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

Thank you very much.

Best,
Katherine
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subj

[Katherine Frances]

To be clear, the MediaInfo specs quoted refer to the deinterlaced output
file.

Post by Katherine Frances
Hi all,
When transcoding to H.264 from an interlaced 4:2:2 original, I always add
i. Chroma subsampling scheme: 4:2:2 -> 4:2:0
ii. Scan: interlaced -> progressive.
I'm interested in the *p* part of the flag. Can anyone tell me how the
deinterlacing is achieved, i.e., what filter is used here by default?
I searched around quite a lot, but couldn't find specifics on this in the
ffmpeg wiki, on the documentation, or elsewhere on the web.
This is a general question rather than particular to a certain file. But,
here I provide the encoding settings for such a file (via MediaInfo). I'm
sure how to parse them in regard to my question - for example, I don't see
any sign of *yadif*, *bwdif*, etc.
cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 /

psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 /
trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 /
chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 /
bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 /
open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 /
intra_refresh=0 / rc_lookahead=40 / rc=cbr / mbtree=1 / bitrate=4872 /
ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=4872
/ vbv_bufsize=4872 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

Thank you very much.
Best,
Katherine

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subject "unsub

[Marton Balint]

Post by Katherine Frances
Hi all,
When transcoding to H.264 from an interlaced 4:2:2 original, I always add
i. Chroma subsampling scheme: 4:2:2 -> 4:2:0
ii. Scan: interlaced -> progressive.
I'm interested in the *p* part of the flag. Can anyone tell me how the
deinterlacing is achieved, i.e., what filter is used here by default?
I searched around quite a lot, but couldn't find specifics on this in the
ffmpeg wiki, on the documentation, or elsewhere on the web.

p means planar here, not progressive. You are not doing deinterlacing.

Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpe

[Katherine Frances]

Hi Martin,

Oh! Thanks for letting me know. I just assumed the conflation of the two
things here.

But then, how are my output videos becoming deinterlaced?

Inputs are uncompressed v210 in MOV. They're definitely interlaced, as
they're digitized from an analogue source (using an AJA ADC) with all
correct setup.
And outputs are definitely progressive, at least according to MediaInfo.

I'm just using a basic script, for example:

ffmpeg -i uncompressed_master.mov -c:v libx264 -pix_fmt yuv420p -c:a

libfdk_aac -b:a 128k access_copy.mp4

So how are my MP4s becoming deinterlaced? Is it a result of declaring MP4
as the output container? I thought that MP4s could contain interlaced
content - am I wrong about that?

Thanks for help!

Best, K

Hi all,

Post by Katherine Frances
When transcoding to H.264 from an interlaced 4:2:2 original, I always add
i. Chroma subsampling scheme: 4:2:2 -> 4:2:0
ii. Scan: interlaced -> progressive.
I'm interested in the *p* part of the flag. Can anyone tell me how the
deinterlacing is achieved, i.e., what filter is used here by default?
I searched around quite a lot, but couldn't find specifics on this in the
ffmpeg wiki, on the documentation, or elsewhere on the web.

p means planar here, not progressive. You are not doing deinterlacing.
Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subje

[Marton Balint]

Post by Katherine Frances
Hi Martin,
Oh! Thanks for letting me know. I just assumed the conflation of the two
things here.
But then, how are my output videos becoming deinterlaced?

Probably they are not.

Post by Katherine Frances
Inputs are uncompressed v210 in MOV. They're definitely interlaced, as
they're digitized from an analogue source (using an AJA ADC) with all
correct setup.
And outputs are definitely progressive, at least according to MediaInfo.

Mediainfo only shows the metadata, in reality the content is most probably
interlaced.

Post by Katherine Frances
ffmpeg -i uncompressed_master.mov -c:v libx264 -pix_fmt yuv420p -c:a

libfdk_aac -b:a 128k access_copy.mp4

So how are my MP4s becoming deinterlaced? Is it a result of declaring MP4
as the output container? I thought that MP4s could contain interlaced
content - am I wrong about that?

AFAIK ffmpeg does not do automatic deinterlacing based on container
features, so even if MP4 were progressive-only (it is not), ffmpeg still
would not do automatic deinterlacing.

The fact that the interlaced metadata is not reflected in the output can
be caused by a number of reasons, either the source file is missing the
interlaced/progressive metadata as well, or ffmpeg simply does not support
propagating it to mp4.

In any case, if you want to deinterlace, use a filter, like yadif.

Regards,
Marton

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org w

[Katherine Frances]

Marton, thank you very much, this is extremely helpful.

Okay, I guess that the output MP4s are actually interlaced, despite the
video stream metadata that MediaInfo reads. Do you think that 'progressive'
is default for libx264 and that's why this metadata property is being added
erroneously?

Lastly, do you know how I can determine whether the file actually is
interlaced?

Thank you!
Best, K

Post by Katherine Frances
Hi Martin,

Post by Katherine Frances
Oh! Thanks for letting me know. I just assumed the conflation of the two
things here.
But then, how are my output videos becoming deinterlaced?

Probably they are not.

Post by Katherine Frances
Inputs are uncompressed v210 in MOV. They're definitely interlaced, as
they're digitized from an analogue source (using an AJA ADC) with all
correct setup.
And outputs are definitely progressive, at least according to MediaInfo.

Mediainfo only shows the metadata, in reality the content is most probably
interlaced.

Post by Katherine Frances
ffmpeg -i uncompressed_master.mov -c:v libx264 -pix_fmt yuv420p -c:a

libfdk_aac -b:a 128k access_copy.mp4

So how are my MP4s becoming deinterlaced? Is it a result of declaring MP4
as the output container? I thought that MP4s could contain interlaced
content - am I wrong about that?

AFAIK ffmpeg does not do automatic deinterlacing based on container
features, so even if MP4 were progressive-only (it is not), ffmpeg still
would not do automatic deinterlacing.
The fact that the interlaced metadata is not reflected in the output can
be caused by a number of reasons, either the source file is missing the
interlaced/progressive metadata as well, or ffmpeg simply does not support
propagating it to mp4.
In any case, if you want to deinterlace, use a filter, like yadif.
Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org

[Kieran O Leary]

Hi Katherine!

Post by Katherine Frances
Marton, thank you very much, this is extremely helpful.

As Marton mentioned, the `p` refers to Planar, and the absence of `p` (as
far as i can tell) suggests Packed - https://ffmpeg.org/doxygen/
trunk/pixfmt_8h_source.html

Okay, I guess that the output MP4s are actually interlaced, despite the

Post by Katherine Frances
video stream metadata that MediaInfo reads. Do you think that 'progressive'
is default for libx264 and that's why this metadata property is being added
erroneously?
Lastly, do you know how I can determine whether the file actually is
interlaced?

As for interlacement checking, the idet filter works well -
https://amiaopensource.github.io/ffmprovisr/#check_interlacement
and if enabled in the preferences, QCTools does a really great job at
visualising the output of the idet filter. I find it interesting to see the
patterns produced by ingested tapes where some sort of deinterlacement
occured for certain segments. Or looking at a file that has misleading
metadata declaring interlacement (or progressive), but there is no evidence
of that when looking at the actual file.

-K
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subject

[Katherine Frances]

Kia ora,

*Andy*: thanks very much for this tip! Will add that filter to the script
as I definitely want to deinterlace.
Do you recommend this over *yadif*, or do I need to combine *scale* with a
deinterlacing filter?

*Kieran*: Hey there! How did I miss that ffmprovisr included that?
Excellent and great point about its use in QCTools.

Thanks again,
K.

Post by Kieran O Leary
Hi Katherine!

Post by Katherine Frances
Marton, thank you very much, this is extremely helpful.

As Marton mentioned, the `p` refers to Planar, and the absence of `p` (as
far as i can tell) suggests Packed - https://ffmpeg.org/doxygen/
trunk/pixfmt_8h_source.html
Okay, I guess that the output MP4s are actually interlaced, despite the

Post by Katherine Frances
video stream metadata that MediaInfo reads. Do you think that

'progressive'

Post by Katherine Frances
is default for libx264 and that's why this metadata property is being

added

Post by Katherine Frances
erroneously?
Lastly, do you know how I can determine whether the file actually is
interlaced?

As for interlacement checking, the idet filter works well -
https://amiaopensource.github.io/ffmprovisr/#check_interlacement
and if enabled in the preferences, QCTools does a really great job at
visualising the output of the idet filter. I find it interesting to see the
patterns produced by ingested tapes where some sort of deinterlacement
occured for certain segments. Or looking at a file that has misleading
metadata declaring interlacement (or progressive), but there is no evidence
of that when looking at the actual file.
-K
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@f

[Andy Furniss]

Post by Katherine Frances
Kia ora,
*Andy*: thanks very much for this tip! Will add that filter to the script
as I definitely want to deinterlace.
Do you recommend this over *yadif*, or do I need to combine *scale* with a
deinterlacing filter?

-vf scale=interl=1 Has nothing to do with de-interlacing it would be
needed more if you wanted to keep the interlacing.

yadif can de-interlace 422 input so if you used that *first* it
shouldn't matter. It would be wrong to convert 422 to 420 without
-vf scale=interl=1 if you then later de-interlaced, so the order
of filters matters.

yadif can produce field rate or frame rate output. It's field rate
that will look worse if you mess up the 422 to 420 conversion.

What to do depends on your content. If there's lots of motion then
field rate de-interlace (yadif=1) will look better. If it's interlaced
but low motion you will get away with frame rate (yadif=0).
Depending on what the masters are they may not be interlaced to start
with.

The right thing to do depends on what the output is for and what the
input really is - there is no right way as such.


_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg

[Katherine Frances]

Thanks again, Andy.
So if I understand correctly:

1. *-vf scale=interl=1* registers to libx264 that the input is
interlaced and to be 'aware' of that in future operations. *yadif*, of
course, does the actual deinterlacing.
2. If used in the same script, *scale* must precede *yadif. *Although it
seems rather redundant.
3. If deinterlacing with *yadif*, *yadif* should precede chroma
downsampling (via *-pix_fmt yuv420p*). In other words, the subsampling
scheme should be changed after the deinterlacing step.
- like this, for example?: ffmpeg -i uncompressed_master.mov -c:v
libx264 -vf yadif -pix_fmt yuv420p -c:a libfdk_aac -b:a 128k
access_copy.mp4
4. If using all three of these options, deinterlacing must be
preceded by chroma downsampling *and *-vf scale=interl=1
- Is the correct order then *scale *-> *pix_fmt* -> *deinterlace* ?

As for yadif mode, I'm only interested in frame rate output (send_frame
<https://ffmpeg.org/ffmpeg-filters.html#yadif-1>, which is the default
anyway).

I really appreciate you taking the time to help me. I'm learning a lot!

Best, K.

Post by Andy Furniss

Post by Katherine Frances
Kia ora,
*Andy*: thanks very much for this tip! Will add that filter to the script
as I definitely want to deinterlace.
Do you recommend this over *yadif*, or do I need to combine *scale* with a
deinterlacing filter?

-vf scale=interl=1 Has nothing to do with de-interlacing it would be
needed more if you wanted to keep the interlacing.
yadif can de-interlace 422 input so if you used that *first* it
shouldn't matter. It would be wrong to convert 422 to 420 without
-vf scale=interl=1 if you then later de-interlaced, so the order
of filters matters.
yadif can produce field rate or frame rate output. It's field rate
that will look worse if you mess up the 422 to 420 conversion.
What to do depends on your content. If there's lots of motion then
field rate de-interlace (yadif=1) will look better. If it's interlaced
but low motion you will get away with frame rate (yadif=0).
Depending on what the masters are they may not be interlaced to start
with.
The right thing to do depends on what the output is for and what the
input really is - there is no right way as such.
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmp

[Carl Eugen Hoyos]

Post by Katherine Frances
Thanks again, Andy.
1. *-vf scale=interl=1* registers to libx264 that the input is
interlaced and to be 'aware' of that in future operations.

No, the option is meant to tell the scale filter that it has to
adapt its operations for interlaced content.

Post by Katherine Frances
*yadif*, of course, does the actual deinterlacing.

Yes.

Post by Katherine Frances
2. If used in the same script, *scale* must precede *yadif. *Although it
seems rather redundant.

I would suggest the opposite since giving yadif more information could
help. There may be a performance trade-off though.

Post by Katherine Frances
3. If deinterlacing with *yadif*, *yadif* should precede chroma
downsampling

Same reasoning as above.

Post by Katherine Frances
(via *-pix_fmt yuv420p*)

You should not use a (non-trivial) filter-chain and -pix_fmt since
iirc, the output (the filter order) is not defined. (But it is a bad idea
anyway.)

"Scaling" and "Chroma-downsampling" are the same insofar as
they are both done by the scale filter.

Did you already tell us if the content you see is actually interlaced?

As said, please find out what top-posting means and avoid it
here.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org wit

[Katherine Frances]

Post by Carl Eugen Hoyos

Post by Katherine Frances
Thanks again, Andy.
1. *-vf scale=interl=1* registers to libx264 that the input is
interlaced and to be 'aware' of that in future operations.

No, the option is meant to tell the scale filter that it has to
adapt its operations for interlaced content.

Post by Katherine Frances
*yadif*, of course, does the actual deinterlacing.

Yes.

Post by Katherine Frances
2. If used in the same script, *scale* must precede *yadif. *Although

it

Post by Katherine Frances
seems rather redundant.

I would suggest the opposite since giving yadif more information could
help. There may be a performance trade-off though.

Post by Katherine Frances
3. If deinterlacing with *yadif*, *yadif* should precede chroma
downsampling

Same reasoning as above.

Post by Katherine Frances
(via *-pix_fmt yuv420p*)

You should not use a (non-trivial) filter-chain and -pix_fmt since
iirc, the output (the filter order) is not defined. (But it is a bad idea
anyway.)
"Scaling" and "Chroma-downsampling" are the same insofar as
they are both done by the scale filter.
Did you already tell us if the content you see is actually interlaced?
As said, please find out what top-posting means and avoid it
here.
Carl Eugen

Hi Carl,

Thank you for your answer.

Post by Carl Eugen Hoyos
2. If used in the same script, *scale* must precede *yadif. *Although it

Post by Katherine Frances
seems rather redundant.

I would suggest the opposite since giving yadif more information could
help. There may be a performance trade-off though.

If the order is yadif -> scale, how is yadif getting more information?
Sorry, I think I'm missing something here.

You should not use a (non-trivial) filter-chain and -pix_fmt since iirc,

Post by Carl Eugen Hoyos
the output (the filter order) is not defined. (But it is a bad idea anyway.)

I'm not clear on your meaning here. It's not possible to do both of these
operations (deinterlace + chroma-downsample to 4:2:0) in one script?

"Scaling" and "Chroma-downsampling" are the same insofar as they are both

Post by Carl Eugen Hoyos
done by the scale filter.

I didn't realize that scale also takes care of the 4:2:2 -> 4:2:0 change.
Thank you for telling me.

Did you already tell us if the content you see is actually interlaced?
Yes, the source file is definitely interlaced.

I hope this post is formatted correctly. Thank you for your help,

Best, K.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmp

[Carl Eugen Hoyos]

Post by Katherine Frances

Post by Carl Eugen Hoyos

Post by Katherine Frances
2. If used in the same script, *scale* must precede *yadif. *Although
it seems rather redundant.

I would suggest the opposite since giving yadif more information could
help. There may be a performance trade-off though.

If the order is yadif -> scale, how is yadif getting more information?
Sorry, I think I'm missing something here.

The scale filter in general does something destructive with the video
so calling yadif first (which does something fuzzy) means giving yadif
the best chance to produce best output.

If you downscale, calling swscale first can improve performance but
it comes at the cost of possibly worse yadif output.

Note that yadif is not the only deinterlacing filter, see the documentation
(I personally only used yadif for a very long time).

Post by Katherine Frances

Post by Carl Eugen Hoyos
You should not use a (non-trivial) filter-chain and -pix_fmt since iirc,
the output (the filter order) is not defined. (But it is a bad idea anyway.)

I'm not clear on your meaning here. It's not possible to do both of these
operations (deinterlace + chroma-downsample to 4:2:0) in one script?

On the contrary:
If you do "-vf something -pix_fmt ..." there is no guarantee if scale (needed
for "pix_fmt") or "something" is called first. (Even if I am wrong and the order
is documented, it is still not ideal imo to use this syntax.)
So to make sure you have exactly one filter chain (with a defined order)
use the format filter.
If you don't need specific filters (like scale and yadif), using -pix_fmt
allows a simpler syntax.

Post by Katherine Frances
I hope this post is formatted correctly.

No, and I am really surprised how this is possible given the many
examples you have already seen in this very thread.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffm

[Katherine Frances]

Post by Carl Eugen Hoyos
Note that yadif is not the only deinterlacing filter, see the

documentation

Post by Carl Eugen Hoyos
(I personally only used yadif for a very long time).

Yes, I've seen. I chose yadif since I like

Post by Carl Eugen Hoyos
So to make sure you have exactly one filter chain (with a defined order)
use the format filter.
If you don't need specific filters (like scale and yadif), using -pix_fmt
allows a simpler syntax.

Okay, I see the distinction and I think I have a handle on it now. Updated
basic script:

ffmpeg -i input.mov -c:v libx264 -vf 'yadif,format=pix_fmts=yuv420p'
access.mp4

It's working nicely.

Post by Carl Eugen Hoyos
No, and I am really surprised how this is possible given the many
examples you have already seen in this very thread.

Both of us think the other a little rude. Now I understand about the
'interleaved' style replies, so it's sorted. Mea culpa.

Thanks very much for your help,

K.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-re

[Carl Eugen Hoyos]

Post by Katherine Frances
Both of us think the other a little rude.

As far as I am concerned: No.

But thanks for calling me rude, Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmp

[Carl Eugen Hoyos]

Do you think that 'progressive' is default for libx264

Fortunately yes.
(As for any other useful encoder I can think of.)

Please avoid top-posting here, Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org w

[Andy Furniss]

Post by Katherine Frances
ffmpeg -i uncompressed_master.mov -c:v libx264 -pix_fmt yuv420p -c:a
libfdk_aac -b:a 128k access_copy.mp4

If the masters really are interlaced you will slightly break them
doing this.

You need to add -vf scale=interl=1

Additionally ffmpeg git master recently changed this to be better than
it was, so using latest should be best.

To retain interlacing you would also need a different command for libx264.

What to do depends on what you want and what the source really is.

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subject "u