[FFmpeg-devel] [RFC] Eliminate -re and make -rate_emu set by AVOption

Luca Abeni lucabe72
Thu Jul 17 08:40:37 CEST 2008


Hi Stefano,

Stefano Sabatini wrote:
[..]
>>> (I do not believe that an audio pts can be computed as frame number * 
>>> time base).
> 
> Yes, indeed as I already wrote currently -re works properly only with
> video streams where is:
> time_base = 1 /frame_rate

Ok... So, I do not see the point in enabling rate_emu for audio streams.


>>> I also have a second (bigger) doubt: in my opinion, rate_emu should not 
>>> be a field in AVCodecContext. In fact, nothing else than ffmpeg.c uses 
>>> it (unless I misread some code). So, I would be tempted to remove this 
>>> field from AVCodecContext, and to use the global rate_emu variable in 
>>> the "if()" quoted above (so, I would change "if 
>>> (ist->st->codec->rate_emu) {" in "if (rate_emu) {").
>> Yes, I tend to agree with this.
> 
> Indeed currently rate_emu is special since is a field which is *never*
> used by the library, but only by ffmpeg/other applications.
> 
> Nonetheless I think it is quite useful to keep it as an AVCodecContext
> field, see the nice property of the patch of which I already wrote,
> -[avs]rate_emu 1 will activate the frame_rate emulation mechanism only
> for the corresponding stream

Well, this is why I wanted to triple-think about the issue before
replying... But I cannot really see why activating rate emulation on
a single stream can be useful. In other words, I believe that rate
emulation is a "global property", not a "per stream property". But
maybe I did not think enough about it ;-)


> Also it doesn't appear to me such a crazy thing the idea to
> implement the rate_emu mechanism directly in the library (the decoding
> function could usleep up to when it will be time to output the decoded
> frame, as currently implemented in ffmpeg -re).

I do not know about this... Let's see Michael's opinion.


				Luca




More information about the ffmpeg-devel mailing list