Re: [RFC] libdvbpsi API changes

On Tue, Dec 29, 2009, Johann Hanne wrote:
> Do you plan to fix the PMT issue regarding the PMTs of multiple programs
> being sent within one PID? The standard does not forbid it, it can be
> found in real-world streams, but libdvbpsi doesn't support it.

Yes it is intended.

> Another shortcoming of libdvbpsi is that subtables with
> current_next_indicator == 0 can't be received. This could be easily
> solved by adding current_next_indicator as a parameter to the demux
> functions just the same way as table_id and table_id_extension.

Or no parameters at all, and send all the sections disregarding the
current_next_indicator flag. Higher levels inline functions can be
provided to do some filtering instead.

> I strongly oppose the idea of adding some kind of transport stream
> generator or any part thereof. The current way of feeding complete
> transport stream packets is already a programming layering violation!
> For libdvbpsi it should be enough to receive the transport stream
> PAYLOAD (pointer to the data buffer + length) plus the unit_start field.
> Every DVB application must implement a TS parser anyway, so way
> duplicate this functionality?

What I observe is that we are missing code to split a section into
184-byte packets. I see a lot of applications where this functionality
is duplicated identically, so I'd like to factorize this code.

As to whether we should work on whole TS packets or just the 184 bytes
of the payload, I don't really care, but I don't see a situation where
it would be bothering to work on the whole TS. After that's just 4 bytes
that you can easily overwrite if needed.

-- 
Christophe Massiot.
_______________________________________________
libdvbpsi-devel mailing list
[email protected]
http://mailman.videolan.org/listinfo/libdvbpsi-devel