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

Baptiste Coudurier baptiste.coudurier
Sat Apr 17 23:32:32 CEST 2010


On 4/17/10 5:49 AM, elupus wrote:
> On Fri, 16 Apr 2010 13:41:08 -0700, Baptiste Coudurier wrote:
>
>> On 04/16/2010 01:33 PM, elupus wrote:
>>> [16 quoted lines suppressed]
>>
>> I'm sure a smaller probesize would be reasonable and would work in most
>> of the cases.
>>
>>> [6 quoted lines suppressed]
>>
>> AVFMT_NOHEADER is handled in av_find_stream_info, and this process is
>> stopped by probesize.
>> AVFMT_NOHEADER is here to inform the user that new streams can be added
>> later on.
>
>> PMT is not found during av_find_stream_info specifically, it is found
>> during the demuxing.
>> av_find_stream_info keeps reading some packets until probesize is
>> reached to detect as many streams as possible, due to AVFMT_NOHEADER.
>> If you remove AVFMT_NOHEADER, there is a great chance some streams will
>> be missed.
>
> They will only be missed if they are not in the first PMT. And imho the
> chance of multiple pmt to show up in the first 5mb (as beeing the default
> probesize) of a file compared to the rest of the file is quite small.

Or if PMT changes, or if the TS contain multiple programs. I'm telling 
you by experience that the code behave this way because we got many bug 
reports about undetected streams.

> They will however totaly be missed if we reduce probesize and pmt shows up
> later. But i'll keep it local to xbmc for now, until ffmpeg get's a new
> mpegts demuxer :)

Absolutely not, you seem to be confused. Demuxer will keep parsing PMT 
and add new encountered streams. You will notice it when the AVPacket 
stream_id is new.
That's why AVFMT_NOHEADER is set, here is the doxygen about it:
     /** Read one packet and put it in 'pkt'. pts and flags are also
        set. 'av_new_stream' can be called only if the flag
        AVFMTCTX_NOHEADER is used.

However with your patch, indeed streams will totally be missed and break
the behaviour of the demuxer.

It seems to me that you are trying hard to push hard a wrong patch 
without trying to understand the reasons behind the code.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list