[Ffmpeg-devel] avformat/mpegts reads too much data for lowbitratestreams

Michael Niedermayer michaelni
Thu Jun 9 22:59:56 CEST 2005


Hi

On Thursday 09 June 2005 22:09, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> > Hi
> >
> > On Thursday 09 June 2005 18:14, M?ns Rullg?rd wrote:
> >> Kenneth Aafl?y <kenneth at aafloy.net> writes:
> >> > torsdag 9. juni 2005, 17:27, skrev M?ns Rullg?rd:
> >> >> Kenneth Aafl?y <kenneth at aafloy.net> writes:
> >> >> > torsdag 9. juni 2005, 15:12, skrev M?ns Rullg?rd:
> >> >> >> Kenneth Aafl?y <kenneth at aafloy.net> writes:
> >> >> >> > How do you tell the user that an AVStream is not active anymore?
> >> >> >>
> >> >> >> You stop returning packets from it.  If all the streams go away,
> >> >> >> you do whatever the method is to signal end of file, which I can't
> >> >> >> recall at the moment.
> >> >> >
> >> >> > That's a crude interface, since there is no av_read_frame(AVStream)
> >> >> > you have to depend on time to detect when to change what to decode!
> >> >>
> >> >> Huh?  If you get packets, you decode them.  If there are no packets,
> >> >> you decode nothing.
> >> >
> >> > Say you have a ts with two services, and the user is currently
> >> > decoding the first service. If this service stops it's transmission
> >> > the user (app) either want to exit (since it's the end of the
> >> > 'stream') or switch to the other service (since it's not the end of
> >> > the 'file'). With your interface it's impossible (close to) to
> >> > trigger either change, since there is no notion of 'end of
> >> > substream'.
> >>
> >> Consider it a deficiency in libavformat.  Fixing it appears to be
> >> nontrivial.
> >
> > hmm, whats non trivial from the lavf api point of view?
> > you could add a flag to AVStream or AVPacket to indicate "end of stream"
>
> Are you proposing a special end-of-stream packet?  I'm not against the
> idea as such, but it would change the semantics.

yes, though iam not saying its a good or bad idea just that it seems 
relatively trivial

-- 
Michael





More information about the ffmpeg-devel mailing list