[FFmpeg-user] Simultaneous two-pass?

[Jesse Gordon]

On 09/27/2012 03:26 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.
> No, the original idea was to fit a video of a given length
> exactly on one CD (or DVD) with the best possible over-all
> quality.
>
> What you want is one-pass encoding with some options
> (see other answers).
Oh! OK! I hadn't even thought of that! That does make sense though.

In the case of a DVD or something, it would make perfect sense to encode 
that way because there's no particular bandwidth bottleneck.

But that's not so much constant bit rate as it is constant filesize or 
something... ha ha :)

> [...]
>
>>>> 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.
>>>
>> I tried a few -threads options and nothing seemed to change
>> anything. It could be that the flv encoder doesn't support
>> threads.
> Correct, see ffmpeg -encoders
Ah - I just checked - flv does not support threading. So that's why it 
was 160% - it was using 60% of one CPU to decode the source file and 
100% of another CPU to encode it. Good enough.

>> 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.
> I suspect this should be (significantly?) faster if done
> in one FFmpeg instance.
>
> Carl Eugen
Well, I'm encoding to flv which does not support any threading, and I 
have 8 cores.
So I can clearly get more work done faster by running several ffmpeg 
instances at the same time.

However, if you are saying that I don't need to do two passes because 
I'm not fitting the video to a fixed size disk, then yes encoding two 
passes just makes it take twice as long.

I'll have two do some two pass and one pass comparisons and see if one 
looks any better than the other.

I'm recoding any user uploaded video file into flv.
Because I want viewers with internet bottlenecks to be able to view it, 
I want the bitrate to be relatively constant -- however, splurging for 
part of a second when it can be made up in the remaining part of the 
second is OK.

Is there a way I can (for example) set ffmpeg to do just that - for 
example allow the bitrate to go up to double as long as the average for 
any 2 seconds of video was within the specified rate?

The only things relating to vbuffer which I found in the man page were 
-hdvbuffer/dvbuffer that is related to capturing from digital video 
hardware -- which doesn't seem to apply to my case.

Thanks very much,

Jesse Gordon

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