[FFmpeg-devel] [PATCH] Fix ffmpeg -re behaviour

[Stefano Sabatini]

On date Thursday 2008-07-17 08:40:37 +0200, Luca Abeni encoded:
> 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 ;-)

Rethinking at it I came to the same conclusion, that is, rate_emu
should be considered a global property.

> > 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.

Attached patch implements the solution suggested by Luca, that is to
use rate_emu as a global option and use ist->next_pts rather than
making the wrong assumption currently implemented.

Regards.
-- 
FFmpeg = Freak and Faboulous MultiPurpose Excellent Generator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-rate-emu-00.patch
Type: text/x-diff
Size: 1376 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081121/597d0b3c/attachment.patch>