Current Patches, Where to get them, How they affect speed/output

[Dark Shikari]

Sweet!

Hey DS is re-registration required for the other forums? Or was the db imported?I'm not about to copy-paste the entirety of doom9, even if I had access to the db ;)

Anyways, ask questions about the site there, not here.

[CpT]

I only asked because smf has a slick importer.


Back to testing the new version :thanks:

[rack04]

Fix zone parsing on mingw

Due to MinGW evidently being in the hands of a pack of phenomenal idiots, MinGW does not have strtok_r, a basic string function.

As such, remove the dependency on strtok_r in zone parsing.

Previously, using zones for anything other than ratecontrol failed.

So does this mean that we don't need to compile x264 with win_zone_parse_fix_06.diff anymore?

[imk]

So does this mean that we don't need to compile x264 with win_zone_parse_fix_06.diff anymore?

It's no longer needed.

[XhmikosR]

Download (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca0a0ab0ff40b8afb3)

x264.x86.r1373M.ICC11.O3.QxSSSE3
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
x264_icc_r1373.diff

x264.x86.r1373M.ICC11.O3.QaxSSSE3
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
x264_icc_r1373.diff

x264.x86.r1373M.core2 (gcc 4.4.2)
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

x264.x86.r1373.core2 (gcc 4.4.2)
Unpatched

[ajp_anton]

How can i test a stream encoded by 1369 if it's OK? Started the encode before it started crashing on people, and it just finished without crashing.

[Dark Shikari]

How can i test a stream encoded by 1369 if it's OK? Started the encode before it started crashing on people, and it just finished without crashing.Grab JM.

ldecod -i input.h264

If it errors out before the end, the stream is corrupt.

[XhmikosR]

BTW, I forgot to thank Dark Shikari for the time he spent on fixing the bug caused by 1364. I wish I could have helped more, but my debug build didn't crash.

[ajp_anton]

Grab JM.

ldecod -i input.h264

If it errors out before the end, the stream is corrupt.Thanks.
287952 frames with no errors. How lucky was I? =)

[techouse]

x264_x86_r1373_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1373_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86.generic.Komisar), unpatched, generic, fprofiled

x264_x64_r1373_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1373_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), unpatched, generic, fprofiled

---------------------------------------------------------

x264_x86_r1373_gcc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1373_gcc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1373_gcc_techouse.txt)
GCC 4.4.2 20091019 (x86.generic.Komisar), generic, fprofiled

x264_x64_r1373_gcc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1373_gcc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1373_gcc_techouse.txt)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), generic, fprofiled

Patches used:

x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

---------------------------------------------------------

x264_x86_r1373_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1373_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x64_r1373_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1373_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)

---------------------------------------------------------

x264_x86_r1373_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1373_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1373_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

x264_x64_r1373_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1373_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1373_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

[rack04]

x264_x86_r1373M (http://www.megaupload.com/?d=OT5LLP4R)

Toolchain:
mingwrt-3.16
w32api-3.13
binutils-2.20
gcc-core-4.4.2
zlib-1.2.3
yasm-0.8.0
Patch:
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)
Build:
./configure --extra-cflags="-march=core2"
make fprofiled VIDS="/c/x264/crew_4cif.y4m /c/x264/parkrun.1280x720.yuv"

[Brazil2]

Bug or feature ?

I encode using --psy-rd=1:0.15 but when it's done MediaInfo reports psy_rd=1.0:0.2

So what is wrong ? Is x264 rounding the input value or is MediaInfo showing a rounded value ?
I'm quite sure that the correct value of 0.15 was shown with older builds of x264 like six months ago, maybe more.

[LoRd_MuldeR]

I encode using --psy-rd=1:0.15 but when it's done MediaInfo reports psy_rd=1.0:0.2

if( p->analyse.b_psy )
s += sprintf( s, " psy_rd=%.1f:%.1f", p->analyse.f_psy_rd, p->analyse.f_psy_trellis );

:p

[nurbs]

x264 rounds the values that get written to the file to one decimal, but the value used during encoding is not changed. AFAIK it's always been that way.

[Brazil2]

OK thanks for clarification :)
Although I wonder why it's made like that.

[LoRd_MuldeR]

Although I wonder why it's made like that.

Probably because "psy_rd" was added to param2string() before the "film" tune started using Psy RDO 0.15 ^^

[qyot27]

']I don't know if it's possible to have two GCC versions at the the same time without screwing things up.
It's possible as long as you keep them separate. Two concurrent toolchains (MSys+MinGW+GCC 3.4.5 in C:\msys, and MSys+MinGW+GCC 4.4.2 in C:\WINDOWS\msys, for example) are fine, but two concurrent GCC versions on one MinGW install (MSys+MinGW+GCC 3.4.5+GCC 4.4.2 in C:\msys) is not, to my knowledge. I couldn't get it to work when I tried. It'd be handier if it could work, though.






For those that want to try it out, I've served up an MSys+MinGW package that uses GCC 3.4.5 instead of the 4.x branch. I've only tested it on my XP Home SP3 setup and my mom's Vista (pre-SP1) laptop, and it worked fine on both. There's a text file provided that lists the things it includes, and it should be fine for compiling x264 and ffmpeg, at the very least. You can download it here (it expects to be extracted to C:\):

http://www.mediafire.com/?zzjt3vlim2n

[kemuri-_9]

you can have as many versions installed as you want.

the tricky part is just calling the right gcc if you have a bunch around...
as you'll end up resorting to renaming executables or using full pathnames to get the right one.
(this is why linux distros generally use a version postfix to signify which version of gcc it is)

as for myself, i have 3 different mingws around.

[qyot27]

Is there any sort of tutorial on how to set up multiple versions of GCC correctly? I couldn't find any through Google when I looked. It's mindnumbingly simple on Linux, as calling CC= takes care of it, but how does that work out on Windows?

This is why I simply go for keeping them separate and not letting any of them interfere with each other.

[J_Darnley]

Is there any sort of tutorial on how to set up multiple versions of GCC correctly? I couldn't find any through Google when I looked. It's mindnumbingly simple on Linux, as calling CC= takes care of it, but how does that work out on Windows?

Well since cygwin and msys are unix-like, setting CC should work fine. Certainly using --cc when configuring ffmpeg gets it to use my gcc 4 which is installed in the same folder as 3.4.5

[qyot27]

Well since cygwin and msys are unix-like, setting CC should work fine. Certainly using --cc when configuring ffmpeg gets it to use my gcc 4 which is installed in the same folder as 3.4.5
Downloaded TDM SJLJ GCC 4.4.1 core and g++ packages.*
Extracted them, and appended -4.4.1 to the end of each.
Put them in /bin.

cd x264
CC=gcc4.4.1 ./configure (or CC=gcc4, doesn't matter)
No working C compiler found.

Neither does it work if I unpack them without renaming to /gcc4 and add an entry to fstab that points there. Still no working C compiler. Like kemuri-_9 said, you have to constantly rename the gcc bin files back and forth for which one you want to use at the time, or use full pathnames (and CC= and --cross-prefix are not the solutions to that). I knew that already, which is why I said separate installations are the easiest to deal with. Then no renaming is necessary - just fire up your GCC 4.4.x-enabled installation, or your GCC 3.4.5-enabled one, which don't talk to each other at all and have a complete MSys each that's are all their own.

Cygwin and MSys may both be Unix-like, but MSys =/= Cygwin. If you want to explain how you got multiple GCC versions working under a single install of MSys without having to rename anything and only calling CC= or --cc=, then I'd be more than happy to hear it. But from where I'm standing (including wasting all of this morning trying to no avail), it's not possible.




*I even grabbed komisar's GCC 4.4.2 build and extracted it out to the empty /mingw directory and pointed it there - still no dice.

[J_Darnley]

CC=gcc-sjlj ./configure works4me.
Is gcc actually called "gcc4.4.1.exe" or "gcc4.exe"?
I think I just extracted the 4.2.1 archives (from mingw) into the my mingw folder and they just worked. They already had the -sjlj suffix.

[kemuri-_9]

if you only download the different gcc and don't have the libs and include files in the new gcc's search path,
you can cheat by adding the library and include paths from your full installation to the commandline,

i.e.:
CC=gcc-blah ./configure --extra-cflags=-I/mingw/include --extra-ldflags=-L/mingw/lib

where there's a full installation at /mingw and the CC you give is only the compiler (no runtime and no headers in its search path)

you won't have to do this if you extract the gcc to the same prefix as your current installation (granted the executable names are different and won't overwrite anything)

[qyot27]

Ok, thanks. Everything's working now the way it should. Now I just have to get 4.4.2 in there instead of 4.4.1.

[techouse]

Another way to permanently change the default CC is via /etc/fstab

[[ReX]]

My x264 r1376 builds.

GCC 4.5.0 (experimental) builds

Generic (http://www.mediafire.com/?iqmwouzu5jm) (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff

-march=core2 (http://www.mediafire.com/?yk3vxi2nmqi) (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff


(NEW) GCC 3.4.6 build

Generic (http://www.mediafire.com/?djxzoxzcunm) (fprofiled)
Patch used: x264_hrd_pd_interlace.16_r1369.diff


ICC 11.1.051 builds
Thanks to MasterNobody and XhmikosR.

Generic (http://www.mediafire.com/?wyrmro0dkb4) (fprofiled)
Patches used: x264_icc_r1373.diff and x264_hrd_pd_interlace.16_r1369.diff

/QaxSSSE3 /O3 (http://www.mediafire.com/?ntdmlmyudty) (fprofiled)
Patches used: x264_icc_r1373.diff and x264_hrd_pd_interlace.16_r1369.diff

/QxSSSE3 /O3 (http://www.mediafire.com/?1yymkmtjytw) (fprofiled)
Patches used: x264_icc_r1373.diff and x264_hrd_pd_interlace.16_r1369.diff

[techouse]

x264_x86_r1376_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1376_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86.generic.Komisar), unpatched, generic, fprofiled

x264_x64_r1376_vanilla_gcc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1376_vanilla_gcc_techouse.7z)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), unpatched, generic, fprofiled

---------------------------------------------------------

x264_x86_r1376_gcc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1376_gcc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1376_gcc_techouse.txt)
GCC 4.4.2 20091019 (x86.generic.Komisar), generic, fprofiled

x264_x64_r1376_gcc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1376_gcc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1376_gcc_techouse.txt)
GCC 4.4.2 20091019 (x86_64.generic.Komisar), generic, fprofiled

Patches used:

x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

---------------------------------------------------------

x264_x86_r1376_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1376_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x64_r1376_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1376_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.051, almost unpatched, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)

---------------------------------------------------------

x264_x86_r1376_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1376_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1376_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

x264_x64_r1376_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1376_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1376_icc_techouse.txt)
Intel C++ Compiler 11.1.051, -QxSSSE3 -O3, fprofiled

Patches used:

x264_icc_13_win.diff (http://imk.cx/pc/x264/build-icc-win.7z)
x264_hrd_pd_interlace.16_r1369.diff (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1369.diff)

[techouse]

if you only download the different gcc and don't have the libs and include files in the new gcc's search path,
you can cheat by adding the library and include paths from your full installation to the commandline,

i.e.:
CC=gcc-blah ./configure --extra-cflags=-I/mingw/include --extra-ldflags=-L/mingw/lib

where there's a full installation at /mingw and the CC you give is only the compiler (no runtime and no headers in its search path)

you won't have to do this if you extract the gcc to the same prefix as your current installation (granted the executable names are different and won't overwrite anything)
If you're doing more than 1 build with the same CC it's probably a good idea to export it before running configure and then use it as default.

[olapanekala]

Happy Holidays to everyone

[aegisofrime]

My version of x264 (r1376) feels old :D Are the x264 developers planning a Christmas present for us? ;)

[Fr4nz]

Probably they're on vacation like us...

[Sharc]

My version of x264 (r1376) feels old :D Are the x264 developers planning a Christmas present for us? ;)
What improvements / features are you waiting for? :D

[Dark Shikari]

Download this clip, open it in VLC or MPC-HC, and seek anywhere in the video. (http://mirror05.x264.nl/Dark/PIRtest.mkv) Oh and it has no keyframes.

[LoRd_MuldeR]

Interesting. What does "PIR" stand for please? And is there any loss in compression efficiency?

[Dark Shikari]

Interesting. What does "PIR" stand for please? And is there any loss in compression efficiency?Periodic Intra Refresh. The loss exists, but it's not that large when compared to having a similar keyframe interval (e.g. keyint=35 for a PAL SD video.)

More importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime HD encoding at zero latency.

In other words, x264 is now the greatest encoder in the world for realtime video applications, like videoconferencing, and anyone who uses anything else needs to have their head examined ;)

[LoRd_MuldeR]

I see. But I guess we won't use that for "movie" encodes with (almost) unrestricted key-frame interval and no "zero latency" requirement, right?

BTW: The DivX H.264 Decoder crashes when seeking in that stream ;)

[TEB]

Periodic Intra Refresh. The loss exists, but it's not that large when compared to having a similar keyframe interval (e.g. keyint=35 for a PAL SD video.)

More importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime HD encoding at zero latency.

In other words, x264 is now the greatest encoder in the world for realtime video applications, like videoconferencing, and anyone who uses anything else needs to have their head examined ;)

Awesomely cewl, do u have any reccomendations for a HD-SDI input card that would work with x264 in a workflow that can spew out Multicast? I wanna show the guys at work how good quality X264 can do vs a HW encoder for RT HD coding ,;) Now we just need to make a good RT workflow that will mux audio and put it into a container ;)
TE

[Disabled]

That looks and sounds awesome. That feature is part of the extended profile, is it? Would it be possible to refresh in different patterns than from top to bottom? Like in an interlaced pattern?
And do you know of any software using x264 for streaming? Like a videoconference app?

[Dark Shikari]

That looks and sounds awesome. That feature is part of the extended profile, is it?No, it's an encoder-side feature unrelated to profile.Would it be possible to refresh in different patterns than from top to bottom? Like in an interlaced pattern?Only if we enabled constrained intra prediction. All patterns that don't use constrained intra prediction must work from the top left to the bottom right (in some variation).And do you know of any software using x264 for streaming? Like a videoconference app?There are at least three low-latency x264-using apps in development.

[Blue_MiSfit]

Nice :) Merry Christmas, DS - and all the trolls on doom9 :D

~MiSfit

[Sharc]

more importantly, combined with other changes, this allows:

1. Zero encoder, decoder, and buffer latency.
2. Error resilience up to 20-25% packet loss rates, using one-slice-per-packet.
3. No keyframes beyond the first, so constant or capped framesize are both possible.
4. Realtime hd encoding at zero latency.

wow! :)

[Emulgator]

While trying to find a x264 setting that would import into Sony DVD-A 5.0b Build 180 (and probably Encore CS3 / DVDDitProHD 6.4):
x264r1376M (Jeeb) run from MeGUI 0.3.1.1060 zathor patched. Commandline by hand:
program --profile high --level 4 --crf 18 --thread-input --keyint 25 --min-keyint 2 --b-adapt 0 --interlaced --ref 4 --weightp 0 --qpmax 45 --ipratio 1.2 --pbratio 1.2 --vbv-maxrate 24000 --no-mbtree --trellis 2 --psy-rd 1.0:0.20 --no-mixed-refs --no-dct-decimate --aud --nal-hrd --sar 1:1 --output "output" "input"
DVD-A imports as .avc, does not announce transcoding (yippie), but fails on muxing.
Sony DVD-A 5.0b Build180 Error Report:
Dateiname: STREAM/00000.m2ts Status: TSWrapper.dll::CTSWrapper::ProcThreadMain::This program has a bug. - m_ptsOfNextGOP is empty.

Encodes made with x264r1376MJeeb (nal_hrd patched16(?) (looks ok, but fails on muxing)
vs.Sony Vegas 9.0c Build 896 as SONY AVC(muxes in DVD-A without transcoding, but looks ugly)

While examining and comparing these .avc elementaries I found the following missing entries suggesting that nal-hrd might not be embedded properly:
Screenshot x264 .avc mediainfo
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_mediainfo.png
Screenshot x264 .avc Stream Summary (my fault: no vbv) Screenshot Vegas 9 .avc Stream Summary Screenshot x264 .avc Stream Summary (now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_Stream_Summary.pnghttp://dvd-manufactur.de/files/20091226_Screenshot04_V9_Stream_Summary.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Stream_Summary.png
Screenshot x264 .avc Header NAL (my fault: no vbv) Screenshot Vegas 9 .avc Header NAL Screenshot x264 .avc Header NAL (now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_Header_NAL.pnghttp://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_NAL.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_NAL.png
Screenshot x264 .avc Header SPS (my fault: no vbv) Screenshot Vegas 9 .avc Header SPS top Screenshot x264 .avc Header SPS (now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot03_x264_Header_SPS.pnghttp://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_SPS_top.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_SPS.png
Screenshot Vegas 9 .avc Header SEI top Screenshot x264 .avc Header SEI top(now with vbv) Screenshot x264 .avc Header SEI bottom(now with vbv)
http://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_SEI_top.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_SEI_top.pnghttp://dvd-manufactur.de/files/20091226_Screenshot05_x264_Header_SEI_bottom.png
Screenshot Vegas 9 .avc Header SPS bottom
http://dvd-manufactur.de/files/20091226_Screenshot04_V9_Header_SPS_bottom.png

Could it be that other nal-hrd patched builds work somewhere else
or can I assume that the patch itself is broken
or is it driver error on my side?

[nurbs]

You haven't specified --vbv-bufsize which is needed if you want nal-hrd to work.

It is possible that blu-ray only allows for 3 reference frames, but I'm not sure about that since I never encode for blu-ray.

[shon3i]

It is possible that blu-ray only allows for 3 reference framesIt allow 4 for 1080 and 6 for 720/576/480 @ level 4.1 and 4.0

[Emulgator]

You haven't specified --vbv-bufsize which is needed if you want nal-hrd to work.

Oh shame, I forgot. Coming from the Blu-ray presets and dreaming all is fine...
I will repeat that with --vbv-bufsize = 30000.

--mvrange = 511 was missing too in CL, but is default anyway now, my luck.

In x264 output I am seeing log2_max_mv_length_horizontal coming out as 2^10 = 1024.
Not sure about the interpretation, but anyway, no showstopper.

Sony AVC is coming out of Vegas and passes muxing with a log2_max_mvrange_length_horizontal of 2^16...
_________________________________________________________________________________

P.S Yep, driver error on my side, nal_hrd is written now. Further testing for muxer acceptance...
_________________________________________________________________________________

Back from testing: The report is still there (Sony DVD-A 5.0b Build 180):
("Dateiname: STREAM/00000.m2ts Status: TSWrapper.dll::CTSWrapper::ProcThreadMain:
This program has a bug. - m_ptsOfNextGOP is empty")

[shon3i]

Try with keyint 50

[Emulgator]

encoding keyint 50 now...

BTW, DVD-A sees 4 refs as ok for not transcoding in L4.0 (slices=0)
and L4.1 (slices=4).

Seems that in L4.0 (slices=0) I just have to take care to take bitrates down, no further restrictions.
Right now using L4.0 with 12Mbps-16Mbit-18Mbps as in Vegas's max AVC preset
were not scheduled for trancoding, but failed on muxing.
____________________________________________________________________

Finished encoding, importing without transcoding attempt,
muxing fails, the error message stays as above.

More tomorrow.

[Lyris]

Emulgator, sorry I can't advise on your problem - but what program are you using to generate the "Stream Summary" and "Header Info" windows?

[ACrowley]

Is b-pyramid +mbtree stable (generally and for HW Players )with latest x264 rev 1376 ?

[Fr4nz]

Is b-pyramid +mbtree stable (generally and for HW Players )with latest x264 rev 1376 ?

Yes it is.