HRD patch in latest x264 builds?

[Atak_Snajpera]

Why hdr patch has not been approved and not included in official and less official cef's builds?

I'm asking because in order to create AVCHD (without re-encoding) in Adobe Encore we are forced to use old r675.

[akupenguin]

The HDR patch has not been integrated because no one has stood up and said "I understand the standard (both the H.264 standard and the specification of HD-DVD/AVCHD/Adobe/whatever else needs HRD), and this patch conforms to the standard and fully implements whatever features are needed."
All I have seen is some patch authors saying "I have no idea what you're supposed to do here, lets write some random bits and hope it works". Admittedly is does seem to work, for definitions of "work" restricted to "make the authoring program not reject my stream". But that's not grounds to call the patch correct.

[Atak_Snajpera]

Admittedly is does seem to work, for definitions of "work" restricted to "make the authoring program not reject my stream".
Yes It's working very well on PS3 :)

Another question. Why HDR is required in AVCHD?

[CruNcher]

My Experience with the HRD patch at least on Software (Hardware Decoder) is mixed but the bigest problem i can't test it on a standalone :D
I authored Mini HD-DVDs with it but they don't seem to work correct (dont behave as Retail Mastered HD-DVDs) with all Software Player (Showtime,PowerDVD and Digital Theatre 2) PowerDVD seems to take everything it gets without makeing problems (nice as a consumer player but bad for compliant testing, who knows maybe it also shows it how a real SAP would do), but Showtime and Digital Theatre 2 show me Aspect Ratio and even Resolution errors.
Digital Theatre 2 belives my 1440x1080 mastered Mini HD-DVD is 352x240 and shows it that way :P almost every of those shows a different result (but they all play it and PowerDVD shows it 1A) it's crazy and i can't test on a Standalone yet, it's strange compared with Retail HD-DVDs (that work in all 3 of them correct), so im almost sure it's like a lottery if those HRD Bitstreams (muxed in EVO) work with a real SAP. Mini HD-DVDs mastered with Nero Vision (useing Atemes H.264 Encoder) work in every of those Software Players flawless (except Digital Theatre 2 it crashes with a Mini HD-DVD with Menu Structure).

[akupenguin]

Why HDR is required in AVCHD?
To make authoring more complicated, so people have to buy professional solutions?
HRD isn't useful for anything at all in the context of files on a disc. The information in a HRD packet is useful to the server in a network broadcast scenario. Even then, the server can derive HRD info just as easily as the encoder can, so there's no reason to write the info in the bitstream.

Actually, there's two stupidities involved: the other is that the H.264 standard does not allow a stream to contain a HRD header (which is the mildly interesting information, if your bitrate is less than the max allowed by your level) without also containing HRD packets before every single frame (which is the useless but hard to compute part).

You may ask: if HRD doesn't serve any purpose other than making the authoring program happy, then can't correctness be measured simply by whether the authoring program is happy? No. There are two possible scenarios:
* I'm wrong about HRD and it's actually used for something. Then writing bogus HRD info will break whatever it's used for.
* I'm right and HRD is useless. Then the only correct fix is to patch the authoring programs to not require it. I ruthlessly apply the rule that bug fixes should only go where the bug is, not work around bugs in other programs, so if this turns out to be the case I will reject the HRD patch.

[G_M_C]

[...]The information in a HRD packet is useful to the server in a network broadcast scenario. [...]

Cant that be the reason, and it beeing tied into the DRM-sceme somehow (revoking/accepting keys ?) And/or into the Bluray v2.0 "interactive networking" stuff ? Or maybe in the same order as the DVD-A watermarking kind of encoding ?

/me is guessing wildly, so just judge my guess mildly ;)

[akupenguin]

Bluray v2.0 "interactive networking" stuff ?
No, I meant a non-interactive broadcast. If there is two-way communication between the server and the single client (which is the case if the server is a disc-drive attached to the decoder), then that replaces any need for the HRD info.
tied into the DRM-sceme somehow (revoking/accepting keys ?)
DRM is supposed to prevent you from doing stuff, especially copying. Leaving aside the question of how well that can possibly work, it's hardly compatible with designing a format to make broadcast easy.

[Manao]

As far as I can see, HRD can be used to minimize the latency of the decoder after seeking (it avoids waiting for the whole VBV duration, you just wait for the removal delay before starting to decode). Since HRD data must be taken into account when writing HRD information, it makes sense for the authoring soft to ask for it.

The interest is limited for bluray/HDDVD (since we can presume that the support can read data faster than the 30/40 mbits of the VBV buffer), but for broadcast, it is - I think - useful.

And if we suppose the decoder does use the HRD information, then writing it incorrectly will either create a shortage or a VBV filling, the first one leading to a stutter, the second to a possible crash.

[drmpeg]

The inclusion of HRD info in the blue laser standards is really about the pic_struct syntax element. It's the only way to signal telecine (field or frame repeats), so it's mandatory in HD DVD (since 23.976p content is always telecined to 29.97i) and optional (not required for 23.976 or 24p bitstreams) in Blu-ray. I'm not sure why it's required in AVCHD, although AVCHD does allow telecine for 24p cameras.

For broadcast, the CPB and DPB timing info is included to help out hardware Transport Stream multiplexers and re-multiplexers.

Ron

[akupenguin]

The inclusion of HRD info in the blue laser standards is really about the pic_struct syntax element.
CPB-DPB and pic_struct happen to go in the same SEI packet, but both are optional and neither depends on the other.
Add to that the silliness of requiring telecine to be signaled in the bitstream. If 24p is always telecined, then the decoder can simply infer that 24p is telecined, no need to look. The only case where telecine should be signaled is when the content is variable framerate and you need to specify telecine's phase so the ends match up.
</rant>

[Trahald]

i am with aku on this.. despite the hours and days ive scoured the inet for definitive info, the calcs on the patch are really just best guesses that attempt to mirror results from pro apps. not remotely solid enough to be added to the main branch. and also lack of definitive specs for the HD formats is the other issue. if people werent having success with it, i would probably not even bother.

i'll try to patch a newer x264 soon.. i had system probs.. then cleaned out my hd and am just getting back together again.. the patch with the interlace fix is the latest (i think)

afaik really only hddvd needs the signaling. it took on the same bad 'issue' with that that dvd/mpeg2 does. bluray will take 24fps stuff. but still needs hrd info.

[drmpeg]

i am with aku on this.. despite the hours and days ive scoured the inet for definitive info, the calcs on the patch are really just best guesses that attempt to mirror results from pro apps. not remotely solid enough to be added to the main branch. and also lack of definitive specs for the HD formats is the other issue.
Doesn't the H.264 specification give you the definitive information?

Ron

[Selur]

while at it: does someone have a BluRay profile for MeGui (couldn't find one through the forum search, just a hd-dvd profile)?

[Atak_Snajpera]

Use PS3 profile plus --aud and --nal-hrd

[cacepi]

Doesn't the H.264 specification give you the definitive information?H.264 provides the HRD semantics, but doesn't specify how HD-DVD or Blu-ray implement it: do we need Type I or Type II HRD? With or without byte stream format? How to set 'low_delay_hrd_flag'? And so forth.

There are too many variables to account for, and unless one knows what HD-DVD expects, there's no real way to provide foolproof support. I'd much rather see x264 have no HRD support at all unless it's 100% guaranteed that such support would work with both of the HD formats. Until then I can live with muxing to .mp4

[drmpeg]

H.264 provides the HRD semantics, but doesn't specify how HD-DVD or Blu-ray implement it: do we need Type I or Type II HRD? With or without byte stream format? How to set 'low_delay_hrd_flag'? And so forth.

There are too many variables to account for, and unless one knows what HD-DVD expects, there's no real way to provide foolproof support. I'd much rather see x264 have no HRD support at all unless it's 100% guaranteed that such support would work with both of the HD formats. Until then I can live with muxing to .mp4
But since the encryption has been thwarted, both HD DVD and Blu-ray H.264 bitstreams are available for examination. IMHO, it seems trivial to reverse engineer the parameters/semantics.

Ron

[Trahald]

But since the encryption has been thwarted, both HD DVD and Blu-ray H.264 bitstreams are available for examination. IMHO, it seems trivial to reverse engineer the parameters/semantics.

Ron
well basically what i did was look at a bunch of streams and came up with formulas that got roughly the same results. its sort of complicated by the fact that cinevision with the same settings makes diffrent cpb_removal_delays/dpb_output_delays than mainconcept. even different versions of cinevision make different values. same stream, same parameters. (for telecined streams that is.) For non telecine the values are pretty linear and predictable. the exact calc of initial_cpb_removal_delay is inferred from the avc spec using a max value which seems to work but really should be a tweaked amount offset from the max and change from gop to gop. currently the same max value is used all gops with the patch. the other flags and values are also assumptions from reverse engineered streams. i mean yes.. the likelihood is that the other values used are the only acceptable flags/params and are verifiable with the avc doc especially since the values can only be a 0 or a 1. also .. many of the pro encoders limit b-frames to 2 for hddvd. and 3 for bluray. it can be assumed these are max values for the spec but really w/out seeing it in writing you can never really know.

the patch sorta makes it known its a buyer beware situation. having said that.. i use the patched encoder all the time w/out much worry.

[Trahald]

btw.. i dont have access to 'real' hddvd or bluray clips from a disk.. just what i can make from cinevision.