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

Black Hole said:
I found a use for sidecar - I exported my recording of Men in Black 3 (C4 HD) to PC and removed the adverts using VideoReDo TVSuite V5, then imported it again, prior to a screening tonight.
Click to expand...
Any particular reason for exporting/VRD/import rather than using DetectAds directly on the box?
 
Faster, more accurate...

That's not to say detectads isn't a great utility, but having paid up for VRD I now have frame-accurate editing without transcoding. Which is not to say VRD can't be improved...
 
In the event there was no need to recreate the sidecar files, and the .hmi file was sufficient to be able to stop and resume. I will however make a mental note to use M2TS next time I process anything with VRD.

VRD needs the ability to inset sections of black (or still-frame) video, and to cut the audio track at a different place to the video, then it will have all bases covered.
 
Black Hole said:
VRD needs the ability to inset sections of black (or still-frame) video
Click to expand...

You can insert black video at the start and/or the end of the edited video fairly easily, using the VideoReDo "Title" option.

Adding to the start: after editing the video:
Tools/Title Editor - click on OK without making any changes, then save the edited video as usual.​

Adding to the end: after editing the video:
Joiner/Add Current Project to Joiner List
Joiner/Edit Joiner List: Add Title - click on OK without making any changes
then select "Create video from joiner list" in the Joiner Editing panel (instead of saving the video in the usual way).​

Adding to the start and to the end: a combination of the above - after editing the video:
Tools/Title Editor - click on OK without making any changes (for the start)
Joiner/Add Current Project to Joiner List
Joiner/Edit Joiner List: Add Title - click on OK without making any changes
then select "Create video from joiner list" in the Joiner Editing panel (instead of saving the video in the usual way).​

The default duration of the Title is set in Tools/Options/Titling. The duration can be changed, case by case, in the Title Editor (via the Edit option in the Title Editor panel) but it is much easier to set a suitable default duration.

Note: as far as I can see, the "Fade In" and "Fade Out" title durations apply to any text or images that have been entered into the title - the actual video is not faded in or out.

It is possible, but fiddly, to insert black video into the middle of a video by splitting the video, then adding the first part to the Joiner, then adding a Title, then adding the second part. Not ideal, but possible.

PS I find that if I usually save as a specific format, say "MPEG M2TS (*.m2ts)" from the VDR save options - it makes life a little easier to change the default file save format in Tools/Options/General Parameters from "Match source format" to "Last used profile".
 
Last edited:
Yes, I know about that. What it doesn't account for it the tendency for the sound track to continue past the cut point, hence the need to cut the sound track independently of the video (and replace - eg - a channel ident slide with black when the sound bleeds across).
 
Black Hole said:
Yes, I know about that. What it doesn't account for it the tendency for the sound track to continue past the cut point, hence the need to cut the sound track independently of the video (and replace - eg - a channel ident slide with black when the sound bleeds across).
Click to expand...
Using Nicesplice/crop on the Humax I have noticed the reverse problem - lack of sound for a couple of seconds following a crop, usually this is not a problem since there is often a title screen following an ad break but it is more noticeable on some films/dramas where the action starts immediately with no lead in.
 
Black Hole said:
Yes, I know about that. What it doesn't account for it the tendency for the sound track to continue past the cut point, hence the need to cut the sound track independently of the video (and replace - eg - a channel ident slide with black when the sound bleeds across).
Click to expand...

Sorry for inadvertantly "trying to teach my grandmother how to suck eggs"!

I've just looked at a test example where I have added a blank "Title" at the end of a video (using VDR) and I can see that the audio does bleed into the added black "title" - though in the example I looked at it was only a few milliseconds. Curious.
 
Not all that curious - where in the frame graphic (on the VRD timeline) does the video sync with the audio? We don't know exactly. Each frame spans 40ms so "a few milliseconds" is not really overlapping audio!
 
Sidecar plug in has now been updated to v1.4.
This is a bug fix release for an issue reported recently. When attempting to process non native recordings the application froze (on box version) or crashed with a system error message (Linux x86 version). Anyone now attempting to process non native transport streams will either succeed to some degree, or sidecar will exit gracefully with the expected short message on why it didn't, rather than aborting prematurely with a cryptic system crash error.
 
Last edited:
The sidecar plug in has now been updated to v1.5. Changes as follows:

Earlier versions of sidecar incorrectly listed an AAC audio track as MPEG if it was encoded using ADTS. This problem only affected non-native imports, since the T2 itself encodes AAC audio using LATM. This problem has now been resolved.
I have also reverted .hmt generation back to pre v1.4 format, which was to always include Program and PMT ID's in the .hmt by default. This is what a Humax generated hmt contains, and what works for the majority of non-native imports. However, as another means to achieve successful audio playback of non-native imports I have added the command line switch -x : Exclude Prog/PMT ID's from .hmt file. In the event your imported video does not play back with sound, then recreating the .hmt using the -x option may well enable it. This is the final concession I will be making to improve compatability with non-native imports, since sidecar was written solely for the purpose of recreating .hmt and .nts files for native recordings only.
In all earlier versions, the program name for the Media List was created using the file name if the transport stream did not contain EIT information(i.e "shrunk", or non-native recordings). This meant that the Media List program name could well contain Humax style extended date/time information appended to the end of the recording name. Additionally, if the recording was "shrunk", this name would be even further extended by the addition of an epoch format number containing the date/time of the "shrink" operation. With sidecar v1.5 I have included a regex which strips off this extraneous information before writing the program name to the .hmt file.
A link to the linux x86 version of sidecar v1.5 is available in the wiki.
 
Last edited:
Time stamps in .hmt file generated by Linux stand-alone version of sidecar.

This is relatively minor matter and I'm hesitant to bring it up (not knowing my arse from my elbow) but I've noticed something a bit odd with the timestamps in .hmt files generated by sidecar when the .hmt file is generated from the original (unedited) .ts file. (Admittedly this is probably an unusual scenario.)

Circumstances:
- Recorded SD programme without padding, today (BST applies)
- Copied programme to Ubuntu server with WebIf.
- Deleted the .hmt and .nts files on the Ubuntu server (after backing them up).
- Used the stand-alone sidecar to generate new .hmt and .nts files (on the Ubuntu server).
- sidecar seems to cleverly pick up the date/times but all the date/time stamps in the sidecar generated .hmt file are 1 hour prior to the timestamps in the original .hmt file (i.e. GMT minus 1 hr)

As far as I can see, the actual timestamps in .hmt files generated by the Humax are GMT (i.e. BST minus 1 hour) so I wonder whether some GMT/BST adjustment is being applied twice (not that I know anything about it).

Do feel free to shoot me down in flames!
 
I think that the HDR-FOX is always set to GMT (in the UK and ROI) and when we switch to BST it applies a one hour offset rather than changing the base time: you can see this in the hidden menu under network time, I think. I have often noticed a one hour time difference for files viewed on the HDR-FOX and on a PC for example. The HMT file format is in the wiki here. The recording dates and times are stored in the HMT file in Unix (epoch) time so, presumably, the hour difference relates to how this is converted to local time.
 
Yes, that bears out what I can see when I examine the data in the HMT files. (I wrote a quick and dirty Excel macro to display the data from specified HMT files, based on the wiki page you pointed to.)

My point was that the timestamps generated by sidecar for BST recordings seem to be one hour before the timestamps on the original .hmt file, as though an additional GMT/BST adjustment had been made.

I will try to hunt down a Hummy generated programme/hmt/nts set for a non-BST recording and check what happens then.

Later Edit:

I have just done exactly the same procedure with a non-BST native Hummy recording. In this case the timestamps generated by sidecar are correct. So I think the issue is with recordings made during BST (possibly to do with an additional -3600 second adjustment to convert BST to GMT). As I said before - not that I know anything about anything.
 
Last edited:
Hopefully the package author, raydon, will see these posts and be able to clarify. It is possible to change the recording time-stamp in the HMT file using a script based upon the HMT utility: see here. General info on the HMT utility is in the wiki here.
 
The BST correction to the times in the HMT was being made because of an incorrect parameter setting in a struct used for a call to the mktime() function which converts a date/time to an epoch value. This only happened with recordings made during the Summer months which is how it slipped through the net.
Also, there is a previously undocumented flag in the HMT file at offset 0x0434 which denotes that a recording was made during BST. This flag is read by the T2, which then applies the one hour offset to GMT timestamps prior to display in the Media List. This flag was missing from sidecar generated HMT's.
Don't know if af123's hmt utility uses this flag, or he has utilised some other means to determine the BST status of a recording, as the times display correctly in the webif Media Browser for both GMT and BST.
I've updated sidecar to v1.7 to correct the struct parameter, and also detect BST recordings and write the HMT flag accordingly.
Unfortunately, I can't update the repository just yet as I'm getting a '403 Forbidden' instead of the login prompt. af123, can you see what's wrong here ?
I have however, updated the download link to the 1.7 linux_x86 version in the wiki, and updated the HMT format information to include the BST flag offset and value.
 
OK, the repository upload is now working again. Thanks af123 :thumbsup:
Latest version in the repository is now v1.8 as I've since added a check for thumbnail file existing, in order to correctly set the hmt flag at offset 0x28e, bit 1.
Link to linux_x86 version also updated to v1.8.
 
raydon said:
Don't know if af123's hmt utility uses this flag, or he has utilised some other means to determine the BST status of a recording, as the times display correctly in the webif Media Browser for both GMT and BST.
Click to expand...
I didn't know about the flag (which appears to be a number of seconds btw - it's a little endian 16-bit value of 0xE10 == 3600) - it must just show correctly due to the TZ variable in the web interfaces's environment.
 
You must log in or register to reply here.
Back
Top