[FFmpeg-devel] [PATCH] When PMT is found, we have found mpegts header information

Michael Niedermayer michaelni
Tue Apr 20 02:33:17 CEST 2010

On Mon, Apr 19, 2010 at 03:50:20PM -0700, Baptiste Coudurier wrote:
> On 04/19/2010 05:07 AM, Joakim Plate wrote:
>> Baptiste Coudurier<baptiste.coudurier<at>  gmail.com>  writes:
>>>> My patch only changes what happens during probesize, where it makes
>>>> av_find_stream_info stop after first pmt is found. It does not stop the
>>>> demuxer from adding more streams later (even as the doxy above would
>>>> suggest that is against api), so further stream will still be found.
>>> Technically by not setting AVFMT_NOHEADER it will make it stop after all
>>> streams
>>> detected in the first PMT have parameters information.
>>> Breaking API is certainly not wanted.
>>> However I think API could be extended to allow this usage. This could be
>>> done that makes av_find_stream_info ignore AVFMT_NO_HEADER.
>>> Would that work for you ?
>> Not sure if you intended to attach a patch, but yea if av_find_stream_info
>> ignored AVFMT_NO_HEADER after first PMT was found that would work just 
>> fine.
>> The point is just to avoid searching the full probesize. For low bitrate 
>> live
>> stream that can take some time.
>> I can't see a good solution to how to do above thou. One can for example 
>> not
>> just stop av_find_stream_info as soon as it has found one stream. Standard 
>> mpeg
>> demuxer has no similar mid stream header that shows up that contains the
>> complete list of streams in the file after that point (maybe it has, but 
>> it's
>> not used anyway).
>> One would have to extend the demuxer/utils.c interface with some 
>> additional
>> flag, and i'm not sure it's really worth it, given the one use case of
> It's not one use case like I explained to you, it's part of the API.
> I don't think breaking is an option unless other people are ok with it.
> Michael ?

if noone is using it we might just take the quick route and break the unused
API otherwise we might need a second flag

also google might be able to awnser if this is used by anyone


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100420/ab47aa47/attachment.pgp>

More information about the ffmpeg-devel mailing list