Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

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
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Katherine Frances]

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

> 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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

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

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

> 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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Katherine Frances]

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
> >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.
>
> > *yadif*, of course, does the actual deinterlacing.
>
> Yes.
>
> >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.
>
> >3. If deinterlacing with *yadif*, *yadif* should precede chroma
> >downsampling
>
> Same reasoning as above.
>
> > (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.

Here I'm confused:

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

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?

"Scaling" and "Chroma-downsampling" are the same insofar as they are both
> 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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

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 scale filter that it has to
adapt its operations for interlaced content.

> *yadif*, of course, does the actual deinterlacing.

Yes.

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

>3. If deinterlacing with *yadif*, *yadif* should precede chroma
>downsampling

Same reasoning as above.

> (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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

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 mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[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
, which is the default
anyway).

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

Best, K.


On Sun, Feb 26, 2017 at 11:34 PM, Andy Furniss  wrote:

> Katherine Frances wrote:
>
>> 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-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

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

On Sun, Feb 26, 2017 at 1:31 PM, Kieran O Leary 
wrote:

> 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/
> trunk/pixfmt_8h_source.html
>
> 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?
> >
> >
> 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-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Kieran O Leary]

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/
trunk/pixfmt_8h_source.html

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?
>
>
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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Andy Furniss]

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 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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[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


On Sun, Feb 26, 2017 at 11:35 AM, Marton Balint  wrote:

>
> 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 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.
>
>
>> 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?
>>
>>
> 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-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Marton Balint]

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




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?



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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[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

On Sun, Feb 26, 2017 at 11:06 AM, Marton Balint  wrote:

>
> 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 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-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Marton Balint]

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 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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Katherine Frances]

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 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-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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