Transportstream over HTTP - SI-data handling not correct

[Micha_R]

Hi,

while making a small HTTP-streaming server for a DVB-compliant satellite receiver (STB), I found 2 problems in VLC related to the SI-data handling. But first...

VLC version 0.8.5
OS: Windows XP / SP2

From the beginning... The streaming server on the STB provides a striped down Transportstream, a remultiplexed version which only contains all the streams from the current selected service. To make sure, VLC only see this one service, the server generates a new PAT at PID 0x0000, which has only the pointer to the PMT-PID of that service. The PMT is a copy of the original one received via satellite.

Problem 1: If the user changes to a different service on the STB, but on the same transponder, VLC ignores the new PAT, if the stransportstream_id and the version_number is identical to the id's from the previous PAT. VLC also ignares the new PAT, if the version_number is different to the previous one, as long as the continious_counter in the transportstream-header is the same. That's not nice, because in real life on a satellite, it can happen, that both the version_number in the PAT and the first continuous_counter values are identical to the old PAT.

Problem 2: VLC is able to process the EPG-data on PID 0x0012. If my server includes this data into the transportstream, I get the name of the current event in the lower status line of VLC and in the "Now Playing" entry in the "Stream and Media Info" window. But in this case, VLC lists all services for which EPG-data is present, in the Navigation menu by program numbers. This is not, what is defined in ISO 13818 part 1 (MPEG-2 system) and ETSI EN 300 468 (DVB SI). The PAT is the main table, which tells the STB/PC-application, which services are present in the transportstream. The EPG-SI data should not be used to determine available services. Additionally, if the EPG-SI data is present, VLC begins to ignore the PAT, even if the version-number and the continious_counter changes. The same happens, if the server provides the SDT on PID 0x0011. Also the SDT is not defined to be uses to detect the available services in the transportstream.

best regards
Micha

[Micha_R]

Hi again,

to show you more detailed, what I mean...

Here is a screenshoot, if the server provides the full EIT on PID 0x0012 (EPG-data). The PAT only lists the current service - in this case "VH1 Classic" on the Astra satellite at 19.2° east:



As you can see, VLC lists all services, for which (even empty) data exists in the EIT, but as defined by ISO/ETSI, VLC should only list the service with program_number 0x6FF1 (28657), because only this is present in the PAT.

Another screenshoot. In this case additionally the SDT is present in the transportstream:



Now VLC also lists the service-names. Of course, this is one of the functions of the SDT, but also in this case, VLC should only list the service(s), which are present in the PAT. Btw. The selected service in the Navigation list is wrong. The shown stream is still from "VH1 Classic"

For boot cases VLC ignores a new PAT. Even if the transportstream_id in the PAT change, which invalidates the data from the last SDT/EIT, VLC hangs on the old stream, which of course is not present any more.

best regards
Micha

[The DJ]

Trac'ed in https://trac.videolan.org/vlc/ticket/684 and https://trac.videolan.org/vlc/ticket/683

[Sigmund]

I posted some comments and a possible workaround to 683. I do however not have any possibility to test it, so I didn't commit it yet. I did also investigate 684 a bit as well, and I don't belive what you say there is true. To work more on that I will need a snippet of data that makes vlc reproduce that issue.

[Micha_R]

Hi,

sorry for late reply

about your #683 note: Even if only the "service_description_table_actual_transportstream" is monitored, it's not granted, that this SDT only list the services, which are really available in the TS. The reference for all services is the PAT at PID 0x0000, defined in ISO 13818 part 1. In the real life, especially in cable networks, it's normal, that the SDT and EIT covers data for more services than present (partial transportstreams). This happens i.e., if the TS on the cable-channel is a remux of a satellite transponder, where some services are removed in the cable-mux due to bandwidth limitations or licensing problems. In such cases the remultiplexer copies the whole original SDT/EIT from the source to the target, but generates a new PAT, which fits to the services really available in the target TS.

about the #684: Just tell me, what data you need for testing (which PIDs should be included and so on), so I can prepare a teststream for you.

Micha

[Sigmund]

Just pat should be enough for a little test, but would be better to have the complete transport stream over such a change situation.