2 pass CBR or VBR not really fixing the bitrate?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio
Hi, I was wondering if anyone has seen similar things.

Trying 2 pass CBR or VBR in ffmpeg


ffmpeg -I <input> -c:v libx264 -pass 1 -f mp4 /dev/null
ffmpeg -I <input> -c:v libx264 -b:v avg -maxrate max -minrate min -bufsize buf -pass 2 <output>

appears to give bitrates that have peak deviations from the average of at least 40%. I tried making maxrate = minrate, 110% of it, removed minrate, removed maxrate, played with different bufsize (1 sec, 2 secs, 1/2 a sec, decreasing it makes the fluctuations smaller but still at 1/2 sec the deviations are large, at 1 sec they are up to 2x from the avg)

I tried multiple versions of ffmpeg and different clips. Is this is a known issue?

Can anyone post an example of a case in which ffmpeg really gets CBR or say 110% VBR?

Thanks!


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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Moritz Barsnick
On Sat, Jul 29, 2017 at 13:16:07 -0700, Manuel Tiglio wrote:
> ffmpeg -I <input> -c:v libx264 -pass 1 -f mp4 /dev/null
> ffmpeg -I <input> -c:v libx264 -b:v avg -maxrate max -minrate min -bufsize buf -pass 2 <output>

Have you tried using the identical video encoding settings for pass 1
and pass 2? I seem to recall that that is important.

> Can anyone post an example of a case in which ffmpeg really gets CBR or say 110% VBR?

I can't, but I can point out that ffmpeg mostly does ABR, not CBR.

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Eric Wilde
At 10:51 PM 7/29/2017 +0200, Moritz Barsnick wrote:
>Have you tried using the identical video encoding settings for pass 1
>and pass 2? I seem to recall that that is important.

Interesting that you say that.  I use "-an" for the first pass and then
"-codec:a libmp3lame -b:a 128k" for the second pass when doing two-pass
recording, and it works fine.  My impression was that audio was
irrelevant for the first pass, since you were only building a set of
compression guide data for the video compressor to use in pass two.

> > Can anyone post an example of a case in which ffmpeg really gets CBR or
> say 110% VBR?
>
>I can't, but I can point out that ffmpeg mostly does ABR, not CBR.

The parameters above work for me.  I tried VBR and could never get audio
that was synchronized properly with the video, using LAME.  Since 128k,
CBR gives acceptable sound, to my ear, and good compression, I wasn't
about to lose sleep over it.  There's too many other reasons why the
audio doesn't synchronize with the video.  I didn't need a self-inflicted
one.

The bitrate is pegged at 128 Kbps (according to MediaInfo) with this set
of parameters.

                                      Eric


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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Moritz Barsnick
On Sat, Jul 29, 2017 at 17:35:39 -0400, Eric Wilde wrote:
> At 10:51 PM 7/29/2017 +0200, Moritz Barsnick wrote:
> >Have you tried using the identical video encoding settings for pass 1
> >and pass 2? I seem to recall that that is important.
>
> Interesting that you say that.  I use "-an" for the first pass and then
> "-codec:a libmp3lame -b:a 128k" for the second pass when doing two-pass
> recording, and it works fine.  My impression was that audio was
> irrelevant for the first pass, since you were only building a set of
> compression guide data for the video compressor to use in pass two.

Please note that I wrote "identical video encoding settings". Indeed,
the docs say it's okay to omit the audio on first pass, while other
sources say it makes a difference, as does the target container.

> The parameters above work for me.  I tried VBR and could never get audio
> that was synchronized properly with the video, using LAME.  Since 128k,
> CBR gives acceptable sound, to my ear, and good compression, I wasn't

Are you talking audio? Yes, libmp3lame hits the target bitrate (be it
ABR or CBR) pretty much spot on. But Manuel obviously asked about
video:

> ffmpeg -I <input> -c:v libx264 -pass 1 -f mp4 /dev/null
> ffmpeg -I <input> -c:v libx264 -b:v avg -maxrate max -minrate min -bufsize buf -pass 2 <output>

And x264 and x265 (or possibly H.264 and H.265) are known to be tricky.

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Eric Wilde
At 12:37 AM 7/30/2017 +0200, Moritz Barsnick wrote:
>Are you talking audio? Yes, libmp3lame hits the target bitrate (be it
>ABR or CBR) pretty much spot on. But Manuel obviously asked about
>video:

Yes, you're right.  I completely missed that, since CBR makes no sense
to me, for video.  As you said, the goal of two pass encoding is to hit
an average bitrate -- which ffmpeg does quite well.

I'm not sure why you'd try to force the codec to have no variations
from the average bit rate because that's not how it works.  Lower bit
counts on frames that don't need a lot of bits (e.g. all black) make
up for higher bit counts on frames that do need a lot of bits (e.g.
motion).  The first pass basically encodes the frames with no limits
and writes their bit counts to the pass file.  The second pass can
then alter how much more it compresses high bit count frames (than the
first pass did) so that it hits the target bit rate.  The average is
all that matters.

But, I'm stating the obvious.  And, I'm probably still missing the
point.  So, I'll clam up and let wiser souls jump in.

                                    Eric


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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio
In reply to this post by Moritz Barsnick
Hi there,

I apologize for my delay in replying, I found that the mailing list messages were being sent to my junk folder :-(

> On Jul 29, 2017, at 1:51 PM, Moritz Barsnick <[hidden email]> wrote:
>
> On Sat, Jul 29, 2017 at 13:16:07 -0700, Manuel Tiglio wrote:
>> ffmpeg -I <input> -c:v libx264 -pass 1 -f mp4 /dev/null
>> ffmpeg -I <input> -c:v libx264 -b:v avg -maxrate max -minrate min -bufsize buf -pass 2 <output>
>
> Have you tried using the identical video encoding settings for pass 1
> and pass 2? I seem to recall that that is important.

Yes, I have tried. All kind of combinations. Interestingly enough, different options do make a difference, in the sense that the results are slightly different,  but still no luck in trying to control the bitrate.

>
>> Can anyone post an example of a case in which ffmpeg really gets CBR or say 110% VBR?
>
> I can't, but I can point out that ffmpeg mostly does ABR, not CBR.

Thanks for sharing! But apparently I cannot even do 110% VBR, it seems to somewhat control the bitrate fluctuations but far from what it should do. I would imagine that people have already gone through this, so I am kind of puzzled.

Thanks again so much.

Manuel


>
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio
In reply to this post by Moritz Barsnick
Hi guys,


> On Jul 29, 2017, at 3:37 PM, Moritz Barsnick <[hidden email]> wrote:
>
> On Sat, Jul 29, 2017 at 17:35:39 -0400, Eric Wilde wrote:
>> At 10:51 PM 7/29/2017 +0200, Moritz Barsnick wrote:
>>> Have you tried using the identical video encoding settings for pass 1
>>> and pass 2? I seem to recall that that is important.
>>
>> Interesting that you say that.  I use "-an" for the first pass and then
>> "-codec:a libmp3lame -b:a 128k" for the second pass when doing two-pass
>> recording, and it works fine.  My impression was that audio was
>> irrelevant for the first pass, since you were only building a set of
>> compression guide data for the video compressor to use in pass two.
>
> Please note that I wrote "identical video encoding settings". Indeed,
> the docs say it's okay to omit the audio on first pass, while other
> sources say it makes a difference, as does the target container.
>
>> The parameters above work for me.  I tried VBR and could never get audio
>> that was synchronized properly with the video, using LAME.  Since 128k,
>> CBR gives acceptable sound, to my ear, and good compression, I wasn't
>
> Are you talking audio? Yes, libmp3lame hits the target bitrate (be it
> ABR or CBR) pretty much spot on. But Manuel obviously asked about
> video:
>

You are right Moritz, I am talking about video.


>> ffmpeg -I <input> -c:v libx264 -pass 1 -f mp4 /dev/null
>> ffmpeg -I <input> -c:v libx264 -b:v avg -maxrate max -minrate min -bufsize buf -pass 2 <output>
>
> And x264 and x265 (or possibly H.264 and H.265) are known to be tricky.

I guess so, but has anyone had “luck” trying to control the video bitrate fluctuations? I am more than happy to share my experience and details with some CC video, such as Sintel, or any other. I haven’t done that yet so as not to spam everyone, but it is kind of interesting I’d say.

Decreasing the buffer size improves the fluctuations (they become smaller) but going down to 0.5 secs already seems like a stretch.

Cheers

Manuel


>
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio
In reply to this post by Eric Wilde
Eric,


> On Jul 29, 2017, at 9:00 PM, Eric Wilde <[hidden email]> wrote:
>
> At 12:37 AM 7/30/2017 +0200, Moritz Barsnick wrote:
>> Are you talking audio? Yes, libmp3lame hits the target bitrate (be it
>> ABR or CBR) pretty much spot on. But Manuel obviously asked about
>> video:
>
> Yes, you're right.  I completely missed that, since CBR makes no sense
> to me, for video.  As you said, the goal of two pass encoding is to hit
> an average bitrate -- which ffmpeg does quite well.
>
> I'm not sure why you'd try to force the codec to have no variations
> from the average bit rate because that's not how it works.  Lower bit
> counts on frames that don't need a lot of bits (e.g. all black) make
> up for higher bit counts on frames that do need a lot of bits (e.g.
> motion).  The first pass basically encodes the frames with no limits
> and writes their bit counts to the pass file.  The second pass can
> then alter how much more it compresses high bit count frames (than the
> first pass did) so that it hits the target bit rate.  The average is
> all that matters.
>
> But, I'm stating the obvious.  And, I'm probably still missing the
> point.  So, I'll clam up and let wiser souls jump in.

If you want to stream and build ladders you want to control the peak bitrate, not just the average. That’s the point that I was trying to convey.


>
>                                   Eric
>
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Nicolas George
Le duodi 12 thermidor, an CCXXV, Manuel Tiglio a écrit :
> If you want to stream and build ladders you want to control the peak
> bitrate, not just the average. That’s the point that I was trying to
> convey.

Not exactly. Clients have a limited buffering ability, and what you need
to control is the average bitrate over the duration of the buffer.

And two-pass encoding is not meant for that. Two-pass encoding is meant
to optimize the bitrate globally, for when you want to fit a movie on
exactly 2×700 mega-octets so you can burn it on a pair of CD-R.

Regards,

--
  Nicolas George

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio

> On Jul 31, 2017, at 1:39 AM, Nicolas George <[hidden email]> wrote:
>
> Le duodi 12 thermidor, an CCXXV, Manuel Tiglio a écrit :
>> If you want to stream and build ladders you want to control the peak
>> bitrate, not just the average. That’s the point that I was trying to
>> convey.
>
> Not exactly. Clients have a limited buffering ability, and what you need
> to control is the average bitrate over the duration of the buffer.


Apple HLS Authoring does not seem to agree with you

https://developer.apple.com/library/content/documentation/General/Reference/HLSAuthoringSpec/Requirements.html#//apple_ref/doc/uid/TP40016596-CH2-SW1 <https://developer.apple.com/library/content/documentation/General/Reference/HLSAuthoringSpec/Requirements.html#//apple_ref/doc/uid/TP40016596-CH2-SW1>

1.23. For VOD content the peak bit rate SHOULD be no more than 200% of the average bit rate.

(actually before early this year it used to be 110%).


>
> And two-pass encoding is not meant for that. Two-pass encoding is meant
> to optimize the bitrate globally, for when you want to fit a movie on
> exactly 2×700 mega-octets so you can burn it on a pair of CD-R.

Two pass encoding is used for CBR and constrained VBR. If you use it for something else, that is great but it is not my question.




>
> Regards,
>
> --
>  Nicolas George
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Nicolas George
Le tridi 13 thermidor, an CCXXV, Manuel Tiglio a écrit :
> 1.23. For VOD content the peak bit rate SHOULD be no more than 200% of the average bit rate.

Without a proper definition of "peak bit rate", this sentence is
meaningless. A bit rate is a quantity of information divided by a time.
Since it is discrete, there is no way of doing calculus, and therefore
there is no notion of instantaneous bit rate. Thus, without saying the
period of time on which the bit rate is computed, it does not mean
anything.

> Two pass encoding is used for CBR and constrained VBR.

No, not for CBR. For CBR, you use all bits allowed, period.

Regards,

--
  Nicolas George

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Jon bae
In reply to this post by Manuel Tiglio
Am 31.07.2017 um 03:52 schrieb Manuel Tiglio:

> Hi there,
>
> I apologize for my delay in replying, I found that the mailing list messages were being sent to my junk folder :-(
>
>> On Jul 29, 2017, at 1:51 PM, Moritz Barsnick <[hidden email]> wrote:
>>
>> On Sat, Jul 29, 2017 at 13:16:07 -0700, Manuel Tiglio wrote:
>>> ffmpeg -I <input> -c:v libx264 -pass 1 -f mp4 /dev/null
>>> ffmpeg -I <input> -c:v libx264 -b:v avg -maxrate max -minrate min -bufsize buf -pass 2 <output>
>> Have you tried using the identical video encoding settings for pass 1
>> and pass 2? I seem to recall that that is important.
> Yes, I have tried. All kind of combinations. Interestingly enough, different options do make a difference, in the sense that the results are slightly different,  but still no luck in trying to control the bitrate.
>
>>> Can anyone post an example of a case in which ffmpeg really gets CBR or say 110% VBR?
>> I can't, but I can point out that ffmpeg mostly does ABR, not CBR.
> Thanks for sharing! But apparently I cannot even do 110% VBR, it seems to somewhat control the bitrate fluctuations but far from what it should do. I would imagine that people have already gone through this, so I am kind of puzzled.
>
> Thanks again so much.
Hi,
how about this command?:

ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M

Source: https://trac.ffmpeg.org/wiki/Encode/H.264

Of course it needs a bit modification to fit your two pass encoding. You just worry about hls, or your really need to get this close persistence?
Because we make life streaming with crf and maxrate/buffsize over hls and never had problems with it.

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio
In reply to this post by Nicolas George

> On Jul 31, 2017, at 11:29 AM, Nicolas George <[hidden email]> wrote:
>
> Le tridi 13 thermidor, an CCXXV, Manuel Tiglio a écrit :
>> 1.23. For VOD content the peak bit rate SHOULD be no more than 200% of the average bit rate.
>
> Without a proper definition of "peak bit rate", this sentence is
> meaningless.

Are you saying that Apple’s authoring requirements for HLS are meaningless?

> A bit rate is a quantity of information divided by a time.
> Since it is discrete, there is no way of doing calculus, and therefore
> there is no notion of instantaneous bit rate. Thus, without saying the
> period of time on which the bit rate is computed, it does not mean
> anything.

When doing streaming you typically send packets of 6-10 secs, so in that interval the peak (i.e. maximum value) bitrate does not have to exceed 10% (110% constrained VBR) or 100% (200% constrained VBR) of the average bitrate in that interval.

But the exact value of that length of time is irrelevant.

The fact that it is a discrete series is also irrelevant, you can compute discrete bitrates in the same way that you compute finite differences (for example).  

This is really really standard for anyone working on streaming. What is not standard is that ffmpeg has such large fluctuations between the peak and average bitrate

>
>> Two pass encoding is used for CBR and constrained VBR.
>
> No, not for CBR. For CBR, you use all bits allowed, period.

Can you type a typical example of what you mean for that? CBR is a 100% constrained VBR (i.e. ideally no fluctuations in the bitrate from its average), essentially.

Thanks!


>
> Regards,
>
> --
>  Nicolas George
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio
In reply to this post by Jon bae
Hi Jonathan,

This helps

> Hi,
> how about this command?:
>
> ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M
>
> Source: https://trac.ffmpeg.org/wiki/Encode/H.264
>

Will give it a try. I had seen in other forums discussing this same issued and that this should work, but ‘nal-hrd=cbr” only work for producing ts files. I was wondering if one could also control the bitrate prior to that, at the mp4 level.

Notice that in the documentation that you quote, just below this example, it says

Constained encoding (VBV / maximum bit rate) <https://trac.ffmpeg.org/wiki/Encode/H.264#ConstainedencodingVBVmaximumbitrate>
You can also use -crf or -b:v with a maximum bit rate by specifying both  -maxrate and -bufsize:

ffmpeg -i input -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M output.mp4
This will effectively "target" -crf 23, but if the output were to exceed 1 MBit/s, the encoder would increase the CRF to prevent bitrate spikes. However, be aware that libx264does not strictly control the maximum bit rate as you specified (the maximum bit rate may be well over 1M for the above file). To reach a perfect maximum bit rate, use two-pass.

In another example, instead of using constant quality (CRF) as a target, the average bitrate is set. A two-pass approach is preferred here:

ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f mp4 /dev/null
ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 output.mp4

And that, does not seem to work as advertised. That is, the two pass encoding still gives a max rate which is far from the specified target (1M in the above example).

Somebody must have gone through this before.


> Of course it needs a bit modification to fit your two pass encoding.

That would be fine. But ideally I would like to have the mp4 files with bitrate control before transmuxing, and keep those mp4 files in case they need to be reused for a number of reasons.

> You just worry about hls, or your really need to get this close persistence?
> Because we make life streaming with crf and maxrate/buffsize over hls and never had problems with it.

Interesting, as in above? Ie

> ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M

What does seem to work in ffmpeg is capped crf (in the sense that the obtained crf is close to the specified cap value), but then the lower bitrates are far from that cap and there is degradation in quality.

Ideally I would like to do 110% VBV, which changing the 2-pass example should be achieved by

ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f mp4 /dev/null
ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1.1M -bufsize 2M -pass 2 output.mp4
Or with a bufsize of 1M (one sec)

Thanks Jonathan, would you mind following up on my comments above? I really appreciate it.

Manuel


>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Nicolas George
In reply to this post by Manuel Tiglio
Le tridi 13 thermidor, an CCXXV, Manuel Tiglio a écrit :
> Are you saying that Apple’s authoring requirements for HLS are meaningless?

Unless there are extra definitions that you neglected to quote, yes.
Unless you intend to burn me at the stake for bad-mouthing Apple, of
course, in that case I deny everything.

> When doing streaming you typically send packets of 6-10 secs, so in
> that interval the peak (i.e. maximum value) bitrate does not have to
> exceed 10% (110% constrained VBR) or 100% (200% constrained VBR) of
> the average bitrate in that interval.
>
> But the exact value of that length of time is irrelevant.

Quite the opposite, it is very relevant. Unless you are using
intra-refresh, I-frames will be significantly bigger than P- and
B-frames. Therefore, whether the window used for averaging is larger or
narrower than the interval between I-frames is very important.

> The fact that it is a discrete series is also irrelevant, you can
> compute discrete bitrates in the same way that you compute finite
> differences (for example).  

Exactly: only an average over a period.

> Can you type a typical example of what you mean for that? CBR is a
> 100% constrained VBR (i.e. ideally no fluctuations in the bitrate from
> its average), essentially.

Except it does not mean anything practical.

Regards,

--
  Nicolas George

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Andy Furniss-2
In reply to this post by Manuel Tiglio
Manuel Tiglio wrote:

>
>> On Jul 31, 2017, at 11:29 AM, Nicolas George <[hidden email]>
>> wrote:
>>
>> Le tridi 13 thermidor, an CCXXV, Manuel Tiglio a écrit :
>>> 1.23. For VOD content the peak bit rate SHOULD be no more than
>>> 200% of the average bit rate.
>>
>> Without a proper definition of "peak bit rate", this sentence is
>> meaningless.
>
> Are you saying that Apple’s authoring requirements for HLS are
> meaningless?
>
>> A bit rate is a quantity of information divided by a time. Since it
>> is discrete, there is no way of doing calculus, and therefore there
>> is no notion of instantaneous bit rate. Thus, without saying the
>> period of time on which the bit rate is computed, it does not mean
>> anything.
>
> When doing streaming you typically send packets of 6-10 secs, so in
> that interval the peak (i.e. maximum value) bitrate does not have to
> exceed 10% (110% constrained VBR) or 100% (200% constrained VBR) of
> the average bitrate in that interval.
>
> But the exact value of that length of time is irrelevant.
>
> The fact that it is a discrete series is also irrelevant, you can
> compute discrete bitrates in the same way that you compute finite
> differences (for example).
>
> This is really really standard for anyone working on streaming. What
> is not standard is that ffmpeg has such large fluctuations between
> the peak and average bitrate

You are encoding with libx264 not ffmpeg, it's just passing params.

What are you using to measure these "large fluctuations" and over what
timescale?

I see in the guide you linked that chunks are required to start with an
I frame - these for the same quality are usually far bigger than b or p
frames, so if you measure over small time there is bound to be a high
variation.

FWIW the player buffer size constraint AIUI is meant to absorb these
sort of things when fed at a constant/limited rate = it's not a
parameter that means the bitstream will at a small scale be constant
rate, it means the player using that buffer size at a certain "feed"
rate will not under/overflow when it meets short term fluctuations. If
you set it too small in some effort to make the encoder avoid these you
will likely end up with I frame pulsing.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio
In reply to this post by Nicolas George

>
>> When doing streaming you typically send packets of 6-10 secs, so in
>> that interval the peak (i.e. maximum value) bitrate does not have to
>> exceed 10% (110% constrained VBR) or 100% (200% constrained VBR) of
>> the average bitrate in that interval.
>>
>> But the exact value of that length of time is irrelevant.
>
> Quite the opposite, it is very relevant. Unless you are using
> intra-refresh, I-frames will be significantly bigger than P- and
> B-frames. Therefore, whether the window used for averaging is larger or
> narrower than the interval between I-frames is very important.

Correct. I tried first fixing the distance between keyframes to 2 seconds and then 2-pass VBV and the other way around and also not fixing the distance between keyframes.

I think I see your point now. To answer your question, the average is done through the entire video, so in a much longer timescale than the distance between keyframes. By looking at the data (I can send you some plots) I’d say that decreasing the averaging time would not change much, but I can try. Any recommendations on that?


>> The fact that it is a discrete series is also irrelevant, you can
>> compute discrete bitrates in the same way that you compute finite
>> differences (for example).  
>
> Exactly: only an average over a period.
>
>> Can you type a typical example of what you mean for that? CBR is a
>> 100% constrained VBR (i.e. ideally no fluctuations in the bitrate from
>> its average), essentially.
>
> Except it does not mean anything practical.

What do you mean?

Manuel


>
> Regards,
>
> --
>  Nicolas George
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Jon bae
In reply to this post by Manuel Tiglio
Am 31.07.2017 um 20:52 schrieb Manuel Tiglio:

> Hi Jonathan,
>
> This helps
>
>> Hi,
>> how about this command?:
>>
>> ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M
>>
>> Source: https://trac.ffmpeg.org/wiki/Encode/H.264
>>
> Will give it a try. I had seen in other forums discussing this same issued and that this should work, but ‘nal-hrd=cbr” only work for producing ts files. I was wondering if one could also control the bitrate prior to that, at the mp4 level.
>
> Notice that in the documentation that you quote, just below this example, it says
>
> Constained encoding (VBV / maximum bit rate) <https://trac.ffmpeg.org/wiki/Encode/H.264#ConstainedencodingVBVmaximumbitrate>
> You can also use -crf or -b:v with a maximum bit rate by specifying both  -maxrate and -bufsize:
>
> ffmpeg -i input -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M output.mp4
> This will effectively "target" -crf 23, but if the output were to exceed 1 MBit/s, the encoder would increase the CRF to prevent bitrate spikes. However, be aware that libx264does not strictly control the maximum bit rate as you specified (the maximum bit rate may be well over 1M for the above file). To reach a perfect maximum bit rate, use two-pass.
>
> In another example, instead of using constant quality (CRF) as a target, the average bitrate is set. A two-pass approach is preferred here:
>
> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f mp4 /dev/null
> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 output.mp4
>
> And that, does not seem to work as advertised. That is, the two pass encoding still gives a max rate which is far from the specified target (1M in the above example).
>
> Somebody must have gone through this before.
>
>
>> Of course it needs a bit modification to fit your two pass encoding.
> That would be fine. But ideally I would like to have the mp4 files with bitrate control before transmuxing, and keep those mp4 files in case they need to be reused for a number of reasons.
>
>> You just worry about hls, or your really need to get this close persistence?
>> Because we make life streaming with crf and maxrate/buffsize over hls and never had problems with it.
> Interesting, as in above? Ie
>
>> ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M
> What does seem to work in ffmpeg is capped crf (in the sense that the obtained crf is close to the specified cap value), but then the lower bitrates are far from that cap and there is degradation in quality.
>
> Ideally I would like to do 110% VBV, which changing the 2-pass example should be achieved by
>
> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f mp4 /dev/null
> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1.1M -bufsize 2M -pass 2 output.mp4
> Or with a bufsize of 1M (one sec)
>
> Thanks Jonathan, would you mind following up on my comments above? I really appreciate it.
>
> Manuel
Hi Manuel,
I don't believe nal-hrd=cbr is only for ts, because it is a x264
parameter, not an ffmpeg paramter. And as I know x264 don't know ts, ts
is just the container, or not?
There is also a mode: nal-hrd=vbr, maybe this fills more your need,
because you don't want 100% constant.

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Manuel Tiglio

> On Jul 31, 2017, at 12:11 PM, Jonathan Baecker <[hidden email]> wrote:
>
> Am 31.07.2017 um 20:52 schrieb Manuel Tiglio:
>> Hi Jonathan,
>>
>> This helps
>>
>>> Hi,
>>> how about this command?:
>>>
>>> ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M
>>>
>>> Source: https://trac.ffmpeg.org/wiki/Encode/H.264
>>>
>> Will give it a try. I had seen in other forums discussing this same issued and that this should work, but ‘nal-hrd=cbr” only work for producing ts files. I was wondering if one could also control the bitrate prior to that, at the mp4 level.
>>
>> Notice that in the documentation that you quote, just below this example, it says
>>
>> Constained encoding (VBV / maximum bit rate) <https://trac.ffmpeg.org/wiki/Encode/H.264#ConstainedencodingVBVmaximumbitrate>
>> You can also use -crf or -b:v with a maximum bit rate by specifying both  -maxrate and -bufsize:
>>
>> ffmpeg -i input -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M output.mp4
>> This will effectively "target" -crf 23, but if the output were to exceed 1 MBit/s, the encoder would increase the CRF to prevent bitrate spikes. However, be aware that libx264does not strictly control the maximum bit rate as you specified (the maximum bit rate may be well over 1M for the above file). To reach a perfect maximum bit rate, use two-pass.
>>
>> In another example, instead of using constant quality (CRF) as a target, the average bitrate is set. A two-pass approach is preferred here:
>>
>> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f mp4 /dev/null
>> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 output.mp4
>>
>> And that, does not seem to work as advertised. That is, the two pass encoding still gives a max rate which is far from the specified target (1M in the above example).
>>
>> Somebody must have gone through this before.
>>
>>
>>> Of course it needs a bit modification to fit your two pass encoding.
>> That would be fine. But ideally I would like to have the mp4 files with bitrate control before transmuxing, and keep those mp4 files in case they need to be reused for a number of reasons.
>>
>>> You just worry about hls, or your really need to get this close persistence?
>>> Because we make life streaming with crf and maxrate/buffsize over hls and never had problems with it.
>> Interesting, as in above? Ie
>>
>>> ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M
>> What does seem to work in ffmpeg is capped crf (in the sense that the obtained crf is close to the specified cap value), but then the lower bitrates are far from that cap and there is degradation in quality.
>>
>> Ideally I would like to do 110% VBV, which changing the 2-pass example should be achieved by
>>
>> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f mp4 /dev/null
>> ffmpeg -i input -c:v libx264 -b:v 1M -maxrate 1.1M -bufsize 2M -pass 2 output.mp4
>> Or with a bufsize of 1M (one sec)
>>
>> Thanks Jonathan, would you mind following up on my comments above? I really appreciate it.
>>
>> Manuel
> Hi Manuel,
> I don't believe nal-hrd=cbr is only for ts, because it is a x264 parameter, not an ffmpeg paramter. And as I know x264 don't know ts, ts is just the container, or not?
> There is also a mode: nal-hrd=vbr, maybe this fills more your need, because you don't want 100% constant.

Thanks Jon, let me try that out and report back to you guys. You are right, I’d prefer 110%

I had read that those parameters are for ts in fact in the example that you sent from that ffmpeg page it actually reads

ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M output.ts

But I will give it a shot.


Manuel
>
> Jonathan
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2 pass CBR or VBR not really fixing the bitrate?

Andy Furniss-2
Manuel Tiglio wrote:

> ffmpeg -i input.mp4 -c:v libx264 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M output.ts
>
> But I will give it a shot.

Also see x264 --fullhelp WRT nal-hrd=cbr, it may not be what you need,
no mp4 and possible "filling".

  x264 --fullhelp | grep nal-hrd -A 3
       --nal-hrd <string>      Signal HRD information (requires vbv-bufsize)
                                   - none, vbr, cbr (cbr not allowed in
.mp4)
       --filler                Force hard-CBR and generate filler
(implied by
                               --nal-hrd cbr)

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

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12
Loading...