Some explanation about DVB transport stream
When we transmit using a DVB standard we modulate a carrier to transmit digital data.
Data are organized in different parts : information for the receiver to tell it where to find different multiplexed channels, where are video, audio in different languages sometimes, how they are coded, and data that can be other things that video or audio. We could use DVB just to transmit files, very more faster than packet radio....
So when a signal is demodulated, we receive data organized by packets (of 188 bytes). but packets are all mixed, data, info, teletext, audio, video....
Each packet has a number to recognize it : PID = Packet IDentification.
To be able to reorganize data to put video data together, audio data together and decode them, we must know where they are (their PID) and at which channel they belong.
So all start with the "mother" of all packets : packet with PID 0 : PAT = Program Allocation Table. This PID=0 is always for PAT. It is known before we receive anything.
In this packet PAT we will find how much programs or channels we have in the multiplexed stream. and we will know the value of PID that give us info about these channels. These are PMT Program Map Table.
If you have 2 services ( channel TV) the PAT will tell you that you have 2 PMT, first PMT at PID 258 and second PMT at PID 270.
So the decoder will search to find packets having PID 258 (first channel), and when it receives them, it find inside these packets that there are 3 elementary streams : video PID 256 audio PID 257 (in English) and audio PID 260 (in French)
So the receiver/decoder will know that if you want to look at first channel it will assemble together all packets "PID=256" that represent video data and send them to the mpeg2 video decoder, if you want the English audio it will take all packets "PID=257" that arrive in the stream and send them to the Mpeg1-layer2 audio decoder.
So to be able to show us a video and audio, any DVB receiver must know the video PID and audio PID it must decode. ( and many other things more complex to explain in only several lines)
So when you scan a frequency with a decoder, it search the PAT, when it get it, it knows how to find PMT and when it get one PMT it knows the audio PID and video PID corresponding, so if you want to watch this channel, it could take all packets for video that are arriving and all packets for audio that are arriving.
So in a DVB Transport Stream we have always a PAT, and one or several PMT.
some specific packets as SDT or NIT allow to give other info like the name of provider, name of network...
In HAMTV DVB multiplexer, there is a bug in the firmware, so there are absolutely no packets describing tables: no PAT, no PMT, no NIT, no SDT..
So any professional DVB decoder or any receiver that want to observe strict DVB standard will not accept this transport stream that is not DVB compliant. Nothing to see, nothing to hear..
But if you use a very simple SetTopBox at very low price, a basic hardware that don't take care of strict DVB characteristics, it will be able to decode if you give it, by yourself, the audio PID value(257) and the Video PID value(256).
If you use a very good SetTopBox that use table, that use PCR and PTS values inside packets to synchronize strictly audio and video, these equipment will not work for HAMTV decoding.
Using a computer and a software like Tutioune will allow us to receive the BAD transport stream coming from HAMTV and to add in real time the tables that are not present.
So the Transport Stream recorded or sent via UDP to VLC, TSreader will have all tables.
VLC gives some info about the stream :
The last thing to do is to explore if there are no other bugs ...
I'm working on that. I need more time for test. I'm writing a long document about all of that.
Sorry, my English is not very good, DVB technology is not very simple, I hope you will understand these explanations, I have tried to simplify the most I could.
Best regards
Jean Pierre COURJAUD F6DZP