'Sidecar' plug-in for the HDR/HD Fox T2

Hmm, I had been using video codec to determine resolution. SD =MPEG, HD = H264. However, it seems some broadcasters are also using H264 for SD.
 
I had the same false assumption in the hmt utility code. In my case it was just a case of looking at the right bytes in the original .hmt
 
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.
 
MontysEvilTwin said:
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.
Click to expand...
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.
 
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.
sidecar_2.3.png
 
I tried this on a radio recording and it said:

Format SD MPEG, 0 x 0. N/A.
Video ID $0000, not present.

Maybe the first line could be removed if there is no Video PID as it's obviously meaningless?
 
prpr said:
I tried this on a radio recording and it said:

Format SD MPEG, 0 x 0. N/A.
Video ID $0000, not present.

Maybe the first line could be removed if there is no Video PID as it's obviously meaningless?
Click to expand...
N/A - Not Applicable. I really don't think that line could cause any confusion, but maybe in a future release...
 
Last edited:
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.
 
MontysEvilTwin said:
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.
Click to expand...
Thanks for the info Monty but I don't feel the need to revisit the code for something as trivial as this.
 
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:
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        840
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.
 
MontysEvilTwin said:
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.
Click to expand...
Thanks 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.
 
raydon said:
Thanks 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.
Click to expand...
You are right about the sample size. I looked at sidecar generated nts files for a couple of films: the recording durations are correct.
 
MontysEvilTwin said:
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.
Click to expand...
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.
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.
Click to expand...
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.
 
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:
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  3
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:
Code: 
  1 I 24  0
  2 P 25  1
  3 B 26  2
  4 B  3  3
  5 P  4  4
but I think they must've been created by nicesplice.
 
Last edited:
prpr said:
I've been doing a bit of analysis on this too (SD only so far), and I'm afriad to say that Raydon has got another field wrong in the .nts file.
Click to expand...
Another one ? Which other fields were wrong in my nts analysis ?
 
Not in the analysis, but in the implementation in sidecar of what goes in the ms time field in the .nts file, as detailed in #114.
 
You must log in or register to reply here.
Back
Top