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

Stefano Sabatini stefano.sabatini-lala
Wed Jul 16 16:53:12 CEST 2008


On date Tuesday 2008-07-15 21:27:22 +0200, Stefano Sabatini encoded:
> 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?

I'll apply it on Friday if no one has objections.

Regards.
-- 
FFmpeg = Furious Fast Magic Purposeless Extended God




More information about the ffmpeg-devel mailing list