x264 development

[roozhou]

There are tons of work to do to add support for MSVC. If you need to include lavf input support, you still have to use MinGW to compile ffmpeg.

[schweinsz]

I downloaded the x264 version to encode raw .yuv to lossless .264 using the following cmd:

D:\sequences\CIF>x264 --partitions "all" --qp 0 --keyint 2 --input-res 352x288 -o frmanls.264 foreman_cif.yuv
yuv [info]: 352x288p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 1.3, bit depth 8
x264 [info]: frame I:150 Avg QP: 0.00 size: 71310
x264 [info]: frame P:150 Avg QP: 0.00 size: 54972
x264 [info]: mb I I16..4: 3.7% 11.8% 84.5%
x264 [info]: mb P I16..4: 0.1% 9.9% 4.6% P16..4: 51.8% 18.6% 9.5% 3.4% 2.1% skip: 0.0%
x264 [info]: 8x8 transform intra:18.9% inter:66.1%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0% inter: 99.7% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 14% 76% 8% 2%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 55% 13% 1% 2% 2% 2% 1% 2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 37% 7% 3% 11% 5% 6% 4% 4%
x264 [info]: i8c dc,h,v,p: 7% 40% 52% 1%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: kb/s:12628.21

encoded 300 frames, 27.08 fps, 12628.21 kb/s


Then I use the jm17.2 to decode the frmanls.264 to raw .yuv, but I found the reconstructed .yuv is corrupted. There is red blocks and corrupted bottom borders.
Is it a bug in x264 or a bug in jm17.2?


Edit1: I download the official x264 and find the same problem.

[kieranrk]

Originally Posted by schweinsz

I downloaded the x264 version to encode raw .yuv to lossless .264 using the following cmd:

JM doesn't support lossless.

[schweinsz]

Originally Posted by kieranrk

JM doesn't support lossless.

I suspect your opinion. I ever explored the jm code and found many code related to lossless with the following style:

if(currMB->is_lossless)
{
if ((currMB->c_ipred_mode == VERT_PRED_8)||(currMB->c_ipred_mode == HOR_PRED_8))
Inv_Residual_trans_Chroma(currMB, uv) ;
else
{
for(j=0;j<p_Vid->mb_cr_size_y;j++)
for(i=0;i<p_Vid->mb_cr_size_x;i++)
currSlice->mb_rres [uv+1][j][i]=currSlice->cof[uv+1][j][i];
}
}

[kieranrk]

Originally Posted by schweinsz

I suspect your opinion.

If I recall correctly it supports the old (I forget what it was called) lossless standard but not the new one (High 4:4:4 Predictive Profile Lossless).

[LoRd_MuldeR]

Indeed, x264 uses the "High 4:4:4 Predictive Profile" in lossless mode. That profile isn't supported by some decoder, quite possible that JM reference is among them.

The H.264 decoder from 'libavcodec' (which includes ffdshow, MPlayer, VLC and friends) as well as 'CoreAVC' do support it though...

[schweinsz]

Originally Posted by LoRd_MuldeR

Indeed, x264 uses the "High 4:4:4 Predictive Profile" in lossless mode. That profile isn't supported by some decoder, quite possible that JM reference is among them.

The H.264 decoder from 'libavcodec' (which includes ffdshow, MPlayer, VLC and friends) as well as 'CoreAVC' do support it though...

Yes, you are right. The JM doesn't support the new lossless mode. I have finished the lossless support of the DiAVC.

[Dark Shikari]

Originally Posted by schweinsz

Yes, you are right. The JM doesn't support the new lossless mode.

It does, but not for 4:2:0 (iirc) for some stupid reason.

[rallymax]

Hi team,

I did an update of the libav* codebase to get some new features - which in turn required a higher version of x264 so I updated that too. Not a problem I rebuilt libav* and libx264.

The x264_validate_parameters() is failing. I've seen this before and last time I simply commented the libx264.c x4->param changes out and used the x264 defaults instead. I also commented out the x264_validate_parameters#76 score code because I was more worried about getting the thing to run. But.... I know that's not the right thing to do since it's there, most likely, for a very good reason.

What should I be doing to to the x4->params.* in libavcodec/libx264.c to get this to not fail?

I actually need the parameters to make it a legal BluRay stream.

When I commented out the code (above) that changed the parmeters and left it as defaults it processed fine and made a playable stream but Adobe Encore wouldn't recognize it as a legal stream and wanted to re-encode it and thus defeated the whole purpose of making a program using the BEST ENCODER IN THE WORLD!!! to ditch the AWEFUL encoder bundled from Adobe.

Did the NAL HRD patch get folded in since Feb '10? If not does that patch still work?

thanks,
Rallymax


Here is the output of the out-of-box libavformat/output-example.c using the libav*.DLLs and libx264-105.DLL...

$ ./output-example xxx.h264
Output #0, h264, to 'xxx.h264':
    Stream #0.0: Video: libx264, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc
[libx264 @ 003e1100] broken ffmpeg default settings detected
[libx264 @ 003e1100] use an encoding preset (vpre)
could not open codec

[EDIT] just saw this above "Authoring Professional Blu-Rays with x264" so I'm going to take those parameters and feed them into the x4->param and see how we go with the score.[/EDIT]

[LoRd_MuldeR]

Originally Posted by rallymax

Did the NAL HRD patch get folded in since Feb '10? If not does that patch still work?

http://git.videolan.org/gitweb.cgi?p...d723c7d0c9f505

Originally Posted by rallymax

What should I be doing to to the x4->params.* in libavcodec/libx264.c to get this to not fail?

Initialize your 'x264_param_t' via x264_param_default() and then only overwrite the settings you need to overwrite. Use x264_param_default_preset() to apply presets/tunings.

(FFmpeg is known to set rather "bizarre" default settings for x264, so x264 will detect "broken" FFmpeg default settings to protect the user. Don't know if FFmpeg ever fixed their x264 default settings)

Originally Posted by rallymax

I actually need the parameters to make it a legal BluRay stream.

The commit message shows an example on how to configure x264 for BluRay compatibility...

[rallymax]

Originally Posted by LoRd_MuldeR

http://git.videolan.org/gitweb.cgi?p...d723c7d0c9f505

re BluRay - Awesome work LM and others.

Originally Posted by LoRd_MuldeR

Initialize your 'x264_param_t' via x264_param_default() and then only overwrite the settings you need to overwrite. Use x264_param_default_preset() to apply presets/tunings.

The commit message shows an example on how to configure x264 for BluRay compatibility...

Init with.... hmm it already has the init call...

static av_cold int X264_init(AVCodecContext *avctx) 
{ 
    X264Context *x4 = avctx->priv_data; 
 
    x4->sei_size = 0; 
    x264_param_default(&x4->params); <---------------
 
    x4->params.pf_log               = X264_log; 
    x4->params.p_log_private        = avctx;

ok... so based on the git commit comments and the ones from kieranrk's google doc page I should be able to get this to go now.

thanks.

[LoRd_MuldeR]

Originally Posted by rallymax

re BluRay - Awesome work LM and others.

Not my work though

Originally Posted by rallymax

Init with.... hmm it already has the init call...

static av_cold int X264_init(AVCodecContext *avctx) 
{ 
    X264Context *x4 = avctx->priv_data; 
 
    x4->sei_size = 0; 
    x264_param_default(&x4->params); <---------------
 
    x4->params.pf_log               = X264_log; 
    x4->params.p_log_private        = avctx;

Obviously the x264 defaults are still overwritten by FFmpeg (libavcodec) with their own "broken" defaults - after the defaults have been initialized by x264 itself.

As far as I understand, you use libx264 indirectly, through libavcodec. Why not call libx264 directly ???

[rallymax]

Originally Posted by LoRd_MuldeR

Not my work though
Why not call libx264 directly?

I'm using libavformat to make the m2ts container so that it's muxed with AC3 too.

[edit] oh, I also use libswscale and the RGB -> YUV planar conversion functions so it's just easier to call the libavformat front end based off of the output-example and have it then call the x264 library for me.[/edit]

Unfortunately libavformat's mpegts muxer is implemented for true MPEG-TS (vs the slight modification of the timestamp header for .MTS). In many hours of Googling I'm yet to find out what the increment value is of the 4byte timecode on the front of the 188byte mpegts packet. I'm of the impression that it's something to do with the real time divided by the current vbr value. I've hacked that into libavformat/mpegtsenc.c to add ".mts" but will need to fix the increment rate eventually so that, I think, BluRay players can scrub fwd/rev properly.

This MPEG-TS & Timecode hack for Bluray is Wikipedia info on the issue.

You wouldn't happen to have an info on that would you?

[LoRd_MuldeR]

Originally Posted by rallymax

I'm using libavformat to make the m2ts container so that it's muxed with AC3 too.

Unfortunately libavformat's mpegts muxer is implemented for true MPEG-TS (vs the slight modification of the timestamp header for .MTS). In many hours of Googling I'm yet to find out what the increment value is of the 4byte timecode on the front of the 188byte mpegts packet. I'm of the impression that it's something to do with the real time divided by the current vbr value. I've hacked that into libavformat/mpegtsenc.c to add ".mts" but will need to fix the increment rate eventually so that, I think, BluRay players can scrub fwd/rev properly.

This MPEG-TS & Timecode hack for Bluray is Wikipedia info on the issue.

You wouldn't happen to have an info on that would you?

No, but why not encode with the x264 CLI encoder to "raw" H.264 stream and mux it to M2TS afterwards, with something like tsMuxeR?

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in 'x4->params' after the x264_param_default() call, except for the things you really need?)

[rallymax]

Originally Posted by LoRd_MuldeR

No, but why not encode with the x264 CLI encoder to "raw" H.264 stream and mux it to M2TS afterwards, with something like tsMuxeR?

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in x264_paramt_t after the x264_param_default() call, except for those you really need?)

I'm trying to make it all just one program vs a workflow (otherwise I could have done this a yr ago with AVS scripts etc)

yes, I'm going to blow away all the libx264.c changes to the defaults and just plug in the ones needed to make BluRay based on the x264 arguments given on the google doc page for legal bluray.

I think we're on the same page.

[rallymax]

Originally Posted by LoRd_MuldeR

(BTW: If you are hacking FFmpeg anyway, why not kick out everything they overwrite in 'x4->params' after the x264_param_default() call, except for the things you really need?)

'just home, pulled everything out except the size and SAR and tried it... and it worked!

Now to pop in the BluRay values...

$ ./output-example.exe xxx.h264
Output #0, h264, to 'xxx.h264':
    Stream #0.0: Video: libx264, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc
[libx264 @ 00544500] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
[libx264 @ 00544500] profile High, level 1.3
[libx264 @ 00544500] non-strictly-monotonic PTS
    Last message repeated 49 times
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
[libx264 @ 00544500] invalid DTS: PTS is less than DTS
[libx264 @ 00544500] non-strictly-monotonic PTS
    Last message repeated 121 times
[libx264 @ 00544500] frame I:1     Avg QP:23.49  size:  2556
[libx264 @ 00544500] frame P:31    Avg QP:22.84  size:   903
[libx264 @ 00544500] frame B:93    Avg QP:29.04  size:   558
[libx264 @ 00544500] consecutive B-frames:  0.0%  0.0%  0.0% 100.0%
[libx264 @ 00544500] mb I  I16..4: 78.3% 15.7%  6.1%
[libx264 @ 00544500] mb P  I16..4: 77.2%  4.7%  0.3%  P16..4: 17.1%  0.4%  0.2%  0.0%  0.0%    skip: 0.0%
[libx264 @ 00544500] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8: 14.3%  0.2%  0.0%  direct:25.0%  skip:60.5%  L0:57.1% L1:38.6% BI: 4.2%
[libx264 @ 00544500] 8x8 transform intra:6.1% inter:41.6%
[libx264 @ 00544500] coded y,uvDC,uvAC intra: 3.3% 27.8% 4.9% inter: 0.2% 42.2% 6.3%
[libx264 @ 00544500] i16 v,h,dc,p:  0%  0%  0% 100%
[libx264 @ 00544500] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  0% 29%  3% 66%  0%  0%  0%  1%  0%
[libx264 @ 00544500] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu:  0%  9% 20% 69%  0%  0%  0%  1%  1%
[libx264 @ 00544500] i8c dc,h,v,p:  0%  3%  7% 89%
[libx264 @ 00544500] Weighted P-Frames: Y:0.0%
[libx264 @ 00544500] ref P L0: 91.5%  0.7%  6.5%  1.2%
[libx264 @ 00544500] ref B L0: 66.4% 26.5%  7.1%
[libx264 @ 00544500] ref B L1: 97.9%  2.1%
[libx264 @ 00544500] kb/s:-0.00

[Dark Shikari]

Originally Posted by rallymax

I'm trying to make it all just one program vs a workflow (otherwise I could have done this a yr ago with AVS scripts etc)

yes, I'm going to blow away all the libx264.c changes to the defaults and just plug in the ones needed to make BluRay based on the x264 arguments given on the google doc page for legal bluray.

I think we're on the same page.

ffmpeg has preset files (accessed with -vpre) that set the x264 default settings accordingly for various presets.

Of course, it's better to just do it right, and you'll have to modify the code if only because not all necessary options are exposed (e.g. NAL HRD).

[iwod]

After the license change for x264, all seems rather quiet on x264 side. Any new things going on?

[Dark Shikari]

Originally Posted by iwod

After the license change for x264, all seems rather quiet on x264 side. Any new things going on?

Well, if you paid attention to git or the weekly newsletter, we now have high bit depth support finished, among other things. I have about 8 local patches that'll go in soon, but nothing really big at the moment.

Also, there was no license change, only a license addition. It's still GPL.

[shon3i]

@Dark Shikari, is it possible in near future to make more friendly bitdepth, as single switch like Mainconcept, not at comple?