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

Måns Rullgård mru
Thu Jun 9 17:50:24 CEST 2005


Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Thursday 09 June 2005 15:03, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> > Hi
>> >
>> > On Thursday 09 June 2005 14:09, M?ns Rullg?rd wrote:
>> > [...]
>> >
>> >> > AVFormatParameters, it depends upon where the variable is needed,
>> >> > and yes iam not happy with how parameters are passed into the
>> >> > demuxers at all
>> >>
>> >> I don't quite like the idea of a struct containing a field for every
>> >> possible parameter to all the demuxers.  Some way of passing arbitrary
>> >> name/value pairs would be much nicer.
>> >
>> > well, do you have any technical arguments for that? iam strongly against
>> > changes based upon "much nicer / I don't quite like the idea"
>>
>> You said yourself you are "not happy" with the current scheme.
>
> yes but that doesnt mean iam happier with every other scheme ...
> IMHO the AVFormatContext should not be allocated in
> av_open_input_stream() but instead before it by the user, that would
> simplify things

That would only move the junk to AVFormatContext instead.

>> Imagine if each (de)muxer had a few parameters.  The
>> AVFormatParameters struct would soon become quite unwieldy, and
>> changes to a single demuxer could have global effects, possibly
>> needlessly breaking binary compatibility.
>
> no, either never change the struct but just add at the end or have some 
> parameter descriptor with (name,min,max,offset,type) for the stuff in the 
> struct

It's the idea of having a single struct with contain mostly things
specific to each (de)muxer I don't like.  Something like the (unused?)
AVOption system could be better.  For instance, applications could
easily present a nice user interface with all available selections,
without the need to update things whenever the library changes.

-- 
M?ns Rullg?rd
mru at inprovide.com





More information about the ffmpeg-devel mailing list