[Dan203]

The main reason TiVo added TS was H.264. It originally appeared in the Australia/New Zealand TiVos because in NZ they broadcast almost everything in H.264. PS does not handle H.264 well, and most players/demuxers will not handle H.264 in a PS container at all. So switching to TS for H.264 made the streams more compatible with the way TiVo Desktop just decrypts the stream and then hands it off to WMP to demux/decode.

As a side benefit TS files transfer much faster because the TS format is basically what they use internally, so only a very minor conversion is required rather then a full remux and re-encryption like they do with PS. It's also easier for their code to move past glitches and errors in the source stream when converting to TS because the conversion is minor and doesn't require them to demux the original audio/video streams. So files that would fail to transfer as PS due to errors in the stream will usually work as TS.

The biggest issue people have with TS files using a tool like kmttg is that the open source tivodecode never had it's TS decryption fully implemented. So it can actually introduce errors into the decrypted file. I wrote a program years ago (which I never released) that uses the TiVo DirectShow filter to do the decryption of TiVo files and it always works perfectly when decrypting TS files. In VideoReDo we use the DirectShow filter too, but we use sort of a backdoor into it rather then building a whole graph, and that backdoor can fail when it hits a glitch in the stream. We have some code to work around it, but it's not 100% so I'm eventually going to rewrite VRDs TiVo support to work more like my other program.

 

[Dan203]

FYI, these days the kmttg windows installation includes DirectShowDump method as well, so at least for people on Windows platform with TiVoDirectShowDump.dll installed (partial TiVo Desktop installation which VRD also uses), you can decrypt TS TiVo files just fine. i.e. These days kmttg has 3 different options for decrypting TiVo files: tivodecode, DSD, and VRD, and of course the latter 2 work fine with TS TiVo files.

I'm not sure uow DSD works exactly. VRD exploits an extra interface in the TiVo DS filter which allows us to access the unencrypted data as if it were a standard file. It works OK for most files, but we've recently discovered that if the file has a glitch then that interface will stop decrypting the data until you seek past the glitch. We added code to detect when this happens and then force a sequence of small seeks until it starts decrypting again. My program builds a simple DS graph, just like the file is going to be played, but it uses a special filter I wrote that can link directly to the output pin of the TiVo filter and dump the unencrypted stream to a file. We've found in our testing that this method is not effected by glitches in the video and is actually able to decrypt even the corrupted portion of the file allowing us to repair some of the frames which we can not even access using our current method.

If DSD uses a metod similar to VRf then it may have issues with some TS files. If it uses a meod similar to my program then it will likely give you the best possible results.

 

[Dan203]

Awesome explanation Dan, thanks! I think I'll select TS for the long distance transfer to here for the time being, and see if there are any glitches, since you guys mention it transfers faster. If I get too many glitches I'll just go back to PS.

Since you have a great handle of these things, can you help with another question/issue I have?

I want to stream the MPEG-PS/TS file directly from Streambaby while its concurrently downloading the file from my philly Roamio+. The issue I'm having is that when I select the file that's downloading in my TiVo Recordings folder locally, it starts to play fine after it buffers a bit but it will only play to the point that the file size WAS when I selected it to stream/play. In other words the download isn't acting as a buffer to the Streambaby stream as I had hoped. How can it be made to do this?

I'm not sure how StreamBaby works but at one point I wrote a player app specifically for TiVo files (also never released) and one of the things I discovered with that is that the duration of the stream reported to the DirectShow graph by the TiVo filter does not get updated if the file is still downloading. So it's stuck at whatever duration was available when the file started playing. However the TiVo filter will decrypt data beyond that point, it just wont report it to the graph. You can see this happen if you play an in progress download in WMP. The duration will be reported as whatever is available when you start playing the file, and you'll only be able to seek in that portion, but if you let it play all the way to the end of the bar it will keep going until it hits the actual end of the file.

If StreamBaby is using DS to decrypt the file then it's likely getting the duration from the graph and then stopping when it reaches that point. I don't believe there is anything in the TiVo header that reports the actual duration of the file, and sunce it's downloading there is no way for it to be calculated, so the only thing I can think of that might fix it is if StreamBaby could detect that the file size was actively changing and then use a large duration, like say 24 hours, for any file it determines is still downloading. Then it would need to elegantly detect and recover when it hit the actual end of file. (could be easier said then done)

 

[Dan203]

VRD does a QSF at the same time, so you're fixing two birds with one stone using it. But it's possible DSD would be able to handle files with glitches in them with a few less dropped frames because of the way it works.