• 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

raydon said:
That's because native HDR video has 192 byte packet size (M2TS format) although recordings have the .ts extension.
Convert your source to .m2ts format with tsMuxeR GUI (very fast) then rename them to .ts before processing with sidecar.
Click to expand...

Thanks. That worked as advertised.
 
JoeBloggs911 said:
How difficult, if at all possible, would it be to tweak this so it can process .ts files from an old Humax 9200T? It now aborts with "ERROR: Source video packet size is 188 bytes, must be 192."
Click to expand...
You need the hrwconv package to simplify this, if the files are already on the Humax.
 
IIRC when I copied the TSs from my 9200 to my T2, they 'just worked' providing you don't want the fancy stuff.
 
Trev said:
IIRC when I copied the TSs from my 9200 to my T2, they 'just worked' providing you don't want the fancy stuff.
Click to expand...
You do RC, but clearly the OP does want proper transport controls, otherwise he wouldn't be here asking about sidecar would he?
 
prpr said:
You need the hrwconv package to simplify this, if the files are already on the Humax.
Click to expand...

Can this work even if I only have the old 9200T .ts files without their original sidecars? The package notes seem to imply that they're needed.

You're right about proper transport controls. I was upset when I first got my T2 to find that recorded radio's play controls had been butchered: no fast-forward or back. The old 9200T had them, so I don't understand why Humax cut them out. It's a real nuisance when the BBC front-load recordings with a minute or more of trails.
 
JoeBloggs911 said:
Can this work even if I only have the old 9200T .ts files without their original sidecars? The package notes seem to imply that they're needed.
Click to expand...
Yes, it does work. The original 9200 sidecars are optional, not required.
I don't understand why Humax cut them out.
Click to expand...
I expect they thought that dumbing down the interface would make it simpler for people. Of course, it doesn't, it just annoys those who used the facility. Those who didn't use it didn't care whether it was there or not. I expect it was some clueless Humax bean-counter somewhere trying to save money/development time. All they succeeded in doing was making things inconsistent.
It's a real nuisance when the BBC front-load recordings with a minute or more of trails.
Click to expand...
Programmes don't start exactly on time like they should do for telly. It's just done on a clock schedule.
 
prpr said:
Yes, it does work. The original 9200 sidecars are optional, not required.
Click to expand...

I managed to get it to work after some misadventures. I had trouble navigating to the directory with the .ts files because I'd forgotten the "ls" command and also fell foul of linux's case sensitivity and inability to handle the space in "My Video". The hrwconv package worked, albeit with some intermittent error messages. But it was very slow, so I'll probably stick with the tsMuxeR/Sidecar combination on the PC.

Getting the full transport controls was useful, but my main reason for converting the files is to process them with detectads.
 
I have just released sidecar v2.5. This version has some refinements to the way the nts 'Played time' entry at offset 0x18 is calculated. Previous versions used a calculation based solely on PES PTS values (which do not always increase monotonically)
To account for this, v2.4 simply used repeat values when the current PTS value was less than that in the previous one.
This version uses a combination of both PTS and DTS values to derive more accurate monotonically increasing values for the timebar.
Wiki links for Linux and Windows versions have been updated accordingly.
 
Last edited:
raydon said:
I have just released sidecar v2.5. This version has some refinements to the way the nts 'Played time' entry at offset 0x18 is calculated. Previous versions used a calculation based solely on PES PTS values (which do not always increase monotonically)
To account for this, v2.4 simply used repeat values when the current PTS value was less than that in the previous one.
This version uses a combination of both PTS and DTS values to derive more accurate monotonically increasing values for the timebar.
Wiki links for Linux and Windows versions have been updated accordingly.
Click to expand...
Thanks for the sidecar updates.
I had noticed with earlier versions of sidecar that the nts files created for recordings (H264 video) that had been remuxed with ffmpeg had unusually large values corresponding to the offset at 0x18 (onscreen time bar value) for some early frames (typically 2-9 frames). Since the latest update, the first frame of ffmpeg-remuxed MPEG video also gets assigned a large value in the nts file at offset 0x18. I made short recordings of H264 and MPEG streams and remuxed both 'on-the-box' with stream copying, and have attached example nts files below. The original recordings are unaffected, so it must be something that ffmpeg does that causes this. I appreciate that sidecar works as intended for native recordings, but thought I'd mention it as packages like hrwconv use both ffmpeg and sidecar. It is easy to fix the files with a hex editor, by setting the affected values to zero.
 

Attachments

MontysEvilTwin said:
Thanks for the sidecar updates.
I had noticed with earlier versions of sidecar that the nts files created for recordings (H264 video) that had been remuxed with ffmpeg had unusually large values corresponding to the offset at 0x18 (onscreen time bar value) for some early frames (typically 2-9 frames). Since the latest update, the first frame of ffmpeg-remuxed MPEG video also gets assigned a large value in the nts file at offset 0x18. I made short recordings of H264 and MPEG streams and remuxed both 'on-the-box' with stream copying, and have attached example nts files below. The original recordings are unaffected, so it must be something that ffmpeg does that causes this. I appreciate that sidecar works as intended for native recordings, but thought I'd mention it as packages like hrwconv use both ffmpeg and sidecar. It is easy to fix the files with a hex editor, by setting the affected values to zero.
Click to expand...
@MontysEvilTwin Thanks for that information. It seems that I inadvertently introduced a bug into that last version which caused the problem you saw with ffmpeg remuxed video. I've just uploaded sidecar v2.6 to the repository, which hopefully will have fixed it. Can you confirm ? Wiki links to other OS versions updated also.
Oops. I left a temporary debug message in v2.6. Now on v2.7 :rolleyes:
 
Last edited:
raydon said:
@MontysEvilTwin Thanks for that information. It seems that I inadvertently introduced a bug into that last version which caused the problem you saw with ffmpeg remuxed video. I've just uploaded sidecar v2.6 to the repository, which hopefully will have fixed it. Can you confirm ? Wiki links to other OS versions updated also.
Oops. I left a temporary debug message in v2.6. Now on v2.7 :rolleyes:
Click to expand...
I tested with the same remuxed recordings I used previously, now with v2.6, and it was fine with both MPEG and H264 video. I'll do a bit more testing and will post if I get any unexpected results. Thanks for the fix.
 
I did some further tests with longer recordings (up to about 1 hour 40 minutes, remuxed with ffmpeg) using sidecar 2.7. The nts files created for MPEG video recordings are fine, as far as I can tell. There is still a problem with H264 video though. In the example attached (recording of about 58 minutes), the values corresponding to the on-screen time bar start to be set to a high value (2359b005 in this case) later on in the recording (first example at offset 0x0053bbd8). This happens about every other frame for a while and then less frequently until the end. I had to split the nts file to allow me to post all of it. The second part is in the next message. It can be recombined using the 'cat' command after extracting the files from the zip files.
 

Attachments

Thanks for that report and the nts file. Unfortunately, the nts file alone is insufficient to perform any analysis. It would also require the ts file, for use in cross reference.
 
I have just uploaded sidecar v2.8 to the repository.
@MontysEvilTwin was able to provide the problem H264 ts file associated with the above nts file, enabling me to do an in depth analysis.
Turns out that towards the latter end of the stream ffmpeg was writing the odd PES packet containing the start of a pic slice, without any PTS or DTS timestamp in the header.
Native MPEG/H264 ts files created on the box are unaffected by this behaviour.
I have created a workaround for this in v2.8, to better enable the hrwconv utility (which has dependencies on ffmpeg and sidecar) to process sources from earlier Humax products.
Wiki download links to other OS binaries have been updated accordingly.

Note: Can you please limit any future sidecar bug reporting to problems/errors generated when processing native HDR video streams only. Thank you.
 
raydon said:
Wiki download links to other OS binaries have been updated accordingly.
Click to expand...
I get "This contains a virus" or words to that effect when trying to download either of those with FF. Not sure what/how it's being generated, but it doesn't want to download.
 
prpr said:
I get "This contains a virus" or words to that effect when trying to download either of those with FF. Not sure what/how it's being generated, but it doesn't want to download.
Click to expand...
Just rechecked the download links using Firefox and Edge and they are both downloading OK.
You just need to complete the captcha to get the link. I've been using filecloud.io for a good while now with no problems.
Antivirus false positive maybe ?

EDIT: Checked the 'download progress' tab in Firefox and there is a virus warning with the option to delete or open the file. This is a "feature" of Firefox
See here and here for details.
It is safe to ignore this warning, at least with my files anyway, and open the zip. Alternatively, use another browser which is a bit less paranoid.
 
Last edited:
You must log in or register to reply here.
Back
Top