[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