NAL HRD has been committed!

[MasterNobody]

First of all x264 should be deterministic (i.e. it should always give the identical output for the identical input), unless you explicitely specify the "--non-deterministic" parameter.

And this usually works for me. For example I regularly do bit-by-bit comparison to test different GCC versions with x264.
There are two bugs that cause nondeterministic results in current version (which are locally fixed in next update). Also VBV is inherently nondeterministic (and this is not the bug).

[LoRd_MuldeR]

Good to know that VBV is inherently nondeterministic. If I remember correctly, the x264 developers once said that an application should always be deterministic ;)

However I didn't enable VBV for my tests, so that's probably why it worked for me...

[Dark Shikari]

Good to know that VBV is inherently nondeterministic. If I remember correctly, the x264 developers once said that an application should always be deterministic ;)Except when forcing such determinism would significantly decrease the quality of output...

[kypec]

Except when forcing such determinism would significantly decrease the quality of output...

:confused: Quality or Encoding time only? Pardon my ignorance and lack of knowledge about video encoding but how can determinism decrease quality here?

[Dark Shikari]

:confused: Quality or Encoding time only? Pardon my ignorance and lack of knowledge about video encoding but how can determinism decrease quality here?Because determinism limits the amount of information that each thread can request from the others, since you cannot request any information that isn't deterministic.

[kolak]

Except when forcing such determinism would significantly decrease the quality of output...

This is one of the reasons why x264 has better quality than pro encoders.

[jpsdr]

I want to extract the raw video data stream from an .mts/.m2ts ripped from a blu-ray, to be able to re-use it afterward directly, untouched, in Scenarist.
Is tsmuxer the right tool to do this ?
If yes, is there some specific command line to put to ensure the video data stream will be correct ?
Thanks.

[shon3i]

Use eac3to to get untoched stream, Tsmuxer can rewritte aud's or hrd model

[mp3dom]

Is BD Reauthor Pro/BD Demuxer safe for extract raw streams from M2TS?

[jpsdr]

Use eac3to to get untoched stream, Tsmuxer can rewritte aud's or hrd model

That was the 2nd tool i was thinking about, but as it was first dedicated to audio (as name stated), i didn't know if it was handling properly video stream.

After a quick look at the doc, i assume the command line
will be only :
eac3to File.mts -demux
or is there other parameters, things to do ?

[shon3i]

Is ABR RC ok with VBV? i do some encodes and I am very pleased with the quality/speed ratio, and I had no problems to mux it with scenarist. Everything work flawlessly.

What is progress, when the patch will be commited, is there something we need to test more?

[kolak]

I want to extract the raw video data stream from an .mts/.m2ts ripped from a blu-ray, to be able to re-use it afterward directly, untouched, in Scenarist.
Is tsmuxer the right tool to do this ?
If yes, is there some specific command line to put to ensure the video data stream will be correct ?
Thanks.

None of these tools seams to be very reliable.

Andrew

[jpsdr]

Can someone explain to me, why a 163000 frames 23.976fps file, encoded with the following command line :

1rst pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 1 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC%

2nd pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 2 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC%

Give me a result file of 14.9GB, instead of the 21.5GB expected ????

[G_M_C]

Can someone explain to me, why a 163000 frames 23.976fps file, encoded with the following command line :

1rst pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 1 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC%

2nd pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 2 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile %5 --threads 0 --thread-input --output %E_DST% %E_SRC%

Give me a result file of 14.9GB, instead of the 21.5GB expected ????

Because the encode is bitrate saturated ? At least thats my guess. Others might not agree with me.

x264 reaches its lowest possible qp's (quantizers) at a lower bitrate than you specify. Lower QP-min, or just be satified that x264 is much more efficient then you expected (which is the recommended reaction).

[Fr4nz]

Can someone explain to me, why a 163000 frames 23.976fps file, encoded with the following command line :

1rst pass :
x264_x86.exe --profile "high" --preset "placebo" --tune animation --pass 1 --bitrate 26517 --stats %STAT_FILE% --level "4.1" --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --subme 9 --trellis 1 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709"
--sar 1:1 --qpfile %5 --threads 0 --thread-input --output NUL %E_SRC%
[...]


As a side-note: why you use the following parameters which, in your case, override many "placebo" preset settings (or are totally useless)?

--mvrange 511 --ref 4 --bframe 3 --slices 4 --subme 9 --trellis 1 --me "umh" --aq-mode 2

Read here:
http://forum.doom9.org/showthread.php?t=148149

[shon3i]

Well --slices 4 is not used by any preset ;) so always must be added manualy, and --ref 4 is better for safetly reason, we don't know what is his source i mean 1080/720/576/480, x264 level detector use H264 specs so if you miss something with that high preset you can get 8-16 refs instead 4-6.

[jpsdr]

My source is 1080p. In the 1rst pass, some preset are overrided to speed it up. After, there is some parameters i prefer set manualy, to be sure they stay Blu-Ray compliant, as tuning may modify them, even if it's useless. I prefer safety.
Now, bitrate saturated ? I realy doubt it... I've encoded an 1h video at CBR at 40000mb, because even with this, file still fill on a single layer blu-ray, and result was a 19GB file, as expected. This one should have more reason to be saturated. And it's the first time i'm seeing this. I'll will redo the encoding (almost one day...), in case something unexpected had happened, and remove the shutdown command from my bat file, to see the result output by x264.

[G_M_C]

My source is 1080p. In the 1rst pass, some preset are overrided to speed it up. After, there is some parameters i prefer set manualy, to be sure they stay Blu-Ray compliant, as tuning may modify them, even if it's useless. I prefer safety.
Now, bitrate saturated ? I realy doubt it... I've encoded an 1h video at CBR at 40000mb, because even with this, file still fill on a single layer blu-ray, and result was a 19GB file, as expected. This one should have more reason to be saturated. And it's the first time i'm seeing this. I'll will redo the encoding (almost one day...), in case something unexpected had happened, and remove the shutdown command from my bat file, to see the result output by x264.

Yes look at the avg QP's x264 achieved to code.

But before i go into this further: This tread is used for something else, so this subject is actually off topic.

[kieranrk]

My source is 1080p. In the 1rst pass, some preset are overrided to speed it up. After, there is some parameters i prefer set manualy, to be sure they stay Blu-Ray compliant, as tuning may modify them, even if it's useless. I prefer safety.
Now, bitrate saturated ? I realy doubt it... I've encoded an 1h video at CBR at 40000mb, because even with this, file still fill on a single layer blu-ray, and result was a 19GB file, as expected. This one should have more reason to be saturated. And it's the first time i'm seeing this. I'll will redo the encoding (almost one day...), in case something unexpected had happened, and remove the shutdown command from my bat file, to see the result output by x264.

Use a build with a more recent set of patches. (like JEEBs)

[jpsdr]

In fact, closing this, G_M_C was right. After the 1rst pass, i was having encoded at 19589.
And, in the begining of the 2nd pass, i had a warning : Target 26517, expected 20260 avg qp :10, try lower qp or bitrate.
I'll add --qpmin 0 in my command line. Thanks for the information and the help. This close this off topic.

[Underground78]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)

[Firebird]

Finally :)

[shon3i]

Champagne was opened :D Cheers!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[kolak]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)

Not sure about all rules, but does it mean it's finished?
Where can I find version with patch (finally can compare it with Cinemacraft HD)
Is there a MeGUI version, which works with it?

Andrew

[JEEB]

Not sure about all rules, but does it mean it's finished?
Where can I find version with patch (finally can compare it with Cinemacraft HD)
Is there a MeGUI version, which works with it?

Andrew

Yes, it seems to be finished on a level, and if anyone has bugs they should be reported so that they could be fixed ASAP. Kierank and the guys have made a tremendous effort at keeping to the standards, though, so it should be usable.

I build builds over at x264.fushizen.eu (http://x264.fushizen.eu) , and it seems like MeGUI 0.3.4.0 can take use of it (at some level), as it could take use of the patched 1471s (which, with megapatches, pretty much were the same as the resulting revision). I haven't tested MeGUI with nal-hrd usage lately, though. So I have no idea if they've updated their things. I would guess that they've updated it, since it has been quite some time that the patch has been around.

Edit:
Jarod, of course, should also get done with the 32bit build at x264.nl at some point as well.

[Zathor]

Is there a MeGUI version, which works with it?
The latest development version should work with it. You have to replace x264.exe and x264_64.exe with the new ones.

[JEEB]

The latest development version should work with it. You have to replace x264.exe and x264_64.exe with the new ones.

And here we have the answer to the question, great job at keeping the application up-to-date.

[mp3dom]

Great work and great results! :) Thanks to all the developers.

[kolak]

The latest development version should work with it. You have to replace x264.exe and x264_64.exe with the new ones.

Thanks- will report my findings about quality (compared to PRO encoders) and compatibility.
Are there any advantages to use 64bit version on WinXP with 6GB of RAM?

[MadMonkey57]

Congratulations and Thanks to ALL OF YOU guys !

[shon3i]

Where can I find version with patch (finally can compare it with Cinemacraft HD)What you need to test more, that not allready tested/proven many times before, now we have officialy one more switch which not affect on quality, just add support for devices.

I now run encode, to see what verificators say :) I have access to Sony Verifier 1.3 again and i have new BDQuest 1.3.2 which have all comformace bugs fixed.

[LoRd_MuldeR]

Are there any advantages to use 64bit version on WinXP with 6GB of RAM?

The 64-Bit version should give ~10% speed-up. And you cannot run into the 2 GB per-process memory limit. The latter probably is only an issue with insane settings.

However be aware that you'll need 64-Bit Avisynth, if you want to use Avisynth input with 64-Bit x264. And you'll need the "x64 Edition" of WinXP, which is only available as OEM version!

[kolak]

What you need to test more, that not allready tested/proven many times before, now we have officialy one more switch which not affect on quality, just add support for devices.

I now run encode, to see what verificators say :) I have access to Sony Verifier 1.3 again and i have new BDQuest 1.3.2 which have all comformace bugs fixed.

Haven't seen anyone testing it against Cinemaraft HD, did you?
Blu-code was very close to x264 (bit less sharp), but CC-HDe is yet another league, so there is something to test.

[laserfan]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)
Am I the only one who's a little bit dizzy in noting that we've gone from 1471 to 1510 (not sure how that happens)!?

I mean, the Criterion evaluation appears to be back at 1480, now all-of-a-sudden we have 1510 and with a lot of names associated with the versions that I've not seen often.

I'm clueless tho about how stuff gets "committed" and maybe there is lots of testing that the rest of us don't see....

[LoRd_MuldeR]

Am I the only one who's a little bit dizzy in noting that we've gone from 1471 to 1510 (not sure how that happens)!?

I mean, the Criterion evaluation appears to be back at 1480, now all-of-a-sudden we have 1510 and with a lot of names associated with the versions that I've not seen often.

I'm clueless tho about how stuff gets "committed" and maybe there is lots of testing that the rest of us don't see....

That's how Git works. In contrast to the client/sever-based SVN or CVS, Git is organized in a decentralized way. It doesn't distinguish between "local" and "remote" repositories.

So you can commit your changes "locally" (into your own local Git repository), but they won't appear on the public server, until the pending changes are merged into the "remote" repository.

Obviously the devs hold back their local changes until they feel they are ready for a broader audience. Then a bunch of changes is merged into the public repository at once...

[dstln]

Recently they've been taking longer between commits, likely for testing/stability reasons. Not sure if it's more of a fundamental change to only release more stable code or just how it's happened to occur recently, but either way it doesn't matter too much.

[kieranrk]

Recently they've been taking longer between commits, likely for testing/stability reasons. Not sure if it's more of a fundamental change to only release more stable code or just how it's happened to occur recently, but either way it doesn't matter too much.

Because the commits have been huge patches where a lot of user testing was necessary. (lavf/ffms input and nal-hrd)

Sod's law also states that there will now be countless bugreports

[julius666]

However be aware that you'll need 64-Bit Avisynth, if you want to use Avisynth input with 64-Bit x264.

Or use avs2yuv to pipe the videostream from the 32 bit avisynth to the 64 bit x264.

[laserfan]

That's how Git works... Obviously the devs hold back their local changes until they feel they are ready for a broader audience. Then a bunch of changes is merged into the public repository at once...Thanks I appreciate your reply and look forward to trying 1510. :)

[Lyris]

Thank you so much and congratulations. I am in awe of the people who can make this sort of thing happen. I look forward to using the best quality AVC encoder in the world on Blu-ray Discs.

Now I just have to hope that we can find a nice master :)

[Revgen]

Commit : Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505)

Why are some of the features missing in x264cli?

Will this be fixed soon?

[Dark Shikari]

Why are some of the features missing in x264cli?

Will this be fixed soon?Which features?

[Revgen]

libx264 now returns HRD timing information to the caller in the form of an x264_hrd_t.

x264cli doesn't currently use it, but this information is critical for compliant TS muxing.

^This.

Pulldown support: libx264 allows the calling application to specify a pulldown mode for each frame.

This is similar to the way that RFFs (Repeat Field Flags) work in MPEG-2.

Note that libx264 does not modify timestamps: it assumes the calling application has set timestamps correctly for pulldown!

x264cli contains an example implementation of caller-side pulldown code.

^And This.

[Dark Shikari]

^This.x264cli doesn't use it because x264cli doesn't need it. It's not a missing feature.

[Revgen]

^Ahh, thanks for clarifying.

[G_M_C]

Brilliant, another milestone for x264 :cool:

:thanks: and cuda's for all who made this possible !

And on a sidenote:
I find x264 a great example on how an open source model can be used by many different people and companies. Both have their own wishes, and their own motivations. But if you sponsor some feature, or if you actually code a feature; it all becomes part of this greater good.

x264 becomes better and better, and has quite possible become the best h264 encoder around, all because of this Open Source model imho.

Super isn't it :).

[Atak_Snajpera]

x264 becomes better and better, and has quite possible become the best h264 encoder around, all because of this Open Source model imho.
I'm not afraid to say that it is already the best video encoder at the moment.

[G_M_C]

I'm not afraid to say that it is already the best video encoder at the moment.

I haven't tested them all, and there are sure to be people pointing to whatever comparison to say it's not (for whatever motivation). So i'd thought I circumvent that swampy area of discussion :p

But I'd agree on that

[Firebird]

I'm not afraid to say that it is already the best video encoder at the moment.

And i think it would be best for at least next 3 years.I mean, seriously, the only encoder that can beat it in feature is x265 :D

[Lyris]

If I thought there was an AVC encoder (at least within my reach) producing better quality results than x264, I would have used it instead of wishing for BD compliance :)

The fact that it's free and open source is the icing on the cake!