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

On Wed, Jan 20, 2016 at 4:05 AM, Daniel Kamil Kozar <[email protected]> wrote:
> 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.

Thanks for this explanation - it makes good sense to me.  I am the
author of dr_81.[ch], so I apologize for the bad function naming :-P
I didn't realize that it was an ATSC-only descriptor, nor was I aware
that there was a DVB-only AC-3 Audio Descriptor 0x6a.  It all makes
sense now.

>> 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.

There is a local broadcaster in New York City (on physical channel 30)
whose broadcast TS seems to comply with ATSC for the most part,
although I've found DVB-style EIT tables along with DVB-style
descriptors in the stream. I assume most televisions here ignore these
tables.  This stream also has a few of the MPEG descriptors but I
guess that's to be expected.  This particular TS is probably just an
edge case, but if you're interested I could send a snippet.

>> 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.

Thanks again for the explanation.

Best Regards,

Mike Krufky
_______________________________________________
libdvbpsi-devel mailing list
[email protected]
https://mailman.videolan.org/listinfo/libdvbpsi-devel