TV recording generates 1 pair ts (~96Mo) and idx (34Ko) files / mn

[jmw67]

Hi,

My Box (LaBox Numericable, France) allows me to record HDTV on a hard disk (500Go).
I would like to extract my recordings from this dik and convert them to divx. One hour of recording on the disk takes a huge space (~3Go).

I tried to analyze the data that the system is storing on the disk. I describe below what I could understand.
Could some one help me or guide me to where I could find information to join the audio and video stream.

Thanks for your help.

================================================== =======================
Here is what I have.

The disk is a standard ext3 file system.

Every recording is stored in a folder named '0000', '0001', '00002', '0003', ....
(see pictures begin_0004_files.PNG and end_0004_files.PNG)
An sqlite database (record.sq3) keeps track of movie title, channel name, recording ('000?')

But where I have difficulties is to understand how the video and audio stream are organized.

In a recording folder, approximately for every minute of recording, the system stores one "ts file" and one "idx file".

These files have standard extension which do not correspond to the usual file type. idx is not a sub title file.

I think the idx file is rather the index file that keeps track of the start and lenght (or end) of audio and video data stored in "frames" in the "ts file"( the transport stream).

Here is the begin of the idx file as hexadecimal data:

0000000: 0200 0000 1c00 0000 0000 0000 0400 0000 ................
0000010: 7267 616e 0200 0000 0000 0000 2513 9100 rgan........%...
0000020: 0000 0000 1437 0000 3613 9100 0000 0000 .....7..6.......
0000030: bcbc 0000 4e13 9100 0000 0000 ec40 0100 ....N........@..
0000040: 5e13 9100 0000 0000 d8c5 0100 7913 9100 ^...........y...
0000050: 0000 0000 3c4c 0200 9113 9100 0000 0000 ....<L..........
0000060: e4d1 0200 a513 9100 0000 0000 8c57 0300 .............W..
0000070: be13 9100 0000 0000 78dc 0300 da13 9100 ........x.......
0000080: 0000 0000 6461 0400 f113 9100 0000 0000 ....da..........
0000090: 50e6 0400 0d14 9100 0000 0000 3c6b 0500 P...........<k..
00000a0: 2114 9100 0000 0000 a0f1 0500 3914 9100 !...........9...
00000b0: 0000 0000 d075 0600 5e14 9100 0000 0000 .....u..^.......
.....

The first 32 bytes are conserved in all idx file.
0200 0000 1c00 0000 0000 0000 0400 0000 7267 616e 0200 0000 0000 0000

After that a pattern appears
2 times 0000 (4 00 bytes) and 8 bytes and again this motif
0000 0000 1437 0000 3613 9100 .....

Note also that in this 8 bytes the motif 9100 is recurrent. This is the case in the other files too but the number is different
I attached screen capture of two files (see begin_first_2_idx_files.PNG)

See the 0004000_ts_first-lines.PNG for the first bytes of TS file.

================================================== ==

The organisation of the sqlite DB :

1) table : rectable

[(0, 'record_id', 'INTEGER', 0, None, 1), (1, 'rectype', 'int', 0, None, 0), (2, 'rec_id', 'varchar', 0, None, 0), (3, 'start_time', 'int', 0, None, 0), (4, 'duration', 'int', 0, None, 0), (5, 'size', 'bigint', 0, None, 0), (6, 'rec_state', 'int', 0, None, 0)]
le contenu de cette table
[(3, 0, '0002', 1381065901, 6899, -840952832, 1), (4, 6, '0000', 0, 0, 0, 1), (6, 0, '0004', 1381103100, 6299, -35975680, 1)]

2) table :extradata

[(0, 'record', 'int', 0, None, 0), (1, 'serial_number', 'bigint', 0, '0', 0), (2, 'nuid', 'bigint', 0, '0', 0), (3, 'protected', 'int', 0, '0', 0), (4, 'avplayer_id', 'int', 0, '-1', 0), (5, 'bouquet_name', 'varchar', 0, '""', 0), (6, 'channel_name', 'varchar', 0, '""', 0), (7, 'channel', 'int', 0, '0', 0), (8, 'metadata', 'varchar', 0, '""', 0)]

this table contains :

[(3, 1760202946, 2871168411, 0, -1, 'NCCHANNEL', 'FRANCE 4 HD', 14, "1|TRUE|89961342|LE JOUR DE L'APOCALYPSE|false"), (4, 0, 0, 0, -1, '', '', 0, ''),
(6, 1760202946, 2871168411, 0, -1, 'NCCHANNEL', 'PARIS PREMIERE HD', 5, '4|TRUE|89763825|Zemmour et Naulleau|false')]

[nic2k4]

This is quite the description, have you tried the obvious first; use a TS conversion program? I haven't used it myself, but HDTVtoMPEG seems to be what you're looking for and there's a guide too.

[jmw67]

Hi,

thanks for your fast reply. Yes I did already some tests with different MPEG-TS programs : HDTVtoMPEG, ProjectX, mpeg2repair, tsMuxeR.
These ts files do not contain PIDs so no program is able to deal with them.
In order to get access to the video and audio stream the idx and ts files need to be combined. All these programs use only the TS file. By counting the blocks of '0000 0000 xxxx xxxx xxxx xxx' I obtained something close to 3000 which is 2 times 60s x 25 frames/s=1500. I was wondering if there is any standard were the indexing is separate from the stream (audio and video), no PID in the TS file. I was also looking for a sync byte but did not succeed in finding one. I think with the idx file this is not really required, as one can move rapidle from one place to another in the TS file.
What are the other technologies that can Transport a Stream (TS but non MPEG-TS) that has the index file and the data separate?
I hope that some body will be able to help.
Any way thanks for the reply.

[nic2k4]

I don't know what else you have tried before coming here, but here's another suggestion, use Mediainfo to see what kind of video and audio you're dealing with. At least if it can see that much there's some hope of getting something done with the TS files without having to reverse engineer the recording format.

You may be able to get something out of your files using FFMPEG, there's some talk about doing that here. If it works on one file, then you should be able to concatenate all the files into one large one and process it. At that point you might want to start a new thread specifically for FFMPEG.


Here are some other tools you might already have tried. TSReader is able to analyse streams and find PIDs. Here's another TS analyser, it's shareware but you get to try it for 30 days. It appears that videoredo has facilities to deal with something close to your problem.


If trying to deal only with the A/V approach won't work, you're probably going to need help from a programmer type; here's some technical info.

[jmw67]

Hi,

I tried already mediainfo but no success it gives only file name and file size. I had also a lokk at FFMPEG but I will check your link.
As I said already in my previous mail, this TS file has no PIDs so really the "segments" of data in the TS files are described by the idx file.
I know this because I tried also TSreader and all the above TS programs.
So I am really looking to some "Transport Stream" technology which utilises data (audio/video) and indexing in 2 separate files. May be the TS data is not mpeg-TS what else can it be. I will have a look at the technical data and the other links. I have some computing skills some I tried already to decipher the idx file (See at the end) .

Best regards

================================================== ==================================
Detailled description

Idx file extract. I skipped the the 32 bytes and read then 1 integer (4 bytes the '0000 0000') and 4 short (4 times 2 bytes)
You notice that :
1) I am in sync with the zero start (i1 is always 0)
2) that s11 varies but s12 is always incremented by 256
3) that s21 varies and s22 is always 37632
The same is observed for all idx files except that the constant 37632 varies is different but close (9100 or 9200 or 9300 expressed in hexadecimal). See the previous mails for attached documents showing hexadecimal screen captures.

One can also notice that considering s12 the lines go by paires 0, 256, 512, ...
But at line at line 496 the number exceeds the size of a short. So I think that this 4 shorts should be combined as 2 integers and taken by two lines to describe one segment in the TS file for audio and video (which order?) for the start position and length (or end) of data.
I am looking at this right now.


Below is what I obtain :
1 i0: 0 s11: 0 s12:0 s21: 63790 s22:37376
2 i0: 0 s11: 1068 s12:0 s21: 815 s22:37376
3 i0: 0 s11: 61616 s12:0 s21: 7215 s22:37376
4 i0: 0 s11: 56373 s12:256 s21: 13103 s22:37376
5 i0: 0 s11: 33979 s12:256 s21: 18991 s22:37376
6 i0: 0 s11: 46143 s12:512 s21: 25135 s22:37376
7 i0: 0 s11: 23749 s12:512 s21: 31535 s22:37376
8 i0: 0 s11: 18506 s12:768 s21: 37423 s22:37376
9 i0: 0 s11: 13519 s12:768 s21: 44079 s22:37376
10 i0: 0 s11: 8276 s12:1024 s21: 49711 s22:37376
11 i0: 0 s11: 3289 s12:1024 s21: 56111 s22:37376
12 i0: 0 s11: 63581 s12:1280 s21: 61999 s22:37376
13 i0: 0 s11: 58594 s12:1280 s21: 2096 s22:37376

...
495 i0: 0 s11: 24735 s12:65280 s21: 20831 s22:37376
496 i0: 0 s11: 60563 s12:1 s21: 26207 s22:37376
497 i0: 0 s11: 55320 s12:257 s21: 33375 s22:37376
498 i0: 0 s11: 2205 s12:257 s21: 41567 s22:37376
499 i0: 0 s11: 45090 s12:513 s21: 46687 s22:37376
500 i0: 0 s11: 40103 s12:513 s21: 53087 s22:37376
501 i0: 0 s11: 52267 s12:769 s21: 58975 s22:37376
502 i0: 0 s11: 12466 s12:769 s21: 65119 s22:37376
503 i0: 0 s11: 7223 s12:1025 s21: 4704 s22:37376
...
A total of 2882 block
14 i0: 0 s11: 18537 s12:1536 s21: 11312 s22:37376

[nic2k4]

So I am really looking to some "Transport Stream" technology which utilises data (audio/video) and indexing in 2 separate files.

I gathered as much and like I said, if mediainfo can't figure out the files, then there's not much chance you'll get a tool that can do a conversion. What you need now is too figure out how the SQL, IDX and TS data relates to each other in relation to the original stream format that is in use in France. This is where the information from that ieee presentation comes in. What you need to do is remux the data from those 3 sources into a standard stream. The difficulty is that all this work may pertain to that specific PVR and any kind of "third party" support to extend the device's functionnality will depend on its popularity. Have you searched for forums dedicated to that PVR?

[jmw67]

Hi,

I tried to find something from my providers web site and otheer forums but no data is really available. So my aim is to discover the audio/video transport format so that with the idx file I can fuse the data and hope to be able to generate something close to MPEG or MPEG-TS that I can convert then to divx with available tools.
I could already analyse the idx file further.
You can see what I get below.
best regards.

================================================== ========


Ignoring the first 32 bytes and displaying hte next 8 as blocks I observe that the byte should be read as "little endean" (the byte 1, byt2 byte3 byte4 should by read as byte4, byte3, byte2, byte1).
This work well for the first four bytes. Below you have the lines diisplayes as bytes (grouped by 2 with <>) and the same lines read with integer as little endean format .

With the bytes one can see how fast the values grow. This is obvious in the first 4 bytes, they are related these number seem to be indexes. For the next bytes it is less obvious. One column is almost constant 146/147. And the two previous byte grow with the second byte faster that the first one (for the 1rst line 46, 249 respectively). For the moment I do not understand the meaning of these numbers (last four bytes)
The size of the TS file ~96283Ko the last Integer index is 98548084 so compared to 96283Ko*1024=98593792 the delat is 45708 in the range of the delta amounts obtained between two successive index. (~35000)
Bytes :
1 i0: 0 < 0 0> < 0 0> < 249 46> < 146 0>
2 i0: 0 < 4 44> < 0 0> < 3 47> < 146 0>
3 i0: 0 < 240 176> < 0 0> < 28 47> < 146 0>
4 i0: 0 < 220 53> < 1 0> < 51 47> < 146 0>
5 i0: 0 < 132 187> < 1 0> < 74 47> < 146 0>
6 i0: 0 < 180 63> < 2 0> < 98 47> < 146 0>
7 i0: 0 < 92 197> < 2 0> < 123 47> < 146 0>
8 i0: 0 < 72 74> < 3 0> < 146 47> < 146 0>
9 i0: 0 < 52 207> < 3 0> < 172 47> < 146 0>
10 i0: 0 < 32 84> < 4 0> < 194 47> < 146 0>
11 i0: 0 < 12 217> < 4 0> < 219 47> < 146 0>
12 i0: 0 < 248 93> < 5 0> < 242 47> < 146 0>
.....
2120 i0: 0 < 152 109> < 80 4> < 76 255> < 146 0>
2121 i0: 0 < 12 241> < 80 4> < 101 255> < 146 0>
2122 i0: 0 < 112 119> < 81 4> < 125 255> < 146 0>
2123 i0: 0 < 24 253> < 81 4> < 148 255> < 146 0>
2124 i0: 0 < 4 130> < 82 4> < 172 255> < 146 0>
2125 i0: 0 < 172 7> < 83 4> < 196 255> < 146 0>
2126 i0: 0 < 152 140> < 83 4> < 220 255> < 146 0>
2127 i0: 0 < 132 17> < 84 4> < 244 255> < 146 0>
2128 i0: 0 < 44 151> < 84 4> < 36 0> < 147 0>
2129 i0: 0 < 212 28> < 85 4> < 60 0> < 147 0>
2130 i0: 0 < 192 161> < 85 4> < 84 0> < 147 0>
2131 i0: 0 < 240 37> < 86 4> < 108 0> < 147 0>
2132 i0: 0 < 152 171> < 86 4> < 132 0> < 147 0>
2133 i0: 0 < 132 48> < 87 4> < 156 0> < 147 0>
2134 i0: 0 < 112 181> < 87 4> < 180 0> < 147 0>
....
2871 i0: 0 < 232 254> < 217 5> < 151 73> < 147 0>
2872 i0: 0 < 144 132> < 218 5> < 175 73> < 147 0>
2873 i0: 0 < 124 9> < 219 5> < 199 73> < 147 0>
2874 i0: 0 < 36 143> < 219 5> < 223 73> < 147 0>
2875 i0: 0 < 16 20> < 220 5> < 247 73> < 147 0>
2876 i0: 0 < 252 152> < 220 5> < 15 74> < 147 0>
2877 i0: 0 < 164 30> < 221 5> < 39 74> < 147 0>
2878 i0: 0 < 144 163> < 221 5> < 63 74> < 147 0>
2879 i0: 0 < 244 41> < 222 5> < 87 74> < 147 0>
2880 i0: 0 < 36 174> < 222 5> < 112 74> < 147 0>
2881 i0: 0 < 16 51> < 223 5> < 136 74> < 147 0>
2882 i0: 0 < 116 185> < 223 5> < 161 74> < 147 0>
2882 blocks

Integers Little endean ================================================== ===
1 i0: 0 < 0> < 9580281>
2 i0: 0 < 11268> < 9580291>
3 i0: 0 < 45296> < 9580316>
4 i0: 0 < 79324> < 9580339>
5 i0: 0 < 113540> < 9580362>
6 i0: 0 < 147380> < 9580386>
7 i0: 0 < 181596> < 9580411>
8 i0: 0 < 215624> < 9580434>
9 i0: 0 < 249652> < 9580460>
10 i0: 0 < 283680> < 9580482>
11 i0: 0 < 317708> < 9580507>
12 i0: 0 < 351736> < 9580530>
...
2120 i0: 0 < 72379800> < 9633612>
2121 i0: 0 < 72413452> < 9633637>
2122 i0: 0 < 72447856> < 9633661>
2123 i0: 0 < 72482072> < 9633684>
2124 i0: 0 < 72516100> < 9633708>
2125 i0: 0 < 72550316> < 9633732>
2126 i0: 0 < 72584344> < 9633756>
2127 i0: 0 < 72618372> < 9633780>
2128 i0: 0 < 72652588> < 9633828>
2129 i0: 0 < 72686804> < 9633852>
2130 i0: 0 < 72720832> < 9633876>
2131 i0: 0 < 72754672> < 9633900>
2132 i0: 0 < 72788888> < 9633924>
2133 i0: 0 < 72822916> < 9633948>
2134 i0: 0 < 72856944> < 9633972>
...
2871 i0: 0 < 98172648> < 9652631>
2872 i0: 0 < 98206864> < 9652655>
2873 i0: 0 < 98240892> < 9652679>
2874 i0: 0 < 98275108> < 9652703>
2875 i0: 0 < 98309136> < 9652727>
2876 i0: 0 < 98343164> < 9652751>
2877 i0: 0 < 98377380> < 9652775>
2878 i0: 0 < 98411408> < 9652799>
2879 i0: 0 < 98445812> < 9652823>
2880 i0: 0 < 98479652> < 9652848>
2881 i0: 0 < 98513680> < 9652872>
2882 i0: 0 < 98548084> < 9652897>
2882 blocks

Little Endean Integer with difference for the 1rst column and substracting 9580000 from the second


1 i0: 0 < 0>delta= 0 < 281>delta= 281
2 i0: 0 < 11268>delta= 11268 < 291>delta= 10
3 i0: 0 < 45296>delta= 34028 < 316>delta= 25
4 i0: 0 < 79324>delta= 34028 < 339>delta= 23
5 i0: 0 < 113540>delta= 34216 < 362>delta= 23
6 i0: 0 < 147380>delta= 33840 < 386>delta= 24
7 i0: 0 < 181596>delta= 34216 < 411>delta= 25
8 i0: 0 < 215624>delta= 34028 < 434>delta= 23
9 i0: 0 < 249652>delta= 34028 < 460>delta= 26
10 i0: 0 < 283680>delta= 34028 < 482>delta= 22
11 i0: 0 < 317708>delta= 34028 < 507>delta= 25
12 i0: 0 < 351736>delta= 34028 < 530>delta= 23
...
2120 i0: 0 < 72379800>delta= 34404 < 53612>delta= 23
2121 i0: 0 < 72413452>delta= 33652 < 53637>delta= 25
2122 i0: 0 < 72447856>delta= 34404 < 53661>delta= 24
2123 i0: 0 < 72482072>delta= 34216 < 53684>delta= 23
2124 i0: 0 < 72516100>delta= 34028 < 53708>delta= 24
2125 i0: 0 < 72550316>delta= 34216 < 53732>delta= 24
2126 i0: 0 < 72584344>delta= 34028 < 53756>delta= 24
2127 i0: 0 < 72618372>delta= 34028 < 53780>delta= 24
2128 i0: 0 < 72652588>delta= 34216 < 53828>delta= 48
2129 i0: 0 < 72686804>delta= 34216 < 53852>delta= 24
2130 i0: 0 < 72720832>delta= 34028 < 53876>delta= 24
2131 i0: 0 < 72754672>delta= 33840 < 53900>delta= 24
2132 i0: 0 < 72788888>delta= 34216 < 53924>delta= 24
2133 i0: 0 < 72822916>delta= 34028 < 53948>delta= 24
2134 i0: 0 < 72856944>delta= 34028 < 53972>delta= 24
...
2871 i0: 0 < 98172648>delta= 34028 < 72631>delta= 23
2872 i0: 0 < 98206864>delta= 34216 < 72655>delta= 24
2873 i0: 0 < 98240892>delta= 34028 < 72679>delta= 24
2874 i0: 0 < 98275108>delta= 34216 < 72703>delta= 24
2875 i0: 0 < 98309136>delta= 34028 < 72727>delta= 24
2876 i0: 0 < 98343164>delta= 34028 < 72751>delta= 24
2877 i0: 0 < 98377380>delta= 34216 < 72775>delta= 24
2878 i0: 0 < 98411408>delta= 34028 < 72799>delta= 24
2879 i0: 0 < 98445812>delta= 34404 < 72823>delta= 24
2880 i0: 0 < 98479652>delta= 33840 < 72848>delta= 25
2881 i0: 0 < 98513680>delta= 34028 < 72872>delta= 24
2882 i0: 0 < 98548084>delta= 34404 < 72897>delta= 25
2882 blocks

[hech54]

I would like to extract my recordings from this dik and convert them to divx. One hour of recording on the disk takes a huge space (~3Go).

I think the most obvious question is:
Who told you it was possible to do that?
The files on the HDD of my SageCom TV box recording Kabel Deutschland can only be read by the cable box.
The files on the USB stick recorded by both my LG LCD TV and my Philips LCD TV can only be read when attached to the television(s).
So I ask again....what makes you think this is possible?

[usually_quiet]

@jmw67 Deciphering the idx files and finding a way to re-assemble the the DVR's .ts files into a standard .ts file seems like it may be a long term project. If you would prefer to have playable files more quickly, have you considered using a capture device to re-record the DVR's output on your computer? Since you have a Windows PC, you have a range of capture hardware and capture software to choose from. If you are willing to accept H.264 rather than DivX for compact files, there are capture devices that hardware encode straight to H.264.

[jmw67]

Hi,
@hech54

Who told you it was possible to do that?

Nobody

So I ask again....what makes you think this is possible?

In a first place I thought that the TS files are standard. I discovered later that this is not the case. Now I am just curious to see how the data is organized, and if I get access to the data may be I can built up something like MPEG-TS and then use available tools.

@usually_quiet

it may be a long term project

I agree completly

I am not locked to divx format. I follow your thinking with the DVR. But how would you use the capture hadware/software? To treate the rerecorded data?

Thanks for your reply

[nic2k4]

I tried to find something from my providers web site and otheer forums but no data is really available.

I have a friend in Australia, that had been working on the same problem with a popular PVR over there. Because the device was popular enough and there was enough interest in the project, a community built around it. It took them months of collaborative work to be able to reverse engineer the recording. The bigger problem is that they're at the mercy of the provider; all their work could go down the drain every time there's a system update. So far they've been lucky that no encryption has been thrown in the mix (probably due to the device's capabilities) and costs is surely the only thing keeping the provider from completely re-implementing their software... I hope you see where this is going.

As for Videohelp, most of the people here are video enthusiasts, there are some professionals and some programmers too, but I don't know if anybody has the knowledge you need. All I know is you need a better thread title to get their attention. Although, this may not be the best place to start a PVR hacking community. I would suggest you look at Yhaoo groups or forums for other brand PVR. You should be searching by chipset instead of device model number; devices with the same hardware should operate the same way.

[netmask56]

It's a long shot but why don't you post the information on the Australian Beyonwiz PVR site. The recording format is similar inasmuch the recording is broken up into small chunks - no "idx" between them and it is fairly straight forward to join up the chunks into a standard mpegts file with either of 2 software programs, one supplied by the company and a much better one by a community member on the forum.

http://www.beyonwiz.com.au/ The forum boasts a few programmers and technical savvy members so maybe you might get some pointers there.

Here is a screen shot of part of a typical " .tvwiz " format

[jmw67]

Hi,
@netmask56
Thanks for the link to the beyonwiz web site, but when I try to access the forum at http://www.beyonwiz.com.au/phpbb2/index.php the page tells me that I am banned from this forum. This is the first time I went there!!!

@nic2k4

All I know is you need a better thread title to get their attention

I agree.
Since the start of this thread I learned a lot. So my problem is how to reconstruct the video/audio stream from a segmented stream similar to HTTP Live Streaming
@nic2k4

It took them months of collaborative work to be able to reverse engineer the recording.

This is not really what I wand to do. The data is recorded on hard disk that that I can extract end then read on my computer. I just try to understand data organisation and built up from that a standard format to use available tools, if this is possible.


I could further understand my data, for more details please read below.
Thanks for your reply

=============================================
As I said in my initial mails, the first bytes are conserved in all idx files they may encode for the encoding of video/audio (21 bytes) :
0200 0000 1c00 0000 0000 0000 0400 0000 7267 616e 02
entering the following texte in google : "0x72 0x67 0x61 0x6e", I get some hints, one of them H264
And entering "0x72 0x67 0x61 0x6e H264" I get source code files. Is it meaningfull?

For the other values I show you the beginning and end of the data for the first 3 files(0004000.idx, 0004001.idx, 0004002.idx) the first value in <> seem to be the segmented data and the second <> is related to the time line (check first and last values between 2 successive files they are the same) and the number of lines in an idx file is very close to
2880=24*60*2 and this is for one minute :

00040000.idx
1 : < 0>delta= 0 < 9507621>delta=9507621
2 : < 14100>delta= 14100 < 9507638>delta= 17
3 : < 48316>delta= 34216 < 9507662>delta= 24
4 : < 82156>delta= 33840 < 9507678>delta= 16
...
2891 : < 98468384>delta= 34216 < 9580194>delta= 23
2892 : < 98502788>delta= 34404 < 9580219>delta= 25
2893 : < 98536628>delta= 33840 < 9580242>delta= 23
2894 : < 98570656>delta= 34028 < 9580242>delta= 0

60*24*2=2880

00040001.idx
1 : < 0>delta= 0 < 9580242>delta=9580242
2 : < 0>delta= 0 < 9580281>delta= 39
3 : < 11268>delta= 11268 < 9580291>delta= 10
4 : < 45296>delta= 34028 < 9580316>delta= 25

2882 : < 98513680>delta= 34028 < 9652872>delta= 24
2883 : < 98548084>delta= 34404 < 9652897>delta= 25
2884 : < 98581924>delta= 33840 < 9652897>delta= 0


00040002.idx
1 : < 0>delta= 0 < 9652897>delta=9652897
2 : < 0>delta= 0 < 9652967>delta= 70
3 : < 22348>delta= 22348 < 9652968>delta= 1
4 : < 56564>delta= 34216 < 9652976>delta= 8
5 : < 90404>delta= 33840 < 9652991>delta= 15

2875 : < 98438468>delta= 34028 < 9725473>delta= 16
2876 : < 98472872>delta= 34404 < 9725501>delta= 28
2877 : < 98506900>delta= 34028 < 9725521>delta= 20
2878 : < 98540740>delta= 33840 < 9725544>delta= 23
2879 : < 98574956>delta= 34216 < 9725544>delta= 0

[usually_quiet]

@usually_quiet

it may be a long term project

I agree completly

I am not locked to divx format. I follow your thinking with the DVR. But how would you use the capture hadware/software? To treate the rerecorded data?

Thanks for your reply

To use the capture hardware and software you would have to:
1. Connect the hardware between the PVR and your computer
2. Use the PVR to play the recordings you want to save while capturing with the software.


You won't have the original MPEG-2 video from the DVR, but if you buy a good capture device and use both the device and its capture software correctly, you will have a copy that is good quality and smaller in size. ...and most importantly, you won't have to wait until you or someone else finds a solution to your current technical problems with re-assembling the files from the DVR into something that is usable.


The down side is the expense, assuming you need to capture high-definition video. An HDMI capture device won't be inexpensive. I don't know what you will pay for one in France, but most are priced at $150-$200 in the US. You will probably also need a device that removes HDCP copy protection from HDMI signals. An inexpensive HDMI splitter is often used to remove HDCP, but only some of them have the ability. I could provide links for devices sold on Amazon US for $25 or $40 that work, but I don't know if the same products are sold in the EU. Also, if you need to remove unwanted material from the captures, you may need to purchase an editor. Freeware that does a good job editing H.264 video isn't available yet.

[nic2k4]

The data is recorded on hard disk that that I can extract end then read on my computer.

Read, as in with a hex editor or can you actually play the recording? If you have software than can play it, you should be able to use something like Graph Edit or a screen capture program and convert it.

[[_chef_]]

Exactly so!