Thumbnails - any configuration?

[jxp]

I've just bought a HDR-Fox and installed the custom firmware. Early days yet but so far I have only two small issues;

1. No HDMI switching(CEC). Reading the forum the Hummy doesn't support it. Very disappointed at the poor support for HDMI switching across the board - a real step backwards from SCART.
2. Thumbnails are poorly configured. The thumbnails seem to be from the very start of the recording. Almost always, this is not the actual program being recorded (I use padding). Ideally I would want to be able to have a config setting for this to say "Use a frame x seconds from the start". I could then set this to be long enough to avoid the padding and short enough to avoid the first ad-break.

I couldn't find much discussion of thumbnails at all on the forum.
Is there any way the custom firmware could override the initial generation of the thumbnail? Is it possible to change the thumbnails after they are created?

 

[Black Hole]

We don't currently have any way to create thumbnails. If you can work out what the graphics format is in the .thm file, it might be possible to do something - but rendering a frame from the video stream might be too much to manage in software on the Humax processor (the Humax itself can grab a frame from the hardware decoder). Possibly it could be off-loaded to a PC, or at least provide the option to upload a suitable graphic.

Update: Over the course of one day, by collaborative effort, a solution has been rolled out in a WebIF update. To cut to the chase, see here: http://hummy.tv/forum/threads/thumbnails-any-configuration.3241/page-3#post-38080

Regarding CEC, this is not simple "HDMI switching", which we might expect to be the ability of a TV to switch inputs to the newest active source. CEC is the ability for devices (eg a DVD player) to be controlled by codes sent across the HDMI via the TV from the TV's remote control. The Humax does not support being controlled via HDMI. There are instances where we suspect the Humax malfunctions when CEC is being sent from the TV, and the advice is to turn off CEC at the TV.

Automatic switching to an HDMI source is a function of the TV, and much less common than automatic switching to a SCART source.

 

[MartinLiddle]

2. Thumbnails are poorly configured. The thumbnails seem to be from the very start of the recording. Almost always, this is not the actual program being recorded (I use padding).

As you have just purchased the box can I suggest you try without padding. Whilst it is a matter of debate I think the majority of users do not use padding because it works pretty well (certainly better than the earlier Humax Freeview boxes).

 

[Black Hole]

Even with AR, the thumbnail frame is rarely pertinent to the recording.

 

[Brian]

Myself, and probably a lot of other owners, would prefer to be able to do away with the thumbnails altogether, as they serve no useful purpose.

 

[Black Hole]

I think we could do that - not actually "do away" with the thumbnail frame, but replace it with a black frame (which would not of course increase the space available for the text or the number of recordings listed per page).

What we need is for someone to get lucky and come across a recording with a black thumbnail (or another usable stock image), and then save it off.

 

[xyz321]

We don't currently have any way to create thumbnails. If you can work out what the graphics format is in the .thm file, it might be possible to do something - but rendering a frame from the video stream might be too much to manage in software on the Humax processor (the Humax itself can grab a frame from the hardware decoder). Possibly it could be off-loaded to a PC, or at least provide the option to upload a suitable graphic.

Still frames can be extracted using something like:

ffmpeg -i test.ts -r 1 -ss 60 -t 5 -f image2 foo-%03d.jpeg

I can't claim the credit for this. I found it a while ago on a forum somewhere.

 

[Trevor Jasper]

Just an idea - as the thumbnail is a grab from the start of the recording, could you use trim to cut the first bit off, and then the Humax will re-generate the thumbnail from the new start?

 

[Black Hole]

Fair point, but not sure whether the Humax process would regenerate a thumbnail for a recording it thinks it has already done.

Update: a self-contained process has been developed for decrypted recordings (see the rest of this topic), but actually there is a process which would achieve the desired effect without decryption or custom firmware - credit MET:

1. Play the recording and press STOP at the point you would like as a thumbnail;
   
   
2. Use FTP to delete the .thm file associated with the recording (this could also be done by exporting the recording to USB and manipulating the file set on the USB drive);
   
   
3. Resume playback - this recreates the missing thumbnail using the frame at the start of playback.

I have a work around. Play the recording and stop just before the point you would like to use as a thumbnail. Use a file explorer or FTP to delete the existing thumbnail. If you then resume play it will create a thumbnail based on where you restarted playback.

NB: We now know that automatic thumbnail generation occurs if a thumbnail (.thm file) does not exist at the time of playback or during housekeeping when entering standby.

 

[Black Hole]

Still frames can be extracted using something like:

ffmpeg -i test.ts -r 1 -ss 60 -t 5 -f image2 foo-%03d.jpeg

Useful. We still need to know how to convert the .jpg to a .thm though. Crack that, and we will be most of the way to a WebIF "load thumbnail from frame at first bookmark" OPT+ button.

 

[af123]

I notice that Raydon's first post about AV2HDR says:

Basically, it enables video not created on the T2, to be imported with all the functionality provided in a native recording. i.e. thumbnails, program synopsis and guidance text, fast forward, rewind, resume from last position etc.

It's possible he knows how to create a .thm file, or he may have just meant that a .thm would be created automatically by the Humax once the other three files were put on.

 

[dragon-it]

The thm file doesn't seem to be any "normal" format looking at it with hex editor, odd choice of theirs! Suppose then logically a roundabout way to get a thm file would be to make a ts cut off with the first frame being the one you want for a thumbnail, or even just a couple of frames altogether, make the other related files, then collect the thm file it creates and swap with the "real" one? I don't suppose you can trigger it to kick off the thumbnail process though?

 

[Ezra Pound]

The thm file doesn't seem to be any "normal" format

It's looking like a raw uncompressed headerless bit map with :-
160 X 91 X 3 (24 bit colour) = 43680 bytes and a ratio of 16:9 roughly
or
a raw uncompressed 480 byte header bit map with :-
160 X 90 X 3 (24 bit colour) + 480 byte header = 43680 bytes and a ratio of 16:9

This doesn't mean I have turned the file into a picture yet ! !

 

[dragon-it]

Yes I was trying that too as there is an amount of symmetry of the bytes in there... now if I could find a few thm files that happened to have recorded an obvious pattern or solid shape, or even a black and white program credits or the like would help but stuck on paid work things at the mo!

 

[dragon-it]

Haven't had a chance to look much but this one from a Fireman sam looks basically black on the tv screen:

 

[af123]

It's looking like a raw uncompressed headerless bit map with :-
160 X 91 X 3 (24 bit colour) = 43680 bytes and a ratio of 16:9 roughly
or
a raw uncompressed 480 byte header bit map with :-
160 X 90 X 3 (24 bit colour) + 480 byte header = 43680 bytes and a ratio of 16:9

This doesn't mean I have turned the file into a picture yet ! !

I tried 160x91x3 on a test .thm and didn't get anything recognisable:



Unfortunate distraction from what I'm supposed to be doing though! : (

 

[dragon-it]

OK so that file having looked quickly is:

00 00 00 FF

the whole way through.... so presumably 4 bytes per pixel RR GG BB + level

Only tool I had to hand here was to replace whole file with one byte so replacing everything with BB and a murky grey shows on telly....

Shouldn't be too difficult to replicate I suppose.

Steve

 

[jxp]

I've done a bit of examination. The .thm files are 32-bit per pixel bitmaps of size 140 x 78.

The files are a raw data file containing the pixel data only (no identifying headers).
The byte sequence is b,g,r,?,b,g,r,? (I think each fourth byte is unused, could be an alpha channel)

 

[Ezra Pound]

Here is something to confirm 140 X 78, this icon - 743_3_11_Video_REC_Fail.png (with the same dimensions) is used for a failed recording :-


EDIT
140 X 78 X 4 (4bytes B+G+R+'FF') = 43680 I can confirm that the first 3 Bytes control BGR and the 4th. Byte remains at 'FF' regardless of picture content

 

[jxp]

Useful. We still need to know how to convert the .jpg to a .thm though. Crack that, and we will be most of the way to a WebIF "load thumbnail from frame at first bookmark" OPT+ button.

Having a quick look at the ffmpeg docs, it seems you can output a frame to a bitmap (not just jpeg) and resize the frame. So that should get us close to producing a true thm file now we know the file format.
Ideally I wanted this to happen automatically, but I don't know how it would work with the default thumbnails. Perhaps they could be generated before the default thumbnail (in which case I guess the default process wouldn't overwrite it). Another option may be to set some sort of attribute on the file so we can tell which is a default thumbnail and which is a custom one.