x264, HDDVD compliance and HRD info patch

[hpn]

I'd like x264 to be better and faster :D

<offtopic>

For a de facto one-man-project it's nothing less than brilliant. How many people are you at ateme working simultaneously on similar projects? /no need to reply/ :D

</offtopic>

[blubberbirne]

I want to test 2pass encoding.

Anyone can post the two avs scripts for 2pass encoding.

thank you

[bond]

I want to test 2pass encoding.

Anyone can post the two avs scripts for 2pass encoding.

thank youhum, i think you need to read up the total basics about encoding very quickly :p

[ArcticFox]

Any reason why when i use the above CLI settings the video plays back super fast?

[Jay Bee]

hum, i think you need to read up the total basics about encoding very quickly :p

Wow, that was helpfull. Would it have taken you more time and effort to post the simple -- answer? I don't know either because I don't use CMD tools. Doesn't automatically mean I'm a complete n00b to video encoding.

[akupenguin]

There is no answer to that question. Which you should know if you've ever done 2pass encoding with any tool, not just on a cmdline.

[Jay Bee]

Don't agree. In vdub you just you just select 1st pass in the first pass and 2nd pass in the second pass. What the exact -- commands are in x264 doesn't seem obvious from that.

[ChronoCross]

Don't agree. In vdub you just you just select 1st pass in the first pass and 2nd pass in the second pass. What the exact -- commands are in x264 doesn't seem obvious from that.

how about --bitrate...I don't think it gets any more basic than that. even in vfw you have to put in a number. Each command in vfw is also similar in name to the command line switch which can be found by doing

x264.exe --help

[akupenguin]

No, the problem is that blubberbirne asked for two avs scripts, which is not how 2pass works. That and it's completely off topic.

[ChronoCross]

heh he made it seem like he was asking 2 questions.

but come on you can use two scripts. As a test to see how far you can throw ratecontrol off. lol

[foxyshadis]

Given how loose first pass's requirements for good rate control are, it's actually pretty easy to get nearly identical distributions from scripts with faster filtering. Replacing mvbob and removenoisemc with tdeint and fft3dfilter can greatly boost the speed of a first pass. Of course, if you have the space lossless is better, but not everyone does. You can also keep the results of the first (or second) pass around for re-encoding with slightly tweaked settings or subtitle scripts.

[blubberbirne]

These x264 build only works with vbr. Try the first pass, and you get a error message that only vbr is supported with the "--nal-hrd" option. Encoding starts, but i don't think, that the stream will be hd-dvd compilant.

But thanks for all the helpfull posting :p

Back to topic please ;)

[check]

Given how loose first pass's requirements for good rate control are, it's actually pretty easy to get nearly identical distributions from scripts with faster filtering.
I don't suppose anyone has any raw data along these lines they could share? It would be interesting to see what sort of efficiency this gives.

[Sagittaire]

news for this patch ... ???

[hpn]

news for this patch ... ???
At least nothing posted to the x264 development list recently.

OT: congrats to foxyshadis fot the fancy new team badge:)

[lexor]

just a question here: now that HD DVD has been decrypted (de-DRMed) is it possible to analyze the bitstream on it? is there a tool for analysis that we can ask those guys over in the muslix64 thread to run? Wouldn't that be a better solution than trying to fit some authoring software that looks like it's buggy itself?

[NanoBot]

Hi Lexor,

if the video is encoded with h.264, you can explore the raw video stream with elecards "streameye". They is a 21 day trial version for download available here:

http://www.elecard.com/products/products-pc/consumer/streameye/

I don't know if a similar program for vc1 exists.

C.U. NanoBot

[bond]

only open issue with this patch according to pengvado:
/* FIXME: I have no idea how you're actually supposed to calculate initial_cpb_removal_delay */

maybe someone can fix this or help the author of the patch...

[Sagittaire]

only open issue with this patch according to pengvado:
/* FIXME: I have no idea how you're actually supposed to calculate initial_cpb_removal_delay */

maybe someone can fix this or help the author of the patch...

Well I think that there are no theorical way to calculate initial_cpb_removal_delay (second) because x264 use another unit with vbv-init * vbv-buffersize (Kbits). You must scan the encoded stream if you want know the real initial_cpb_removal_delay.

Simple solution is to set vbv-init at 0.0 in x264 and in this case initial_cpb_removal_delay will be at 0 second. In this case the first frames will be strictly limited by the max bitrate. It's not a big problem ...

[Sergey A. Sablin]

Well I think that there are no theorical way to calculate initial_cpb_removal_delay (second) because x264 use another unit with vbv-init * vbv-buffersize (Kbits). You must scan the encoded stream if you want know the real initial_cpb_removal_delay.

there is simple way to map bits to time for cbr case, but not for vbr cause fill rate for vbr isn't constant. as devs claim cbr is vbv compliant then this shall work, but as there is no any timing calculation which follow the spec than I don't believe cbr is nearly compliant with h264 spec.

Simple solution is to set vbv-init at 0.0 in x264 and in this case initial_cpb_removal_delay will be at 0 second. In this case the first frames will be strictly limited by the max bitrate. It's not a big problem ...

initial_cpb_removal_delay shalln't be equal to 0 cause this means first picture after it will underflow buffer (cause there is no time to fill buffer).

[Manao]

x264 is always in VBR, it doesn't pad iirc.

[gubbah]

Ian posted an updated version of the patch (http://www.via.ecp.fr/via/ml/x264-devel/2007-01/binRlJ78jLbDT.bin), here is a build (http://x264.net/x264_rev618_HRD.7z).

EDIT: the older 616 patch (build (http://x264.net/x264_rev616_HRD.7z)) is may be better as suggested by Trahald

That link appears to be dead...any mirrors?