[FFmpeg-devel] [RFC] allow mpegts demuxer to reload streams if service disappears

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Sun, Jul 15, 2007 at 10:53:27AM +0200, Nico Sabbi wrote:
>> Michael Niedermayer wrote:
>> 
>> > also the stream removial is likely completely wrong. from what i remember
>> > these tables can be split and so if you remove all except whats in the
>> > next table you will just have a subset of all services
>> 
>> a more correct approach would be: every time the pat version changes 
>> (and not sooner) reset the program map and reparse the PAT;
>> whenever a PMT version changes reset the single program.
>> I wouldn't give too much importance to multi-section tables:
>> I've never seen one myself and accordingly to someone much more in the 
>> knows than me they were never used (they don't make any sense)

I haven't ever seen a multi-section PAT, but I wouldn't go so far as
assuming there won't ever be one.  There are a few satellite muxes
that carry the PMT for all programs as different sections on the same
PID.  Supporting this is not difficult at all if done right.

> IIRC theres a maximum size for these tables and so not supporting split
> tables means not supporting more than X streams, this doesnt sound like
> a path which we should follow, unless X is huge, but i doubt it

A section can be up to 1024 bytes, which gives room for a fair number
of programs and streams per program.

>> > also id like to emphasize that we must demux all services/streams
>> > by default demuxing just a random one/first one is not ok there
>> > is AVDiscard with which the user can indicate which
>> > streams/services he wants
>> 
>> last time I checked there wasn't the slightest notion of service or 
>> program in AVFormat; was it introduced recently?
>> It's not practical for users discarding individual pids because
>> 99% of the times they won't know which pids comprise a program
>
> its a matter of adding service_name / service_id fields to AVStream
> they are already known in the mpeg ts demuxer and just have to be exported

Yes, we should do this.  Exporting the transport_stream_id might also
make sense, although it is not essential for most uses.

I'm actually tempted to replace the quite messy TS demuxer in lavf
with a cleaner one I've written.  Who's in favour?

-- 
M?ns Rullg?rd
mans at mansr.com