Re: [FFmpeg-user] Questions about the concat video filter

[Katherine Frances]

Kia ora Dave,

> Some audio encodings don’t support arbitrary sample counts, so it’s not 
> uncommon that the audio and video encodings of a file has minor fluctuations 
> in their duration. Also video and audio sampling rates often has different 
> timebases so it’s usually not feasible for their durations to be the same. 
> For instance you may have a second of 48000 Hz audio, but it is not possible 
> to have one second of an NTSC (3/1001 fps) recording.
> So for instance concatenating a segment of video + audio with another segment 
> of video + audio would be more accurate, then concatenating 2 audio encodings 
> and separately concatenating 2 video encodings and then hopefully that they 
> will still align.


Yes, it makes total sense that audio & video streams should be
specified as such, so that everything stays in step. Thank you for the
confirmation.

> No unless you provide that black slug. In this case the duration of the last 
> frame will be longer to cover the missing video.


Thanks. That command is a perfect demo.

> If you know what you want the output to be then you should clarify, otherwise 
> it leaves the guesswork to ffmpeg which may or may not be want you want.


Haha, got it.

Cheers Dave, I really appreciate your thoughtful answers!

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] Questions about the concat video filter

[Katherine Frances]

Ugh another typo - *higher*-quality. I'm so sorry. Anyway, is that anything
to do with the concat filter, or again just a matter of general encoding
defaults?
___
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] Questions about the concat video filter

[Katherine Frances]

Hi Carl Eugen,

It tries hard...


Haha, alright then.

As for default output specs - okay, now I see that I was over-thinking that
a bit, and wrongly assuming that there was something specific to the concat
filter happening there. One of my input files was an H.264/MP4 that
happened to have specs very close to the default libx264 encoding settings,
so that's probably what put the idea in my head and confused matters. My
bad! I'm up to date now, strike that question.
But as for the pix_fmt - for the test files I've created, ffmpeg selects
the lesser-quality chroma subsampling scheme for the output. Can I assume
this as a general rule of thumb?

Cheers, 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] Questions about the concat video filter

[Katherine Frances]

Opps, accidental (and ironic) typo. In the previous message, I meant to
write "but I don't find the wording very clear", not the double negative I
actually sent.
___
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] Questions about the concat video filter

[Katherine Frances]

Hi all,

I've been investigating the concat filter recently, and after the
documentation at https://ffmpeg.org/ffmpeg-filters.html#concat and the wiki
page at https://trac.ffmpeg.org/wiki/Concatenate#differentcodec, I have a
couple of further questions.

The documentation says,

Related streams do not always have exactly the same duration, for various
> reasons including codec frame size or sloppy authoring. For that reason,
> related synchronized streams (e.g. a video and its audio track) should be
> concatenated at once.
>

It's the wording "at once" that is tripping me up. Does it mean 'together'?
i.e., all streams from a given input should be specified in order, as shown
in the examples, rather than grouping e.g. the video streams from each
input, then the audio streams from each input?

Further,

The concat filter will use the duration of the longest stream in each
> segment (except the last one), and if necessary pad shorter audio streams
> with silence.
>

Can I then assume that in the case in which the video stream is shorter, it
will be padded with black slug?

Further, if the specs for the output streams are not explicitly set by the
user, how does FFmpeg 'decide' what codec & options etc to use? The docs
say:

the filtering system will automatically select a common pixel format for
> video streams, and a common sample format, sample rate and channel layout
> for audio streams, but other settings, such as resolution, must be
> converted explicitly by the user.
>

but I don't find the wording isn't very clear. From my tests, it seems to
default to something similar to the specs of the lower-quality input? I
wonder if someone can confirm, or give some more information about the
default output codec settings.

Disclaimer: these might be noob questions to some of you, but for me it's
not obvious, so I would appreciate clarification. Thank you.

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

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

[Katherine Frances]

On Mon, Feb 27, 2017 at 12:19 AM, Carl Eugen Hoyos <ceffm...@gmail.com>
wrote:

> 2017-02-26 12:11 GMT+01:00 Katherine Frances <knfran...@gmail.com>:
> > 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

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


On Sun, Feb 26, 2017 at 11:34 PM, Andy Furniss <adf.li...@gmail.com> 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 <kieran.o.le...@gmail.com>
wrote:

> Hi Katherine!
>
> On Sat, Feb 25, 2017 at 10:54 PM, Katherine Frances <knfran...@gmail.com>
> 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

[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 <c...@passwd.hu> 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

[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 <c...@passwd.hu> 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

[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 <knfran...@gmail.com>
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".