What does ENC mean on my SD recording?
- Thread starter Kirbett
- Start date
Thanks.
Black Hole
May contain traces of nut
I only mentioned it because newbies might have found it confusing.
Absolutely. The subject is confusing enough as it is without me adding more by mistake!
I noted your earlier comment on the need to update the documentation when we finally get to the bottom of this. I'm happy to help if I can. Regards.
All is not lost. I've just uploaded an update to the sidecar utility which parses this Content Management metadata from the saved .ts file so you can now check any suspect recordings retrospectively. See the main sidecar thread HERE for details.
Black Hole
May contain traces of nut
The wiki I will leave to others; I was referring to my Things Every... etc (particularly the guide to decryption) which currently state that only HiDef recordings have the ENC property.
Yes, as af123 has already determined.
Yes, as I have since determined using the latest sidecar implementation.
Extremely unlikely, as this metadata is defined in standard ETSI EN 300 468, and yes, I they would rely on the EPG (or the EIT as it actually is) to carry it.
The broadcast transmission stream for neither HD, or SD is scrambled. It is only Freeview license that requires the PVR to scramble HD content on receipt.
Correct, see the hmt format in the wiki for a full breakdown.
I believe it is becoming increasingly evident that they do carry the same value. It would appear that in the current situation, it is the broadcaster (BBC) who is now incorrectly setting the content management metadata, instructing the PVR to scramble the content of some selected SD broadcasts.
Last edited:
FYI My recording of Shrek last night has the 0x28E OnDiskEncrypted flag set to Decrypted, and the 0x3DC Encrypted flag set to Encrypted, resulting in both 'Dec' and 'Enc' icons being displayed in the webif media browser. Manually correcting the hmt file to enable Opt+/Decrypt was insufficient to achieve a good decryption, and only resulted in a garbage file. So it would seem the DLNA database is also being set to protect these SD recordings. Had to re-install auto-unprotect before I finally got a good decryption.
4ndy
Member
Could the implementation of Freeview Play have given rise to new agreements?
Freeview, Freeview Plus, Youview and now Freeview Play
all use the same broadcast data.
Shrek the Third seems the odd one out as it has been shown by the BBC several times, including, I think, last Christmas.
Sent from my GT-I9505 using Tapatalk
Freeview, Freeview Plus, Youview and now Freeview Play
all use the same broadcast data.
Shrek the Third seems the odd one out as it has been shown by the BBC several times, including, I think, last Christmas.
Sent from my GT-I9505 using Tapatalk
Black Hole
May contain traces of nut
It crosses my mind that whatever undertaking may have been made in the past, the rights holders of material that the BBC (or whoever) wants to broadcast have the upper hand and may impose their own requirements.
As I read it, the Humax software's behaviour in the face of seeing do_not_scramble=0 is correct as per the D-book.
However, in the same section of the D-book, it states:
Black Hole
May contain traces of nut
...and what if the rights holder says "you can't have my content unless you set the protection bit"?
The BBC's response to the Digital UK consultation of May 2013 also makes interesting reading:
http://www.digitaluk.co.uk/__data/a...e_to_Digital_UK_HD_consultation_June_2013.pdf
This leads one to wonder whether their motivation for the apparent changes in their handling of EPG information is less to do with a desire to protect the SD content, than it is to strengthen the 'nudge' they give to people to switch from the SD to the HD channel of the simulcast. After all, there's far more mileage to be gained by moving people on to the HD channel where they can be more easily kept in line, than by chasing an SD horse that has long since bolted. The BBC makes no bones about it's desire to do this. They even go so far as to advocate automatic re-allocation of the LCN of the SD channel by its HD equivalent. I find it easy to imagine that the commoning up of the EPG entries for the two sides of the simulcast would be an implementation fall-out from such a strategy.
On a more practical note, thanks to all who have helped enlighten me on the technical aspects of all this. And apologies for the low signal to noise ratio of my postings.
prpr
Well-Known Member
That table only applies to HD content. The column you snipped tells you the rules for SD.
But I said that back in post #69...
Thanks for your earlier full and helpful response. Your hmt format document has been my bible for the last few years!
May I take up one small point, however. Your revised wording for 0x3DC states:
'Encrypted' flag. 1 = Decryption allowed. Determines if decryption on copy to USB is allowed.
I wonder whether your wording might give some people (aka me) the wrong impression - at least if I now understand things properly. Am I right in thinking that this flag says nothing about the current state of encryption of the recording (that is covered by the flag at 0x28E). Nor, strictly speaking, does it indicate whether decrypting is allowed. I now think it's probably a faithful map of the spec (as provided by af123 above) i.e. it describes what state the recording must be in before it leaves the box. I'm sure this reads like nit-picking, but there is a subtle difference: a difference that makes it totally reasonable (if inconvenient!) for a recording to show both the Enc and Dec icons at the same time. (As af123 has also already pointed out, these confusion problems arise from the choice of the 'Enc' icon by Humax to indicate a recording that will have to be encrypted [in certain circumstances] rather than one that currently is encrypted.)
All recordings, (both HD and SD) when first written to the hard disk are encrypted, and the On-disk encrypted flag at 0x28E should always initially be set to one.
When the flag at 0x3DC is set to zero there will be an 'Enc' icon beside the recording in the HDR's own Media Browser.
In this state, decryption on copy to USB is not allowed.
This is the norm for HD recordings.
When the flag at 0x3DC is set to one there will not be an 'Enc' icon beside the recording in the HDR's own media browser.
In this state, decryption on copy to USB is allowed.
Until recently this was the norm for SD recordings.
When the recording is copied to a USB drive (or pseudo USB drive) it will be decrypted as it copies, and on completion the On-disk encrypted flag at 0x28E will be set to zero in the copied hmt only. The original hmt on the hard disk will remain unaltered, as will the original encrypted .ts file.
So yes, strictly speaking, 0x3DC does indicate whether decrypting is allowed. It is by changing this flag on HD recordings that a decrypt on copy to USB is enabled. That's all the 'Foxy' utility does.
There should never be an occasion when you get both ox28e and 0x3DC flags set to zero because decryption has been disallowed, yet the On-disk decrypted flag is saying (incorrectly) that the recording has been decrypted.
Please note: I have not mentioned the subject of modifying flags in the DLNA database to enable decryption via streaming as that has no bearing on the interpretation of the hmt format, although the 0x3DC flag does need to be set correctly for this method to work.
Last edited:
MontysEvilTwin
Well-Known Member
This confused me slightly as auto-unprotect sets the value at 0x3DC to 04, not 01. Either value clears the 'Enc' flag in the Humax media browser. If 03xDC is set to 02 or 03 you get the Enc flag and the no copy icon (if 0x431 = 00). Values at 03xDC of 05 or higher also give the Enc flag (I have checked up to 10 in hex: 05 to 09 and 0a to 10).
Sorry for the confusion Monty. A flag is contained in a single bit so for 'flag' read 'flag bit'. I was referring to the binary value in bit two not the whole byte, which actually contains two known flag bits in bits one and two. So, valid byte values can only be 0,2,4, or 6.
Bit one is 00000010 in binary, or 2 in decimal and holds the the 'Copy Limited' flag.
Bit two is 00000100 in binary, or 4 in decimal, and holds what we now know to be a copy of the 'do_not_scramble' flag transmitted in the FTA_content_management_descriptor of the EIT (Event Information Table). It was originally describeded by me as the 'Encrypted' flag simply because of the 'Enc' icon it displays in the HDR's Media Browser. If it would help to avoid any confusion I could always rename it to 'do_not_scramble' in the HMT format description in the wiki.
Last edited:
Raydon, thanks for your full response - and apologies for putting you to so much trouble. I was familiar with all that - despite appearances to the contrary (!). But I do admit to taking a step too far in drawing the specific conclusion about the possible legitimacy of the Enc/Dec combination. Sorry.
Thanks too for your improvements to the sidecar utility. As it happens, I did manage to recover the (unprocessed) originals of the three Enc-marked SD recordings from my off-box back-ups. These allowed me to belatedly test the point upon which I had speculated - and got wrong!
I think I've now resolved all the problems I need to for my own operational purposes. But I think there are a couple of 'discussion' issues that others have raised that I think are still not fully addressed. But I may be in a minority of one, and am happy to let them lie.
a) For those who think the BBC's motives in taking this step are part of a strategy to enforce SD encryption, I repeat my suggestion to read their response to the 2013 Digital UK consultationIt is very short, very understandable and very explicit. With their charter currently under review it is far more important, and urgent, to them to show that there is a growing move to HD than it is to retrospectively enforce SD encryption. I strongly suspect that the inclusion of hitherto HD-specific information in the EPG is a by-product of an ongoing move to position SD as a technical downgrade of the HD service rather than as a service with a viable long term future in its own right.
b) The fact that the Humax uses the 'Enc' icon to indicate content that must be encrypted [in certain circumstances], and that it automatically encrypts every transmission upon receipt, means that a standard defined in terms of 'when to encrypt' becomes an implementation defined in terms of 'when to decrypt'. I repeat that it's a subtle distinction, but it does create an 'implementation-defined hole' down which I, at least, fell.
Thanks again.
Thanks too for your improvements to the sidecar utility. As it happens, I did manage to recover the (unprocessed) originals of the three Enc-marked SD recordings from my off-box back-ups. These allowed me to belatedly test the point upon which I had speculated - and got wrong!
I think I've now resolved all the problems I need to for my own operational purposes. But I think there are a couple of 'discussion' issues that others have raised that I think are still not fully addressed. But I may be in a minority of one, and am happy to let them lie.
a) For those who think the BBC's motives in taking this step are part of a strategy to enforce SD encryption, I repeat my suggestion to read their response to the 2013 Digital UK consultationIt is very short, very understandable and very explicit. With their charter currently under review it is far more important, and urgent, to them to show that there is a growing move to HD than it is to retrospectively enforce SD encryption. I strongly suspect that the inclusion of hitherto HD-specific information in the EPG is a by-product of an ongoing move to position SD as a technical downgrade of the HD service rather than as a service with a viable long term future in its own right.
b) The fact that the Humax uses the 'Enc' icon to indicate content that must be encrypted [in certain circumstances], and that it automatically encrypts every transmission upon receipt, means that a standard defined in terms of 'when to encrypt' becomes an implementation defined in terms of 'when to decrypt'. I repeat that it's a subtle distinction, but it does create an 'implementation-defined hole' down which I, at least, fell.
Thanks again.
I wonder if the two low order bits actually correspond to the control_remote_access_over_internet field in the descriptor? In particular, the standard says that if this field is non-zero in conjunction with do_not_scramble=0 then:
I can't think of any way of testing this though.