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