Archiving

[raydon]

I am not totally convinced that the Humax saves the SD stream "as is", though I would be very happy to be proved wrong.

Your response prompted me to dig a bit deeper and I now believe you are correct in your assumption that the Humax does add the 4 byte time-codes to the broadcast stream before writing packets to disk.
To prove it one way or the other, I used the DVB-T tuner card in my desktop PC to capture raw data from one of the MUX's and this raw data is indeed in 188 byte packet format, so I stand corrected.
Here's a quote from a document I later found on the net which may help to explain these time-code bytes.

Timecode
Transport Stream had been originally designed for broadcast. Later it was adapted for usage with digital video cameras, recorders and players by adding a 4-byte timecode (TC) to standard 188-byte packets, which resulted in a 192-byte packet.[14][15] This is what is informally called M2TS stream. Blu-ray Disc Association calls it "BDAV MPEG-2 transport stream".[14] JVC called it TOD (possibly an abbreviation for "Transport stream on disc") when used in HDD-based camcorders like GZ-HD7.[16][17] M2TS transport stream is also used for recording HDV video (onto tape and onto file-based media), and for AVCHD video files, which often have MTS extension.[18] The timecode allows quick access to any part of the stream either from a media player, or from a non-linear video editing system.

 

[Black Hole]

Hmm. I too stand corrected. I had accepted the existing common wisdom that the data was just grabbed - why would it do anything else?!

 

[raydon]

Hmm. I too stand corrected. I had accepted the existing common wisdom that the data was just grabbed - why would it do anything else?!

This maybe ?
Last line of the quote in my previous post: "The timecode allows quick access to any part of the stream either from a media player, or from a non-linear video editing system"
Only Humax can provide the definitive answer.

 

[Black Hole]

That's not what I meant. I saw no reason to question the wisdom that the recording was just the broadcast stream unaltered - hence the exclamation mark at the end.

This is a case of me not following my own principles and dotting every last i before accepting something as absolute fact. Sometimes one has to, to make progress, but you see why my principles are as they are!

 

[johnb]

I'm no expert. I am trying to make sense of the Transport Stream for my own amusement. (Actually, trying to make sense of Raydon's documentation of nts files - in an attempt to create an nts from an existing ts without remuxing or using AV2HDR-T2 - as I said, my own amusement!)

I converted many of my non-Humax recordings, both mpg and ts, (made over the years using various USB stick tuners) to Humax compatible files by using VideoReDo. I open the files in VideoReDo then save them as .m2ts files, (MPEG2 M2TS (*.m2ts) on the Save As menu, then rename the .m2ts to .ts. I'm not sure whether any remuxing is involved but the process is very quick and the VideoReDo displays that it is doing "Fast Frame Copying". Raydon's sidecar package can then use these files to create the sidecar files and they play fine on the Humax.

[Edited] I've deleted part of my original post because it was superseded by posts made while I was typing.

 

[raydon]

I'm not sure whether any remuxing is involved

There isn't. It's just adding the time codes to every packet, which otherwise remain unaltered.

 

[raydon]

That's not what I meant.....

Sorry, didn't have my mind reader hat on.

 

[prpr]

Do you have a reference for this timecode field, or can you post what you know about it please? I've never managed to find a spec. anywhere.

 

[prpr]

I saw no reason to question the wisdom that the recording was just the broadcast stream unaltered

Depends what you mean by unaltered really. The .ts files on disk do not contain certain PIDs that get transmitted. The data within the PIDs that are stored to disk is unaltered though (aside from the on disk encryption of course).

 

[raydon]

Do you have a reference for this timecode field, or can you post what you know about it please? I've never managed to find a spec. anywhere.

The only references I've been able to find about the time-codes are this:

The difference is that each ISO-TS packet is preceded by a 32-bit timestamp value, signalling when the packet is to be delivered to the demuxer.
First 2 bits are copy-control bits (see aacs spec).
Next 30 bits are timestamp (ATC, arrival time counter, 27 MHz)
The purpose of the timestamp is to avoid having to add padding packets.

and some information to be gleaned HERE. The link is to the sources for the m2ts2ts utility, which converts 192 byte packet streams to standard 188 byte packets. If you examine the code you will see that not only does it remove the time-codes, but also re-orders the packets based on these arrival time-codes. This utility could probably be compiled to run on the T2 if deemed to be useful.

 

[EEPhil]

Having looked at the output from the Humax & Hauppauge I was beginning to conclude the Humax was adding something - and NOT error correction. Packets from both devices look the same if examined in "MPEG-2 TS packet analyser" - which they should.
As far as I can see so far, the 4 bytes are added before the sync-code. (I say this because the Humax ts files I've looked at start with 4 bytes then 0x47).
Those 4 bytes when considered as big endians do increase as you progress through the file. What that proves, I don't know.

Depends what you mean by unaltered really. The .ts files on disk do not contain certain PIDs that get transmitted. The data within the PIDs that are stored to disk is unaltered though.

If it didn't wouldn't you be recording the whole multiplex when you just wanted BBC1?

I converted many of my non-Humax recordings....

So have I. You missed the point that I mentioned - "for my amusement". I use similar tools. I'm looking at the Transport Stream and nts files to learn more about them - not to replace any of the existing tools.

 

[raydon]

As far as I can see so far, the 4 bytes are added before the sync-code.

That is correct, and is as expected for an M2TS (BDAV) format container.

Those 4 bytes when considered as big endians do increase as you progress through the file. What that proves, I don't know.

Since these are arrival timestamps of when the Humax received the packet it just proves that you can't go back in time.

 

[raydon]

This utility could probably be compiled to run on the T2 if deemed to be useful.

OK, I went ahead and built it ( and some other stuff too). TSTools v1.12 for the T2 now available for download from HERE. Built from sources available from HERE.
If af123 is agreeable then an installable package could well be provided in future. I will leave the decision on suitability entirely up to him.
This suite of tools includes the m2ts2ts utility that I mentioned earlier which can convert a native 192 byte packet T2 recording to a 188 byte format file. I made some minor changes to the m2ts2ts sources so that the -quiet switch now stops all except error messages being output. The original was quite verbose, even with the -quiet switch, and was causing processing to take ages.
There are a whole lot of other utilities in there which may, or may not, prove to be useful to the more techno-savvy types. In the main they are all for 188 byte packet format unencrypted transport streams. I cannot and will not provide any warranty, or support, for these tools, so be warned !

 

[Black Hole]

Sounds like a useful thing to add alongside MPG conversion as a pre-formatting tool, it may well make the files from the Humax compatible with video utilities which currently baulk.

 

[prpr]

TSTools v1.12 for the T2 now available for download from HERE.

Behind a "registration" wall and who knows what junk is going to come our way if we give in to their demands?
Yuk. I hate these things on principle, but thanks for compiling it anyway.

 

[Trev]

Behind a "registration" wall...

You don't have to register. I just downloaded it without registering.

 

[raydon]

Behind a "registration" wall and who knows what junk is going to come our way if we give in to their demands?
Yuk. I hate these things on principle, but thanks for compiling it anyway.

I don't like them either which is why I hosted the file on ezfile.ch. Take another look at the page, not just a cursory glance. It says sign in to download faster. Just check the "I'm not a robot" checkbox, complete the captcha if it presents one, and you will get the link.

 

[prpr]

This is what I see:


"Required" doesn't imply optional to me. I have downloaded stuff from ezfile before by ticking some box, but it isn't there now.

 

[raydon]

You need to temporarily turn off Adblock Plus for ezfile.ch

 

[EEPhil]

Since these are arrival timestamps of when the Humax received the packet it just proves that you can't go back in time.

But, isn't that the sole purpose of a PVR - to go back in time - otherwise you'd be watching it live?