x264 development

[shon3i]

Good news - the Panasonic reads the X264 Bluray demo disk just fine. So, definitely some sort of muxing issue then, or maybe as you suggest the BPyramid Strict option works on Panasonic only when combined with some other option like SAR.SAR is MANDATORY option for blu-ray, look here at 2.1 chapter http://forum.doom9.org/showthread.php?t=154533, for all mandatory options for BD, they should be always used when encoding for BD. SAR should not fix b-pyramid problem, but i suggest you to use it, since panasonic is very strict, and one of player that really follow BD specs. You should use b-pyramid always if you get some quality gain.

I just demuxed the previous MKV.That is same as directly encode to MKV. So this option definitly will not work as i said. You need to encode directly to raw 264, otherwise, x264 will calculate differenet AUD for target container, which after Tsmuxer completly broke, demuxing mkv to elementary (raw 264) will not change that calculations, and stream practically is useless, and make unplayable on panasonic players.

I'm also going to try remuxing a stream from the Bluray demo disk with TSMuxer, burn, and see what happens. It will work, since all calculations are ok, unless you use MKV or other container in that process as intermediate file, that will rush compatibility, and make stream unplayable.

[JoeH]

First test:
Remuxed x264 demo file 0003.m2ts using all of TSMuxer's default settings. The Panasonic played it just fine.

MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=500
V_MPEG4/ISO/AVC, "F:\4 Peliculas\X264 Demo Disk\BDMV\STREAM\00003.m2ts", fps=24, insertSEI, contSPS, track=4113
A_DTS, "F:\4 Peliculas\X264 Demo Disk\BDMV\STREAM\00003.m2ts", track=4352, lang=eng

[JoeH]

Second test

I've output 4 different streams - 2 are .MKV, 2 are .264. One of each container type has SAR set, the other does not.

Just tested .MKV with no SAR - this is identical to what didn't work before. As expected, it did not work. I ran this just as a control.

[JoeH]

Third test

.264 stream without SAR set. It works just fine in the Panasonic.

Fourth test

.MKV stream with SAR set. Does not play.

Fifth test

.264 stream with SAR set.

Results summary - Panasonic players will play streams from TSMuxer using BPyramid --strict option as long as the original input is a .264 stream and not an MKV stream. This will work with default TSMuxer options, and works regardless of whether the SAR option is correctly configured or not.

[rack04]

Results summary - Panasonic players will play streams from TSMuxer using BPyramid --strict option as long as the original input is a .264 stream and not an MKV stream. This will work with default TSMuxer options, and works regardless of whether the SAR option is correctly configured or not.

I wouldn't summarize this as all Panasonic's. My BD-35 doesn't have any problem playing back remuxed mkv's with --strict.

[shon3i]

I wouldn't summarize this as all Panasonic's. My BD-35 doesn't have any problem playing back remuxed mkv's with --strict.
Here is not question that what will work or not. It's simple, MKV/MP4 output (or demuxed from MKV/MP4) should never use if target is BD, regardless that some player play or not, that stream will never pass initial verification, and it's completly broken.

[rack04]

Here is not question that what will work or not. It's simple, MKV/MP4 output (or demuxed from MKV/MP4) should never use if target is BD, regardless that some player play or not, that stream will never pass initial verification, and it's completly broken.

Actually that is exactly the question. JoeH said that Panasonic's do not play files that have been remuxed from mkv and I stated that my BD-35 will.

[shon3i]

Well it's not question since is not legal operation, end of story. In past we have people with BD-35 which have exactly same problem (in BDrebuilder thread). From this point maybe panasonic update their software, but still why we should expect something to work, when is come broken.

[JoeH]

I also have a BD35, and the playback problems are identical on it as on the BD60 with the rendering / muxing method I use.

[laserfan]

I continue to struggle with understanding the tsMuxeR setting of --vbv-len wrt the --vbv-init (default 0.9) setting in x264, along with bufsize and maxrate:

--vbv-len - The length of the virtual buffer in milliseconds. The default value is 500. Typically, this option is used in conjunction
with --cbr. The parameter is similar to the value of vbv-buffer-size in the x264 coder, but is set not in kbit, but in milliseconds (with
constant bitrate they can be counted at each other). If you have self-encoded a x264 file with constant bitrate, for more smooth
broadcasting to the network you are encouraged to make the same (or less) setting than in the x264. On virtual buffer overflow relevant
errors are written in the log.
Under what circumstances (if any) should the --vbv-len parameter in tsMuxeR be altered from default 500ms? Any reason to alter it, or the 0.9 default of vbv-init if my output is to BD standard?

[kieranrk]

I continue to struggle with understanding the tsMuxeR setting of --vbv-len wrt the --vbv-init (default 0.9) setting in x264, along with bufsize and maxrate:


Under what circumstances (if any) should the --vbv-len parameter in tsMuxeR be altered from default 500ms? Any reason to alter it, or the 0.9 default of vbv-init if my output is to BD standard?

(bufsize/bitrate)*1000

vbv-init is not relevant

[shon3i]

As in readme written that is used only in conjunction with -cbr, don't touch it, because has no effect.

[Sharc]

Here is not question that what will work or not. It's simple, MKV/MP4 output (or demuxed from MKV/MP4) should never use if target is BD, regardless that some player play or not, that stream will never pass initial verification, and it's completly broken.
Does stream damage come with mkv/mp4 muxing or with demuxing?

[shon3i]

Does stream damage come with mkv/mp4 muxing or with demuxing?
tsmuxer is that who will broke stream, but MKV or MP4 muxer will strip/revrite AUD when mux, and will not revert back on demux. And since Tsmuxer have some not perfect mechanism to restore all need information for bd, instead that will violate all aud data.

[Sharc]

@shon3i
Thank you. A new revision of TSMUXER would be nice ....

[shon3i]

Yep, long time, tsmuxer currently have problem with pulldown streams, an who know what else, i think we can make pretty list of bugs. I think is time for new muxer, opensource idealy to be easily maintained :D.

Anyway, mkv or mp4 output is not for BD, only raw 264 or maybe ts/mpg. So any aplication that mux mkv/mp4 into BD structure, definitly use some (ugly) hack.

[JoeH]

OK, I just ran another test that I think is very important to note.

I muxed the .264 output with BPyramid Strict into an MKV container, remuxed with TSMuxer into Bluray folders and burnt. It plays perfectly.

So, that means that BPyrmaid -Strict only causes problems with Panasonics when X264 outputs MKV format directly. As long as you output .264 from X264, you can then remux into MKV and eventually later into Bluray without problems.

[bob0r]

So,
x264.exe .264 > .mkv > .m2ts = ok
x264.exe .mkv > .m2ts = bad?

What did you use to .264 > .mkv ?

[shon3i]

So,
x264.exe .264 > .mkv > .m2ts = ok
x264.exe .mkv > .m2ts = bad?

What did you use to .264 > .mkv ?
No :)

x264.exe .264 > BD = OK
x264.exe .mkv/.mp4 > BD = bad
x264.exe .264 > .mkv/.mp4 > .264 > BD = bad

@JoeH, yes it because x264 automaticly calculate what need for target container. But still your combination beside playing will never pass verification, and remuxing raw stream to container and back is not good combination, it maybe work with tsmuxer because use some hacks, but will never pass with comercial muxers. Don't do that.

[bob0r]

x264.exe .264 > BD

"because it is the only way to get correct AUD and HRD info"

That's why. (Asked in #x264)

[burfadel]

For the resizing filters, what usefulness would spline100 and spline144 functions from the splineresize filter for avisynth http://www.geocities.com/wilbertdijkhof have when compared to the standard spline64resize, in terms of quality? If they do prove useful is it possible to be included in the x264 filters as well? they are afterall, essentially just an extension of the current spline16/36/64 filters, so shouldn't take much codespace.

[Dark Shikari]

You probably won't get significantly better than a basic Lanczos or Spline36 without doing edge-directed interpolation (EEDI, NNEDI, etc).

[Gser]

So I gather that the more sample points - the more sharper the resize. The pdf nicely explained the mathematical principles of it but not its effect on picture quality.

[Dark Shikari]

So I gather that the more sample points - the more sharper the resize.No; sharpening is generally done by choosing sharper filter coefficients.The pdf nicely explained the mathematical principlesThe problem with the mathematical principles is that they assume that the source is band-limited. This is true in the case of audio, and complete nonsense in the case of images.

[burfadel]

You probably won't get significantly better than a basic Lanczos or Spline36 without doing edge-directed interpolation (EEDI, NNEDI, etc).

Ah ok :) maybe a new optimised combination filter lol.

[kemuri-_9]

the resize filter in x264cli is based off of libswscale which does not have the concept of a bazillion varieties of spline like avisynth does.

[JoeH]

No :)

x264.exe .264 > BD = OK
x264.exe .mkv/.mp4 > BD = bad
x264.exe .264 > .mkv/.mp4 > .264 > BD = bad

@JoeH, yes it because x264 automaticly calculate what need for target container. But still your combination beside playing will never pass verification, and remuxing raw stream to container and back is not good combination, it maybe work with tsmuxer because use some hacks, but will never pass with comercial muxers. Don't do that.

The test I was speaking of is this one:
x264.exe .264 > .mkv > BD = OK (even with BPyramid -Strict on Panasonics)

[shon3i]

The test I was speaking of is this one:
x264.exe .264 > .mkv > BD = OK (even with BPyramid -Strict on Panasonics)
However, maybe play on your player, but may not on other, because that option still is not full BD compatible, it's just "work" now, maybe not tomorrow, is too risk and is not for backup or any serious usage.

x264.exe .264 > BD is only way to go.

[JoeH]

What about x264.exe .264 > M2TS > BD? Is that safe?

I ask because sometimes it is helpful to have a muxed video file before outputting the BD in order to finish editing subtitles, check out the video quality, etc.

[kieranrk]

What about x264.exe .264 > M2TS > BD? Is that safe?

I ask because sometimes it is helpful to have a muxed video file before outputting the BD in order to finish editing subtitles, check out the video quality, etc.

As long as the muxer doesn't mangle the stream (i.e tsmuxer) then it's ok.

[video_magic]

As long as the muxer doesn't mangle the stream (i.e tsmuxer) then it's ok.

Sorry to ask, but that is not clear to me. Are you saying there that tsmuxer does, or does not, mangle the stream? Thanks.

[shon3i]

Sorry to ask, but that is not clear to me. Are you saying there that tsmuxer does, or does not, mangle the stream? Thanks.
In most cases tsmuxer will try to change stream and replace by it's own hack. To prevent this you can try disabling insertSEI and contSPS options.

[JoeH]

OK. Honestly I haven't had any problems so far with TSMuxer that I haven't been able to solve somehow or another, but just in case, are there any reasonably priced / free muxers available that don't have this problem?

[schweinsz]

Is the B picture not supported by the x264 lossless mode?
I use the following cmd to encode the lossless bitstream using the x264 and get the following output:
D:\sequences\CIF>x264 --partitions "all" --qp 0 --keyint 10 --bframes 5 --input-res 352x288 -o frmn
_2bac.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:30 Avg QP: 0.00 size: 71208
x264 [info]: frame P:270 Avg QP: 0.00 size: 54093
x264 [info]: mb I I16..4: 2.8% 12.3% 85.0%
x264 [info]: mb P I16..4: 0.1% 9.4% 4.5% P16..4: 49.3% 23.3% 8.9% 2.7% 1.8% skip: 0.0%
x264 [info]: 8x8 transform intra:42.9% inter:70.6%
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: 15% 66% 16% 3%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 56% 15% 1% 2% 2% 2% 1% 3%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 38% 8% 3% 10% 5% 6% 3% 4%
x264 [info]: i8c dc,h,v,p: 9% 41% 50% 1%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 60.0% 11.5% 17.3% 11.2% 0.0%
x264 [info]: kb/s:11160.97

encoded 300 frames, 29.18 fps, 11160.97 kb/s

[Underground78]

See here : http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=6a4a9beae060d69bbeaeb8c1c3056fb6ae6765f6

[kemuri-_9]

I need some guinea pigs on windows platforms to help me on something:
I'm working on a patch to x264 to utilize native windows threading API rather than having to rely on pthread-win32 for threading.
so I need others to confirm that deadlocking and corruption do not occur.

Something important to know about this patch is that the code takes different paths for Vista/7 vs XP/2000.
(It shouldn't work on pre-2000 windows machines either, so don't even bother trying)

so i'll need victims from both sets of platforms (more worried about the XP & 2000 group tho)

build here (http://kemuri9.net/dev/x264/experimental/x264_w32thread.7z)

[Underground78]

It seems to work well here on XP SP3, output seems to be identical. Should we expect a (little) speed increase (I see something like a 2 or 3% speed gain) ?

[kemuri-_9]

It seems to work well here on XP SP3, output seems to be identical. Should we expect a (little) speed increase (I see something like a 2 or 3% speed gain) ?

No, I'm not particularly expecting that there should be any speed gains or losses for XP/2000... it should be just about the same as pthread-win32.
I would expect a very slight gain for Vista/7 though, as the patch uses some API exclusive to Vista/7 that pthread-win32 doesn't use.

[easyfab]

Ok here with xp sp3 and AMD II X4 620.

Same SSIM and bitrate and a little bit faster than the X264.nl version.

[shroomM]

Will test tomorrow and let you know of the results.

[MatLz]

XP32 SP2 here.
No problem.
Files are identical (the 'M' exepted)

[mariush]

Windows 2003 R2 32bit... SD 760x568, 25fps...q6600 overclocked to about 3Ghz, 4GB ram... it's slower but otherwise I don't notice anything wrong with the video itself.

x264_default.exe --frames 5000 --preset slower --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 5000 frames, 77.24 fps, 920.67 kb/s

x264_wthread.exe --frames 5000 --preset slower --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 5000 frames, 76.76 fps, 920.67 kb/s

But it was actually more like 74 fps throughout the first 4000 frames

x264_default.exe --frames 2000 --preset veryslow --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 2000 frames, 31.11 fps, 934.50 kb/s

x264_wthread.exe --frames 2000 --preset veryslow --tune film --pass 1 --bitrate 900 -o ep422.mkv 422.avs
encoded 2000 frames, 30.57 fps, 934.50 kb/s

The values reported after encoding were the same, in this case the following:

Second pass on the first 500 frames was 0.01 fps higher with the wthread version, 7.95 vs 7.96 fps.. but that may be just a fluke, due to the low number of frames.

[Usedocne]

@ kemuri-_9
No problems encountered here. (tested both 2pass and CRF)

[jpsdr]

On last git there is :

Improve quantizer handling
The default value for i_qpplus1 in x264_picture_t is now X264_QP_AUTO. This is currently 0, but may change in the future.
qpfiles no longer use -1 to indicate "auto"; QP is just omitted. The old method should still work though.


Actualy, i have all my qpfiles on the following format (exemple) :
1000 -1 I
2000 -1 I

Do i need to change all my files, or is the old format still compatible, but value not used ?

Is now the new format like :
1000 I
2000 I

this ?

[Dark Shikari]

On last git there is :


Actualy, i have all my qpfiles on the following format (exemple) :
1000 -1 I
2000 -1 I

Do i need to change all my files, or is the old format still compatible, but value not used ?

Is now the new format like :
1000 I
2000 I

this ?

The old method should still work though. 5chars

[jpsdr]

But, you said 'should still work', not '100% certain backward compatibility warrant'. So, i'm... well... a little... ....

Sorry, i don't know the meaning of '5chars'...

[sneaker_ger]

A post needs at least 5 characters in this forum, it's just a filler.

[MatLz]

Is theoricaly possible to have a knob (centered by default at 1.0) to control the amount of bits allocated for Bframes by mbtree ?
Thx

[kemuri-_9]

thanks for all the testing on the previous build XP users!

however, now i need your stashed away PCs once again for a new build (http://kemuri9.net/dev/x264/experimental/x264_w32thread_other.7z) that utilizes the condition variable API for pre-vista machines that a certain company developed.

this build should be compared against the standard pthread-win32 build, we'll be making a decision to drop pthread-win32 support depending on the benchmarks.

[MatLz]

Xp32 sp2
No problem
Identical files


But as my posts seem invisible...you won't care, right ?