Starting work on Techno Trend Premium support (2 Viewers)

[draktheas]

I wish it was just for EIT and NIT data, but it essentially will be the whole transport stream. Unfortunately, the only way for me to pull data from the API is from the TTPremium native DLL, through interop to my .NET wrapper, back out to my Directshow native DLL, and eventually into the Media Portal filters. So you can see my concern as this path will be followed by all data, including EIT, NIT, Video stream, and Audio stream.

Drak

 

[CodeMonkey]

I wish it was just for EIT and NIT data, but it essentially will be the whole transport stream. Unfortunately, the only way for me to pull data from the API is from the TTPremium native DLL, through interop to my .NET wrapper, back out to my Directshow native DLL, and eventually into the Media Portal filters. So you can see my concern as this path will be followed by all data, including EIT, NIT, Video stream, and Audio stream.

Drak

Hmmm. Sounds like it would be a good idea to jump into irc and see if frodo or agree or someone has any ideas. Would it be possible to use unmanaged c++ for that piece to avoid interop?

 

[draktheas]

I can skip marshalling and .NET land all together if I can figure out a way for Directshow and MFC/ATL to play nice together. I might keep trying along that path. I spent about 4 hours the other day trying to make it work, but everything I did to correct one problem just seemed to create more problems. Fix one compiler error and 18 more crop up, mostly because they are include and linker changes.

Drak

 

[draktheas]

Well, I guess it was just too late and I wasn't thinking to the best of my ability when I tried to get Directshow and MFC/ATL to compile and link together before. I went back and approached the problem from a different angle and was able to get it all compiling and linking. So I don't have to route through managed code anymore. Wheeeeheeeeewww!

I think I can start making some really good progress on this now. The end result will be a Directshow source filter for TTPremium that will support up to four output pins with configurable (through COM interface) PID output on each one. This may be something that is not only useful for Media Portal, but anyone who needs to access multiple PID's and streaming data from the TTPremium cards.

Drak

 

[CodeMonkey]

Well, I guess it was just too late and I wasn't thinking to the best of my ability when I tried to get Directshow and MFC/ATL to compile and link together before. I went back and approached the problem from a different angle and was able to get it all compiling and linking. So I don't have to route through managed code anymore. Wheeeeheeeeewww!

I think I can start making some really good progress on this now. The end result will be a Directshow source filter for TTPremium that will support up to four output pins with configurable (through COM interface) PID output on each one. This may be something that is not only useful for Media Portal, but anyone who needs to access multiple PID's and streaming data from the TTPremium cards.

Drak

Great news!

 

[draktheas]

Ok, yet another complication with the TTPremium SDK. They only allow access to data streaming for individual PID's. One PID per raw data filter. Unfortunately, these aren't going to be in Transport Stream format. So now I need to either write a MPEG-2 Transport Stream multiplexer myself, find an open source multiplexer that I can integrate with my source filter, or I will need to write my own Stream Anaylizer and hook it into Media Portal that will handle the raw PID packets. No wonder no one has written support for this card yet. It really is becoming a pain in the a** to work around the shortcomings of the SDK.

Does anyone know of any open source MPEG-2 multiplexers? Any advise? I am willing to do what I have to to get it to work, but man this is becoming a monster project.

Drak

 

[draktheas]

Now that I think about it. I do not want to re-mux the data because it is just going to be de-muxed again anyway. I guess the only choice is to write my own stream anylizer and section filter. Frustration is starting to set in.

Drak

 

[JMS]

Ok, yet another complication with the TTPremium SDK. They only allow access to data streaming for individual PID's. One PID per raw data filter. Unfortunately, these aren't going to be in Transport Stream format. So now I need to either write a MPEG-2 Transport Stream multiplexer myself, find an open source multiplexer that I can integrate with my source filter, or I will need to write my own Stream Anaylizer and hook it into Media Portal that will handle the raw PID packets. No wonder no one has written support for this card yet. It really is becoming a pain in the a** to work around the shortcomings of the SDK.

Does anyone know of any open source MPEG-2 multiplexers? Any advise? I am willing to do what I have to to get it to work, but man this is becoming a monster project.

Drak

At least DVB.NET 2.6 includes a simple TS multiplexing unit which will generate a TS from a video, one or more MP2 audios, one or more AC3 audios and one or more TTX streams. It will simulate some SI tables as well (very similiar to the way ProjectX does it - thanks to dvb.matt). Although currently there are some bugs which show up in some situations (packet synchronisation fails if a stream has no PTS [some TTX streams on german PayTV channels] or a stream contains no payload [again some german PayTV channels switching off the stream on alternate language MP2 PIDs]). For most cases the generator works with all TS players (esp. VLC and TSPlayer from the DVBViewer) but some channels keep causing problems [which may cause to loose audio in VLC because packets are not properly ordered]). For using the generator as a PID to TS collector this may be no problem. Well - decide yourself...

Jochen

 

[JMS]

Now that I think about it. I do not want to re-mux the data because it is just going to be de-muxed again anyway. I guess the only choice is to write my own stream anylizer and section filter. Frustration is starting to set in.

Drak

Again DVB.NET 2.6 includes some stuff for SI table analysis - not PES audio/video/TTX which is not really needed for what I do. The core is used for EPG merely and currently being improved but not yet included in the 2.7 (very early) Beta available for download from the official DVB.NET forum.

Jochen

 

[draktheas]

Thanks JMS. I think I am going to try not to re-mux if I can avoid it. After all, one of the first optimizations to make after it is working would be to take the re-mux/demux combo out of the graph. Why bother re-muxing if I am just going to take that data an demux it anyway. Does that make sense?

On another note, I will definitely look at DVB.NET again, because I am curious how muxing to a TS works, whether I actually use it or not.

Drak