Re: move descriptor headers/sources to system-dependent dirs

Michael,

On 20 January 2016 at 00:59, Michael Ira Krufky <[email protected]> wrote:
> Is it actually possible to have two
> different descriptors from different "systems" with the same ID?

Sadly, yes. While this isn't much of a concern for descriptors whose
tag is <= 0x80, it becomes a really big problem for the "User private"
range of 0x81 - 0xFF. There is absolutely no standardization in that
block, which results in different structures being mapped to the same
tag. It hasn't happened in dvbpsi yet, but it's a matter of time -
especially if we start adding network-private descriptors, which is
what the "custom" directory is for, and whose individual headers are
required to state the name of the system/standard.
Also, this change was further dictated by a previous one related to
renaming the structures : for example, previously, dvbpsi had a
dvbpsi_ac3_audio_dr_t structure in dr_81.h, which was the ATSC AC-3
descriptor. DVB, however, defines its own AC-3 descriptor with the tag
0x6A. If anybody wanted to add support for this descriptor in dvbpsi,
it would have to be named at least similarly to dvbpsi_ac3_audio_dr_t,
possibly creating confusion. Thus, the names of the types and
functions were changed to include the name of the standard/system in
order to create a clear distinction. Separating the files into
individual directories was just a further consequence of that.

> Isn't it possible to have descriptors spanning multiple "systems" in a
> single TS?

Doesn't seem likely, at least for ATSC/DVB. It's hard to make any
assumptions about the "user private" range, though.

> Do applications have to change their include paths now, too?  or was
> this change only internal?

As I said above, the change isn't limited to only the include paths :
names of the structures and functions were also changed to incorporate
the system name. There is a helper script available in the tree that
automagically changes all the affected names (misc/new_dr_api.pl). You
can also compile your application with DVBPSI_USE_DEPRECATED_DR_API,
which will enable the wrappers for the old names of the functions and
types (and give you a plethora of "deprecated" warnings). Keep in
mind, though, that any new descriptors will not support the old API
anymore, and the wrapper will possibly be removed in a future release.

Kind regards,
Daniel
_______________________________________________
libdvbpsi-devel mailing list
[email protected]
https://mailman.videolan.org/listinfo/libdvbpsi-devel