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

Baptiste Coudurier baptiste.coudurier
Tue Apr 20 03:12:04 CEST 2010

On 04/19/2010 05:33 PM, Michael Niedermayer wrote:
> 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

All right then.
I slightly changed the patch, Joakim would that patch work for you ?

Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ts_noheader.patch
Type: text/x-diff
Size: 968 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100419/91fa506a/attachment.patch>

More information about the ffmpeg-devel mailing list