[FFmpeg-user] Simultaneous two-pass?

[Jesse Gordon]

On 09/27/2012 01:57 AM, Carl Eugen Hoyos wrote:
> Jesse Gordon <tojesseg <at> gmail.com> writes:
>
>> But I suppose there is a limit to how far ahead
>> bandwidth can be borrowed.
> Why do you think so?
> I don't think it is true in the general case.

Oh, I just figured that the whole point of fixed rate encoding was for 
streaming over a limited bandwidth connection to a device that may or 
may not have a large buffer.

Even if the video codec allowed data for the end of the movie to start 
collecting for the end of the movie:

For example, if a 1 hour video had 90% of its action in the first 10 
minutes, the bitrate for the first ten minutes would be so high that the 
viewer would have to wait a long time for it to buffer because the 
bitrate for the first 10 minutes would be much higher then the stated 
"fixed bitrate," even though it would average out due to the rest of the 
film being slow moving.

Likewise, if the last 10 minutes had all the action, then, for the first 
50 minutes, all the data would have to be stored on the player until the 
last 10 minutes finally arrived -- and I suppose some stand-alone 
devices might not want to have to

But my guess is that most two-pass type constant bitrate codecs don't 
allow the transferring and storing of frames out of order.

So I guess my point is that two-pass fixed bitrate isn't really fixed, 
but that within about a given second or so, the bitrate may vary far 
above and far below the specified rate, but averaged over several 
seconds it is exactly at its fixed bit rate. This allows short buffers 
to deal with the actual lack of constancy of the bitrate.

Any player could very reasonably be expected to deal with bit rate 
changes that average out within a few seconds, but I doubt they would be 
expected to deal with having to buffer 10 minutes of video just to 
average out the bit rate.


All I'm saying is that there's probably a window of acceptable deviation 
from the stated constant bitrate, and it's probably no more than a few 
seconds for most fixed rate codecs. If a codec is allowed to "splurge" 
and go many times over its fixed rate for 10 minutes because it knows 
that it'll be slow later in the film, it will (for those 10 minutes) be 
unplayable due to constant buffering.


>> All I want is to run the second pass just one
>> borrow-window's-width behind the first pass
> Isn't that what one-pass encoding with a set
> bit-rate does?
Well, that depends. I believe that the second pass could begin before 
the first pass is done because the second pass doesn't need to know how 
the 1000th frame looks in order to encode the first frame...

The second pass can encode at twice the stated bitrate for one second if 
it knows that there is a quiet period after that second. It cannot, however,
encode at twice the stated bitrate for 10 minutes even if it does know 
there is a slow period after that which could make up for it because the 
player probably doesn't have 10 minutes in the future buffered up yet.

> [...]
>
>> I have 8 cores in my CPU and I did notice that ffmpeg
>> was using about "160%" which means almost 2 cores.
>> However, idle was still around 80%,
> Play with different values for -threads
> And note that not all encoders and not
> all decoders support multi-threading.
>
> Carl Eugen
I tried a few -threads options and nothing seemed to change anything. It 
could be that the flv encoder doesn't support threads.
But that's OK because whenever a user uploads a video, it has to be 
converted into half a dozen different sizes and rates to accomodate 
viewers with different internet speeds, so I can just launch several 
instances in parallel.

Thanks very much,

Jesse Gordon

> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>