-
The forum software that supports hummy.tv has been upgraded to XenForo 2.3!
Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.
'Sidecar' plug-in for the HDR/HD Fox T2
- Thread starter raydon
- Start date
MontysEvilTwin
Well-Known Member
If there is no easy way to be certain a particular recording is 'SD' or 'HD' would it be possible to add a 'HD' checkbox by the channel number and name boxes? This could be ticked or unticked automatically based on the default but could be changed if necessary before creation of the new hmt file.
Not easy to extract this information from H264 video stream, but certainly do-able. I'll put it on my 'to do' list but I don't know when I'll get round to it.
Sidecar v2.1 is now available in the repository. Changes as follows:
Video size and format is now determined by parsing mpeg Sequence header, or h264 Sequence Parameter Set.
An existing hmt file will no longer be overwritten unless it is a dummy created by sidecar for the purpose of enabling decryption.
Instead, the following entries will be updated.
Channel Number
Channel Name
Recording Duration
Recording End Time
Other hmt entries can be edited via the web interface 'Rename' option or directly from the command line using af123's hmt utility.
Video size and format is now determined by parsing mpeg Sequence header, or h264 Sequence Parameter Set.
An existing hmt file will no longer be overwritten unless it is a dummy created by sidecar for the purpose of enabling decryption.
Instead, the following entries will be updated.
Channel Number
Channel Name
Recording Duration
Recording End Time
Other hmt entries can be edited via the web interface 'Rename' option or directly from the command line using af123's hmt utility.
Last edited:
Sidecar v2.3 is now available in the repository.
New in this version :
A third option button has been provided in the sidecar screen to allow the display of transport stream information only. No sidecars are created when selecting this option.
Content Management metadata has been added to the displayed information.
Obviously, the recording will still need to be decrypted first in order to retrieve this metadata from the transport stream.
New in this version :
A third option button has been provided in the sidecar screen to allow the display of transport stream information only. No sidecars are created when selecting this option.
Content Management metadata has been added to the displayed information.
Obviously, the recording will still need to be decrypted first in order to retrieve this metadata from the transport stream.
N/A - Not Applicable. I really don't think that line could cause any confusion, but maybe in a future release...
Last edited:
MontysEvilTwin
Well-Known Member
I've noticed that rewinding MPEG ts recordings, with Sidecar-generated nts files, at x2 and x4 speeds gives blocky pictures. At greater rewind speeds the picture is fine. H264 ts files (both standard and high definition) are fine at all rewind speeds: it only affects MPEG format video.
Thanks for the info Monty but I don't feel the need to revisit the code for something as trivial as this.
MontysEvilTwin
Well-Known Member
Fair enough, it has taken this long for someone to notice.
MontysEvilTwin
Well-Known Member
Out of interest I compared an original nts file (mpeg) to one created using sidecar. The sidecar-created file has an extra 32 byte block at the end of the file, but that does not appear to cause any issues. The only other differences are the played time values stored in the 4 byte block starting at offset 0x18, and the values at equivalent offsets in the subsequent 32 byte entries. Some extracted data is presented below:
The absolute values are different; the original file only has the played time value updated about every fourth block (each 32 byte block presumably equals a frame of video?). Sidecar appends a new value to every 32 byte entry, but sometimes the value goes down rather than up: this could be the source of the blocky picture during rewind. If I am right that each 32 byte section of data corresponds to 1 frame, then since the video is 25 frames per second, I would expect the above example to correspond to about half a second of video. However, while the data presented from the sidecar-generated file does equal half a second, the timings in original file correspond to 1 second. This difference may be significant.
Code:
Offset Time (ms) Time (ms)
(4 bytes) Original Sidecar
0x18 766 320
0x38 1021 440
0x58 1022 360
0x78 1022 400
0x98 1274 560
0xb8 1274 480
0xd8 1274 520
0xf8 1528 680
0x118 1528 600
0x138 1528 640
0x158 1528 800
0x178 1783 840Thanks for the info Monty. In an MPEG nts file each 32 byte block does indeed correspond to 1 video frame. However, as you so correctly pointed out, the sidecar generated time values should always be increasing, never decreasing, I'll check this out when I have the time, but I have a lot on at present.
Regarding the 12 timestamp values you quoted, it's much too small a sample to make a real judgement. Try deducting the first value from the last value, which should always equate to the recording duration in milliseconds.
MontysEvilTwin
Well-Known Member
You are right about the sample size. I looked at sidecar generated nts files for a couple of films: the recording durations are correct.
MymsMan
Ad detector
Sometimes the Humax generated nts file contains entries for more frames than actually exist in the actual recording at both beginning and end so surplus nts entries are no problem and of course the nts is not required for standard speed playing.
You shouldn't rely on the video being exactly 25fps. Especially for HD recording the Humax creates more than 25fps, some of the frames being very short (which exposes a bug in nicesplice). If you divide the actual frame count by recording duration the result is often between 26 and 27fps.
prpr
Well-Known Member
I've been doing a bit of analysis on this too (SD only so far), and I'm afraid to say that Raydon has got another field wrong in the .nts file.
The field at offset "0x05 1 byte Picture sequence frame count" is shown here as created by sidecar in column 3, and the correct version in column 4 by my analysis/fix utility:
The first P-frame after the I-frame resets the counter (to the number of frames between P and I). As it is at the moment, sidecar just seems to have hard-coded the GoP structure, which is never going to be the right thing to do.
I've also seen files such as:
but I think they must've been created by nicesplice.
The field at offset "0x05 1 byte Picture sequence frame count" is shown here as created by sidecar in column 3, and the correct version in column 4 by my analysis/fix utility:
Code:
1 I 0 0
2 P 1 1
3 B 2 2
4 B 3 3
5 P 4 4
6 B 5 5
7 B 6 6
8 P 7 7
9 B 8 8
10 P 9 9
11 B 10 10
12 P 11 11
13 B 12 12
14 P 3 13
15 B 4 14
16 P 5 15
17 B 6 16
18 P 7 17
19 B 8 18
20 P 9 19
21 B 10 20
22 P 11 21
23 B 12 22
24 P 13 23
25 B 14 24
26 P 3 25
27 B 4 26
28 P 5 27
29 B 6 28
30 I 7 29
31 B 8 30
32 B 9 31
33 P 10 3
34 B 11 4
35 B 12 5
36 P 13 6
37 B 14 7
38 B 3 8
39 P 4 9
40 B 5 10
41 B 6 11
42 P 7 12
43 B 8 13
44 B 9 14
45 P 10 15
46 B 11 16
47 B 12 17
48 P 13 18
49 B 14 19
50 B 3 20
51 P 4 21
52 B 5 22
53 B 6 23
54 P 7 24
55 B 8 25
56 B 9 26
57 P 10 27
58 B 11 28
59 B 12 29
60 I 13 30
61 B 14 31
62 B 3 32
63 P 4 3
64 B 5 4
65 B 6 5
66 P 7 6
67 B 8 7
68 B 9 8
69 P 10 9
70 B 11 10
71 B 12 11
72 P 13 12
73 B 14 13
74 B 3 14
75 P 4 15
76 B 5 16
77 B 6 17
78 P 7 18
79 B 8 19
80 P 9 20
81 B 10 21
82 P 11 22
83 B 12 23
84 P 13 24
85 B 14 25
86 P 3 26
87 B 4 27
88 P 5 28
89 B 6 29
90 P 7 30
91 B 8 31
92 I 9 32
93 B 10 33
94 P 11 2
95 B 12 3I've also seen files such as:
Code:
1 I 24 0
2 P 25 1
3 B 26 2
4 B 3 3
5 P 4 4
Last edited:
Another one ? Which other fields were wrong in my nts analysis ?