Updating title.

Would still be nice to report/export the various private streams indeed.

I'm not sure MHP/MHEG should be exposed as a stream.

They are carousel data. It might make more sense to have tsdemux take care of collecting the information into a temporary directory and emit the proper messages/signals to notify of new information.

In addition, we might also want "timed" signals/messages for carousel/MHP/MHEG information (for actions that should happen synchronized with the stream).

Updating the title accordingly.

I'm currently testing a (5 liner) patch which makes mpegtsbase post sections (at virtually zero-cost) for all those private sections (DSM, MHEG, ...). Essentially it recognizes those streams as being PSI and not PES streams and accumulates/emits them on the bus.

With a bit of extra parsing code in the mpegts library, this would enable handling all those "streams" application-side (where it should be handled).

I'm going to say this bug is closed with the following fix. All the information needed for an application to handle MHP/MHEG/HBBTV/... is now posted on the bus.


commit 1c96c79b88cce303bf02fe9b2723d09c6caa938c
Author: Edward Hervey <edward@collabora.com>
Date:   Sat Jul 6 14:50:52 2013 +0200

    mpegtsdemux: Handle private section streams
    
    Until now we simply ignored those streams (since we couldn't do anything
    with it anyway). Now that we have the mpegts library and we offload the
    section handling to the application side we can properly identify and
    extract them.
    
    By default it is disabled for tsparse and enabled for tsdemux, but there is
    a property to change that.
    
    This should open the way to properly handle all private section streams,
    including:
    * DSM-CC
    * MHEG
    * Carousel data
    * Metadata streams (though I haven't seen any of those in the wild)
    * ... And all other specs/protocols making use of those
    
    Partially fixes #560631