[libdvbpsi-devel] [RFC] libdvbpsi API changes

[Johann Hanne]

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.

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.

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?

Regards,
  Johann

> 
> 3/ All application projects duplicate the same lines of code, generally
> called "WritePSISection", to split a PSI section into transport stream
> packets. Since libdvbpsi's input is TS packets, it seems logical to be
> able to output TS packets. We therefore propose to add an extra API that
> would look like :
> 
> int dvbpsi_HowManyTSBuffers(dvbpsi_section_t *)
> (merely returns (size + 183) / 184)
> int dvbpsi_GenTS( uint8_t *pp_ts_buffers[], int i_nb_buffers,
> dvbpsi_section_t *, uint16_t i_pid, uint8_t *pi_cc )
> 
> This change is source-compatible with 0.1.6 because it only adds new
> functions.
> 
> 
> Conclusions :
> If you have a great idea, or a strong opposition to the ideas presented
> here, please share.
> 
> Kind hugs to everybody,
> -- 
> Christophe Massiot.
> _______________________________________________
> libdvbpsi-devel mailing list
> libdvbpsi-devel at videolan.org
> http://mailman.videolan.org/listinfo/libdvbpsi-devel