[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
>> AVFMT_NO_HEADER.
>
> 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