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

[Stefano Sabatini]

On date Monday 2008-07-14 13:38:45 +0200, Michael Niedermayer encoded:
> On Mon, Jul 14, 2008 at 10:32:01AM +0200, Stefano Sabatini wrote:
> > Hi all,
> > 
> > currently ffmpeg -re -i ... doesn't work with only audio files, which
> > makes for example tricky to stream with RTP audio streams.
> > 
> > This is because rate_emu is currently set in opt_input() only for
> > video streams, and is ignored if there is only an audio stream to
> > transcode (for example if you're using -vn).
> > 
> > My solution is to make -rate_emu settable through AVOption options
> > using rate_emu, then remove the -re option.
> > 
> > This alone doesn't fix the problems for audio-only multimedia streams
> > streaming, there are still timestamp issues to be addressed.
> > 
> > I'm not sure this is the best solution, so I'm posting it here to
> > foster ideas and suggestions.
> 
> iam fine with the patch IF it works and has been tested with at least
> one case where -re was needed in the past.

Mmhh... can someone propose such a use case? 

As for me I want to fix it mainly to use it for streaming RTP audio
streams like:
ffmpeg -arate_emu 1 -i file.flv -vn -f rtp rtp://localhost:5004

Anyway with the patch the:
ffmpeg -vrate_emu 1 ...

behaviour should be equivalent to the previous:
ffmpeg -re ...

with the very nice property that you can use for example
-arate_emu/-vrate_emu/-srate_emu and the real-time decoding will
happen only for corresponding A/V/S output packets, while with
-rate_emu it will work (that is will usleep) for every type of output
packet.

And the code as it has ever been (since r1641) has been always broken,
it just works for video streams for which is the case:
1/frame_rate = time_base

so further patches will be needed to get it properly working for every
stream.

So is it OK to apply?

Regards.
-- 
FFmpeg = Fostering and Frenzy Meaningful Pitiless Exxagerate Generator