View Full Version : NAL HRD has been committed!
Pages :
[
1]
2
3
4
5
6
7
8
9
10
11
12
13
kieranrk
16th January 2010, 18:58
Patch has now been committed.
Features
Writing of pic_timing and buffering_period SEI units as required by Blu-Ray etc.
libx264 returns hrd timing information. This means muxers don't have to parse the bitstream to utilise this information (new)
CBR (filler rbsp) and VBR HRD
Valid support for pulldown
VFR VBV and VFR ratecontrol
sneaker_ger
16th January 2010, 19:09
"pthreadGC2.dll not found" on start even with standard settings. Windows XP SP3.
bnshrdr
16th January 2010, 19:31
"pthreadGC2.dll not found" on start even with standard settings. Windows XP SP3.
You will need to either obtain the specified pthread dll or use the patch to compile your own static x264 build. The OP hast just provided a x264 build with that dependency.
@kieranrk: Also what else is in your binary, just vanilla + your patch?
moviefan
16th January 2010, 19:47
What is the difference of this patch to the x264_hrd_interlace_xxxx.diff?
sneaker_ger
16th January 2010, 19:49
Thx, works now. (Get pthreadGC2.dll (ftp://sourceware.org/pub/pthreads-win32/dll-latest/lib/pthreadGC2.dll) here, if anyone else needs it)
shon3i
16th January 2010, 20:02
What is the difference of this patch to the x264_hrd_interlace_xxxx.diff?
and
1. Who is author
2. Did this patch are completly different to Alex or Trahald
3. Did you work for x264 team? i mean did this after some testing get finaly into git. I won't give my feedback if this is another try. I want to know if this is for merging into git.
4. please somebody do a normal compile
kieranrk
16th January 2010, 20:18
What is the difference of this patch to the x264_hrd_interlace_xxxx.diff?
Cleaned up and minor things fixed up.
1. Who is author
2. Did this patch are completly different to Alex or Trahald
3. Did you work for x264 team? i mean did this after some testing get finaly into git. I won't give my feedback if this is another try. I want to know if this is for merging into git.
4. please somebody do a normal compile
1/2 - Zmgorynych == Alex Giladi. I added the hrd timing parts.
3. Yes. Yes this is for merging into git. Alex isn't going to be around much so I'm going to push to get this patch merged.
4. Sorry about that. EDIT: new one should be static.
@kieranrk: Also what else is in your binary, just vanilla + your patch?
Yes. Just vanilla and the patch.
sneaker_ger
16th January 2010, 21:03
New build works fine without the dll. Two typos in the help:
--nal-hrd, Signal HRD information (needed e.g. for blu-ray compliance
requires vbv-maxrate and vbv-bufsize
1. ","
2. missing ")"
VFR maniac
17th January 2010, 09:35
Hi Kieranrk, your patch doesn't write Buffering Period SEI unless the muxer is raw.
shon3i
19th January 2010, 01:06
Ok, patch working corectly, muxing passes, BD verification passes. What we need to test more?
kieranrk
19th January 2010, 01:31
Ok, patch working corectly, muxing passes, BD verification passes. What we need to test more?
I've changed it a bit now, fixed some bugs and am adding CBR HRD. Possibly this might have introduced a bug so I'll upload a new patch either tonight or tomorrow.
komisar
21st January 2010, 16:13
kieranrk, build 1400 version of x264 with you patch get failure...
checkasm report:x264: SSSE3
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel var2 : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- sub_dct4 : [OK]
- sub_dct8 : [OK]
- add_idct4 : [OK]
- zigzag_frame : [OK]
- zigzag_field : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
predict_16x16[3] : [FAILED]
30 69 9d 71 4d 5d 71 a0 c4 b1 8d 86 a0 af 9e ae cf
4e 51 57 5d 62 68 6e 74 7a 80 86 8c 92 98 9e a3 a9
8f 58 5e 64 6a 70 76 7c 81 87 8d 93 99 9f a5 ab b1
85 5f 65 6b 71 77 7d 83 89 8f 95 9b a0 a6 ac b2 b8
37 67 6d 73 79 7e 84 8a 90 96 9c a2 a8 ae b4 b9 bf
2d 6e 74 7a 80 86 8c 92 97 9d a3 a9 af b5 bb c1 c7
70 75 7b 81 87 8d 93 99 9f a5 ab b1 b6 bc c2 c8 ce
87 7d 83 89 8f 94 9a a0 a6 ac b2 b8 be c4 ca d0 d5
5d 84 8a 90 96 9c a2 a8 ae b3 b9 bf c5 cb d1 d7 dd
0 8c 91 97 9d a3 a9 af b5 bb c1 c7 cc d2 d8 de e4
0 93 99 9f a5 aa b0 b6 bc c2 c8 ce d4 da e0 e6 eb
1 9a a0 a6 ac b2 b8 be c4 c9 cf d5 db e1 e7 ed f3
0 a2 a7 ad b3 b9 bf c5 cb d1 d7 dd e3 e8 ee f4 fa
0 a9 af b5 bb c1 c6 cc d2 d8 de e4 ea f0 f6 fc ff
0 b0 b6 bc c2 c8 ce d4 da df e5 eb f1 f7 fd ff ff
0 b8 bd c3 c9 cf d5 db e1 e7 ed f3 f9 fe ff ff ff
0 bf c5 cb d1 d7 dc e2 e8 ee f4 fa ff ff ff ff ff
4b 52 59 5f 66 6d 73 7a 81 88 8e 95 9c a2 a9 b0
52 59 60 67 6d 74 7b 81 88 8f 96 9c a3 aa b0 b7
5a 60 67 6e 75 7b 82 89 90 96 9d a4 aa b1 b8 bf
61 68 6f 75 7c 83 89 90 97 9e a4 ab b2 b8 bf c6
68 6f 76 7d 83 8a 91 97 9e a5 ac b2 b9 c0 c7 cd
70 77 7d 84 8b 91 98 9f a6 ac b3 ba c0 c7 ce d5
77 7e 85 8b 92 99 9f a6 ad b4 ba c1 c8 ce d5 dc
7e 85 8c 93 99 a0 a7 ae b4 bb c2 c8 cf d6 dd e3
86 8d 93 9a a1 a7 ae b5 bc c2 c9 d0 d6 dd e4 eb
8d 94 9b a1 a8 af b5 bc c3 ca d0 d7 de e5 eb f2
95 9b a2 a9 af b6 bd c4 ca d1 d8 de e5 ec f3 f9
9c a3 a9 b0 b7 bd c4 cb d2 d8 df e6 ec f3 fa ff
a3 aa b1 b7 be c5 cc d2 d9 e0 e6 ed f4 fb ff ff
ab b1 b8 bf c5 cc d3 da e0 e7 ee f4 fb ff ff ff
b2 b9 bf c6 cd d3 da e1 e8 ee f5 fc ff ff ff ff
b9 c0 c7 cd d4 db e2 e8 ef f6 fc ff ff ff ff ff
- intra pred : [FAILED]
- quant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]
P.S. huh, maybe this is not nal-hrd-patch... investigation continues...
P.P.S. apparently I broke intel-support patch... sorry...
kieranrk
26th January 2010, 03:23
Please test this new revision to make sure I haven't broke anything.
There are a few things left and it should be ready for final review.
shon3i
27th January 2010, 00:06
I just successfully produced two Blu-ray movies ;). Tell me about CBR-HRD what is recommendation for ratecontrol? With CRF i can't specify bitrate, is it only for ABR and 2pass, and what is advantage of CBR instead VBR HRD
Dark Shikari
27th January 2010, 00:30
I just successfully produced two Blu-ray movies ;). Tell me about CBR-HRD what is recommendation for ratecontrol? With CRF i can't specify bitrate, is it only for ABR and 2pass, and what is advantage of CBR instead VBR HRDCBR HRD implies filler bytes; it is not necessary or recommended for Blu-ray.
mopurist
29th January 2010, 17:50
When I try http://pastebin.com/d51413f02 pastebin says "Unknown post id, it may have expired or been deleted."
Is there a new version about? Merged into git? Anyone care to share?
Thanks.
kieranrk
29th January 2010, 23:59
When I try http://pastebin.com/d51413f02 pastebin says "Unknown post id, it may have expired or been deleted."
Is there a new version about? Merged into git? Anyone care to share?
Thanks.
I probably set the expiration date too soon.
See: http://pastebin.com/m44061f19
(some minor changes)
VFR maniac
30th January 2010, 00:23
http://pastebin.com/m44061f19
bs_realign is missing...
mp3dom
30th January 2010, 01:09
I don't know which BD verifier were used by shon3i, anyway I've made an encode with x264+1.1 NAL-HRD (the version at the 1st post) on the Elephant's Dream video. Using the Interra BDQuest Verifier it gave me 3 fatal errors. I must say that Scenarist MUI Generator (and Scenarist itself) accepts and mux without problems.
I've activated the --nal-hrd, --slices 4 and --aud, fps were 24p and resolution were 1920x1080 (obviously)
The error output of BDQuest says:
- 'pict_struct_present_flag', expected (1), found (0)
- Compression Ratio (CR) is less than MinCR (4). Number of bytes in NAL unit (1096693) is more than the maximum limit (983040)
- 'slice_type' in 'I Type' picture must be (7), found (2)
Regarding the first error (pict_struct_present_flag) I've see that in this x264 version there's a specific flag (--pict-struct) that is enabled by default for interlaced footage... Could be that it is mandatory for bluray?
I've got 8 errors regarding the "Compression Ratio (CR) is less than etc. etc. etc.". In every error the NAL unit value change and it's value is always bigger than the maximum limit of 983040.
About the third error, I want to say that this error appear even on encodes made by CineVision or the Scenarist Still Image Encoder. I think that this error could be ignored...
Hope this helps!
Thanks!
kieranrk
30th January 2010, 01:29
bs_realign is missing...
Forgot about that. Will post a corrected one.
Regarding the first error (pict_struct_present_flag) I've see that in this x264 version there's a specific flag (--pict-struct) that is enabled by default for interlaced footage... Could be that it is mandatory for bluray?
Presumably so. (See the spec ;) )
I've got 8 errors regarding the "Compression Ratio (CR) is less than etc. etc. etc.". In every error the NAL unit value change and it's value is always bigger than the maximum limit of 983040.
Not sure about this one; I'm double checking the H.264 spec about this. Try with the new patch and build I will post in a second to double check it isn't related to the bitstream issues.
shon3i
30th January 2010, 01:42
I don't know which BD verifier were used by shon3iI have both Sony and Interra, but last time i didn't checked with verifier :) so maybe is problem something with patch 1.1. I will test now with 1.2.
And about MinCR from specs:
Minimum compression ratio (MinCR) (Note) for Main profile and the equivalent constraint for High
profile shall be restricted as follows;
�� For Main profile level 4.1, MinCR=4 for movie stream, MinCR=2 for still picture
�� For High profile level 4.1, the same semantic constraint as described above shall be applied.
�� For other levels of High profile, the same semantic constraint on MinCR for Main profile shall
be applied.
(Note): The semantic constraint on MinCR for Main profile is described in Annex A of the ISO/IEC
14496-10[11].
btw here is about for pict_struct_present_flag
• pic_struct (in Picture timing SEI) shall be present if frame_mbs_only_flag in SPS is set to 0.
pic_struct_present_flag shall be set to 1 to satisfy this restriction.
Btw so we always must use --pict-struct ? is this something changed, because earler version don't have this command and stream came out with this assumed. I think, this should be always on since is mandatory for Blu-Ray
kieranrk
30th January 2010, 02:03
btw here is about for pict_struct_present_flag
..
Btw so we always must use --pict-struct ? is this something changed, because earler version don't have this command and stream came out with this assumed.
In progressive mode we set frame_mbs_only_flag to 1 so pic_struct is not necessary.
In the past pic_struct was on automatically with interlaced. Now it only turns on automatically if you use pulldown. I've changed it to be on in interlaced mode.
About the third error, I want to say that this error appear even on encodes made by CineVision or the Scenarist Still Image Encoder. I think that this error could be ignored...
Yes that error is wrong. The first one is also wrong. Dark Shikari also tried that verifier a while ago and it kept claiming things that were clearly not true.
mp3dom
30th January 2010, 19:49
With 1.21 patch the problem of "Compression Ratio (CR) is less than MinCR(4)... bytes in NAL unit (xxx) more than maximum limit etc etc" still persist.
kolak
30th January 2010, 20:27
I don't know which BD verifier were used by shon3i, anyway I've made an encode with x264+1.1 NAL-HRD (the version at the 1st post) on the Elephant's Dream video. Using the Interra BDQuest Verifier it gave me 3 fatal errors. I must say that Scenarist MUI Generator (and Scenarist itself) accepts and mux without problems.
I've activated the --nal-hrd, --slices 4 and --aud, fps were 24p and resolution were 1920x1080 (obviously)
The error output of BDQuest says:
- 'pict_struct_present_flag', expected (1), found (0)
- Compression Ratio (CR) is less than MinCR (4). Number of bytes in NAL unit (1096693) is more than the maximum limit (983040)
- 'slice_type' in 'I Type' picture must be (7), found (2)
Regarding the first error (pict_struct_present_flag) I've see that in this x264 version there's a specific flag (--pict-struct) that is enabled by default for interlaced footage... Could be that it is mandatory for bluray?
I've got 8 errors regarding the "Compression Ratio (CR) is less than etc. etc. etc.". In every error the NAL unit value change and it's value is always bigger than the maximum limit of 983040.
About the third error, I want to say that this error appear even on encodes made by CineVision or the Scenarist Still Image Encoder. I think that this error could be ignored...
Hope this helps!
Thanks!
3rd error seams to be Interra verifier bug- it's also reported on Cinevision and Blu-code streams.
Does Sony verifier show the same?
MUI generator does very basic checks- it can't be used to verify compliance- way not good enough.
mp3dom
30th January 2010, 20:43
We only have the Interra verifier and don't have the Sony. I'm more "worried" about the second (Compression Ratio) since with the CineVision encodes that error doesn't show.
moviefan
30th January 2010, 20:59
MUI generator does very basic checks- it can't be used to verify compliance- way not good enough.
Does that mean that the x264_hrd_interlace patch might be broken too? It passed MUI Generator and thus I thought it produces BD compliant steams.
mp3dom
30th January 2010, 21:12
Like kolak says, the MUI generator made only a basic check and it's not reliable. Only the verifier (and not all of them, like you can see :)) can validate a stream as 100% BD compliant. Also the mastering factory have it's own verifier (before pressing the BD). Don't know if it's 100% reliable, but the EclipseSuite BD it's renowned to be very strict about specs.
shon3i
30th January 2010, 21:25
Does Sony verifier show the same?I can test, but not until next week, because i am on short vacation, and i don't have access to BD Verifier on my work.
Does that mean that the x264_hrd_interlace patch might be broken too? I don't think so, muxing stage do other checks like VBV and HRD VBV, so broken HRD will affect on muxing. I saw many streams which not pass muxing in scenarist even some are demuxed from original titles.
Anyway did we sure that many DVD's today are 100% DVD compilant, and now many broken streams work on most standalones :)
I want to say both Verifiers maybe are not good and have bugs ;)
kolak
30th January 2010, 23:09
I can test, but not until next week, because i am on short vacation, and i don't have access to BD Verifier on my work.
I don't think so, muxing stage do other checks like VBV and HRD VBV, so broken HRD will affect on muxing. I saw many streams which not pass muxing in scenarist even some are demuxed from original titles.
Anyway did we sure that many DVD's today are 100% DVD compilant, and now many broken streams work on most standalones :)
I want to say both Verifiers maybe are not good and have bugs ;)
There are lots DVDs, which are out of DVD spec, but mainly because of lack of knowledge or because some people just don't care. It's also because there are many DVD authoring softwares which don't produce fully compliant projects and again even if authors know about it, they just don't care (because client doesn't care and wants everything as cheap as possible). There are also many well authored DVDs, which don't work on some players, because these players (even if they have official DVD-Video logo on them) never went through any compatibility checks or test. These players should not be on the market or at least they should not have DVD logo- it's kind of crime :)
Interra verifier is not very reliable (there are still many missing features). Sony verifier is an "old" software and way more reliable, so it's the best to use this one to check x264 streams.
rack04
30th January 2010, 23:26
Version 1.21 does not patch correctly the latest git. I get 6 failed hunks.
kieranrk
31st January 2010, 02:32
Version 1.21 does not patch correctly the latest git. I get 6 failed hunks.
I'll upload the fixed patch in a few minutes.
Emulgator
31st January 2010, 13:16
BTW: Sony Vegas 9.0c MPEG-4 Encoder .avc outputs pic_struct_present =1.
http://doom10.org/index.php?topic=7.0
Post 18, last screenshot. (Sony Vegas Header SPS bottom)
shon3i
31st January 2010, 13:29
BTW: Sony Vegas 9.0c MPEG-4 Encoder .avc outputs pic_struct_present =1.
http://doom10.org/index.php?topic=7.0
Post 18, last screenshot. (Sony Vegas Header SPS bottom)
In bd specs clearly stay "pic_struct (in Picture timing SEI) shall be present if frame_mbs_only_flag in SPS is set to 0", frame_mbs_only is 1 for progressive encodes.
kieranrk
31st January 2010, 13:52
Just use --pic-struct if for whatever reason the program you use wants it.
mp3dom
31st January 2010, 14:00
Correct me if I'm wrong: the 'picture structure' field could have different values for what I've read... like (i.e., dunno if it's wrong or not, i don't have the specs) 3 for TFF or 4 for BFF. In case of a progressive encode the --pic-struct parameter write 1?
Latest question: the 1.22 patch tries in some way to fix the 'problem' regarding MinCR? I can try to encode again and redo the verification pass if necessary otherwise I'll wait for anoter patch version (I don't have a performant CPU, so I need a bit of time)
Thank you very much!
kieranrk
31st January 2010, 14:39
Correct me if I'm wrong: the 'picture structure' field could have different values for what I've read... like (i.e., dunno if it's wrong or not, i don't have the specs) 3 for TFF or 4 for BFF. In case of a progressive encode the --pic-struct parameter write 1?
Latest question: the 1.22 patch tries in some way to fix the 'problem' regarding MinCR? I can try to encode again and redo the verification pass if necessary otherwise I'll wait for anoter patch version (I don't have a performant CPU, so I need a bit of time)
Thank you very much!
For progressive the value of pic_struct is 0.
I'm almost certain this 'problem' with MinCR is a mistake by the validator.
rack04
31st January 2010, 19:06
V1.22
patch: Unexpectedly ends in the middle of line
patch: **** only garbage was found in the patch input.
Emulgator
1st February 2010, 13:44
Reading H.264 further, but well, I will rather post that without my conclusions, I have none at the moment ;-)
Hopefully it helps developers and the people who have verifiers...
frame_mbs_only_flag equal to 0 specifies that coded pictures of the coded video sequence may either be coded fields or coded frames.
frame_mbs_only_flag equal to 1 specifies that every coded picture of the coded video sequence is a coded frame containing only frame macroblocks.
When the value of profile_idc does not indicate conformance to any of the profiles specified in Annex A
and vui_parameters_present_flag is equal to 1,
timing_info_present_flag shall be equal to 0,
nal_hrd_parameters_present_flag shall be equal to 0,
vcl_hrd_parameters_present_flag shall be equal to 0,
and pic_struct_present_flag shall be equal to 0.
When the value of profile_idc does indicate conformance to one or more of the profiles specified in Annex A
and vui_parameters_present_flag is equal to 1,
the values of
timing_info_present_flag,
num_units_in_tick,
time_scale,
fixed_frame_rate_flag,
nal_hrd_parameters_present_flag,
vcl_hrd_parameters_present_flag,
low_delay_hrd_flag,
pic_struct_present_flag
and the values of syntax elements included in the hrd_parameters( ) syntax structures,
when present,
shall be such that the bitstream activating the sequence parameter set
is conforming to one or more of the profiles specified in Annex A.
pic_struct_present_flag equal to 1 specifies that picture timing SEI messages (subclause D.2.2) are present that include the pic_struct syntax element.
pic_struct_present_flag equal to 0 specifies that the pic_struct syntax element is not present in picture timing SEI messages.
When pic_struct_present_flag is not present, its value shall be inferred to be equal to 0.
D.2.2 Picture timing SEI message semantics
The presence of picture timing SEI message in the bitstream is specified as follows.
– If CpbDpbDelaysPresentFlag is equal to 1 or pic_struct_present_flag is equal to 1,
one picture timing SEI message shall be present in every access unit of the coded video sequence.
– Otherwise (CpbDpbDelaysPresentFlag is equal to 0 and pic_struct_present_flag is equal to 0),
no picture timing SEI messages shall be present in any access unit of the coded video sequence.
Table D-1 – Interpretation of pic_struct
Value -> Indicated display of picture, Restrictions; NumClockTS
0 -> frame -> field_pic_flag shall be 0; NumClockTS=1
1 -> top field ->field_pic_flag shall be 1, bottom_field_flag shall be 0; NumClockTS=1
2 -> bottom field ->field_pic_flag shall be 1, bottom_field_flag shall be 1; NumClockTS=1
3 -> top field, bottom field, in that order -> field_pic_flag shall be 0; NumClockTS=2
4 -> bottom field, top field, in that order -> field_pic_flag shall be 0; NumClockTS=2
5 -> top field, bottom field, top field repeated, in that order -> field_pic_flag shall be 0; NumClockTS=3
6 -> bottom field, top field, bottom field repeated, in that order -> field_pic_flag shall be 0; NumClockTS=3
7 -> frame doubling -> field_pic_flag shall be 0, fixed_frame_rate_flag shall be 1; NumClockTS=2
8 -> frame tripling -> field_pic_flag shall be 0, fixed_frame_rate_flag shall be 1; NumClockTS=3
9-15 -> Reserved
kieranrk
1st February 2010, 17:31
Just out of interest does Blu-ray let you code 1080p25 without using interlacing? Can you use 1080p25 will pic_struct or something?
Also is there anything about NumClockTS?
Rumbah
1st February 2010, 17:45
I've seen a German BluRay with 1080p25 if i remember correctly, but I don't know which one it was. If it's important I can search for it ;) .
shon3i
1st February 2010, 18:12
Just out of interest does Blu-ray let you code 1080p25 without using interlacing? Can you use 1080p25 will pic_struct or something?
Also is there anything about NumClockTS?
Not without --interlaced switch (scenarist) and earler version of HRD patches. I will now test with or without pic_struct. Please give me few hours :)
Trahald
1st February 2010, 21:45
While in practice it may be different, 1080p25 is not allowed.
shon3i
1st February 2010, 22:17
While in practice it may be different, 1080p25 is not allowed.
Encocoding progressive material with interlaced switch you get interlaced video 1080i25 which is allowed, and scenarist detect it as 1080i25.
kolak
1st February 2010, 22:25
While in practice it may be different, 1080p25 is not allowed.
You ave to encode it as it would be 50i and it does work.
If you have a good player you may get original 25p on your TV.
Andrew
Atak_Snajpera
2nd February 2010, 00:23
PS3 plays 1080p 25fps without problems. I wouldn't be surprised if this also applies to other good brands.
kolak
2nd February 2010, 16:43
PS3 plays 1080p 25fps without problems. I wouldn't be surprised if this also applies to other good brands.
It's not about what PS3 or even any other player can play- BD doesn't support pure 25p/30p modes.
PS3 can play much more than BD spec allows- it did play 100Mbit AVC, but at maybe 5fps :)
Andrew
mp3dom
2nd February 2010, 16:49
Back to the NAL patch: At the end I'm not understanding if the current patch version (1.22) match the specs posted by Emulgator.
kieranrk
2nd February 2010, 18:39
Back to the NAL patch: At the end I'm not understanding if the current patch version (1.22) match the specs posted by Emulgator.
It does.
shon3i
2nd February 2010, 20:18
BD doesn't support pure 25p/30p modes.Well support it as Secondary video, so is generaly supported. That's why i liked HDDVD, maybe is less overall bitrate and storage, but twice more Video and Audio combination are allowed.
renqian
3rd February 2010, 16:23
here some primary question:
which Splitter Filter should i use to keep the field won't loss when i encoding?
and which decoder can playback the product correctly in 60fps on LCD or LCD TV?(i mean if i use the HTPC)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.