[FFmpeg-devel] [rfc][soc] ffmpeg behaviour

Luca Barbato lu_zero
Wed Mar 9 01:41:21 CET 2011

On 03/09/2011 12:41 AM, Stefano Sabatini wrote:
> On date Tuesday 2011-03-08 21:24:12 +0100, Luca Barbato encoded:
>> Recently I started to use ffmpeg in some specific ways (as you could see
>> from the data-support patch) and I noticed it is completely counter
>> intuitive how certain settings are set by default if you start using
>> containers with more than a stream per type, more than an output and such.
>> I'd like to change the current parsing so that
>> ffmpeg -i input-with-N-video-streams out.something
>> Doesn't set the size of all the output streams to the size of the last
>> stream in the input container and such similar unexpected behaviours.
> I suppose the sane behavior would be to keep the same size for all the
> output streams (but in this case what should be the behavior of -s or
> -vf?).

the fact is that if you have two video streams that are the same but one
scaled down, you'd like that encoding them would preserve the different
size. or at least that's what I'd expect.

>> In addition our minimalistic approach to the networking is biting us
>> while we try to stream live contents for long times (I mean even hours,
>> not just days...) apparently causing desync between audio and video
>> while using ffmpeg as producer for live streaming...
> I wonder if ffmpeg is supposed to be used that way, -re looks
> definitively underkill and I can imagine all kinds of things going
> wrong for such usage.

ffmpeg is quite ok if your network is localhost ^^; Would be nicer
having it working fine on a more realistic network...

>> Any other opinions? Probably making ffmpeg more useful might fit a
>> summer of code task quite well (lots of small, self contained task and
>> few all encompassing refactors)
> On the other hand ffmpeg is one of the most complex and delicate
> pieces of the whole project, so I'm not sure it would be feasible as a
> soc task for an inexperienced FFmpeg programmer (for which IMO the
> ideal task is something possibly self-contained and not too close to
> the core).

I'd rather have the student start from scratch and have this experience
to refine both the program and the api.


PS: just for fun I tried to write something that _just_ streamcopies,
after about 1h of "ops I should copy that field as well" and "why don't
we have sane default for our fractional fields" I just got something
that works fine just with nut <-> nut. I'd expect that same<->container
could work for other format but obviously does not. I recycled it as
proof of concept for something more crazy but that's another story...


Luca Barbato

More information about the ffmpeg-devel mailing list