2017-02-26 13:59 GMT+01:00 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-user@ffmpeg.org
On Mon, Feb 27, 2017 at 12:56 AM, Carl Eugen Hoyos
wrote:
> Note that yadif is not the only deinterlacing filter, see the
documentation
> (I personally only used yadif for a very long time).
Yes, I've seen. I chose yadif since I like
> So to make sure you have exactly one
2017-02-26 12:44 GMT+01:00 Katherine Frances :
> On Mon, Feb 27, 2017 at 12:19 AM, Carl Eugen Hoyos
> wrote:
>> >2. If used in the same script, *scale* must precede *yadif. *Although
>> > it seems rather redundant.
>>
>> I would suggest the opposite
On Mon, Feb 27, 2017 at 12:19 AM, Carl Eugen Hoyos
wrote:
> 2017-02-26 12:11 GMT+01:00 Katherine Frances :
> > Thanks again, Andy.
> > So if I understand correctly:
> >
> >1. *-vf scale=interl=1* registers to libx264 that the input is
> >
2017-02-26 12:11 GMT+01:00 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.
No, the option is meant to tell the
2017-02-25 23:54 GMT+01:00 Katherine Frances :
> 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
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.
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
Hi Katherine!
On Sat, Feb 25, 2017 at 10:54 PM, Katherine Frances
wrote:
> 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/
Katherine Frances wrote:
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
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?
On Sun, 26 Feb 2017, Katherine Frances wrote:
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.
Inputs are uncompressed v210 in MOV. They're definitely
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
On Sun, 26 Feb 2017, Katherine Frances wrote:
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
To be clear, the MediaInfo specs quoted refer to the deinterlaced output
file.
On Sun, Feb 26, 2017 at 10:50 AM, Katherine Frances
wrote:
> Hi all,
>
> When transcoding to H.264 from an interlaced 4:2:2 original, I always add
> the flag *-pix_fmt yuv420p*, which obviously
15 matches
Mail list logo