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

[3ngel]

A separate program can implement the buffer. There are several buffered-pipe programs around, such as bfr. This works well on Linux, and helps even when feeding x264 from a local but bursty source, e.g. mplayer -vo yuv4mpeg:file=pipe.y4m. See my post here:
http://forum.doom9.org/showthread.php?p=1206916#post1206916

Yes, i see thanks, but i'm running under windows.

I think an option like --FrameBuffer NumFrames, would not so hard to develop, and it would simplify things even in your case :)
I hope this suggestion will be considered sometime.
Thanks.

[MasterNobody]

Here is my patch collection for x264 (for revision 1019), most of which I use in my builds of x264vfw: http://stashbox.org/288851/bm_x264_patch_collection.r1019.zip.

Description of included patches:
'independent' dir:
x264_cosmetic.r1019.diff - cosmetic fix for warning "C4028: formal parameter 2 different from declaration" when compiling with VS2008.
x264_cost_mv_memoryleaks.r1019.diff - fixes memoryleaks of mvs cost arrays (not very important for x264 CLI, but useful when using x264 as shared library).
x264_custom_strtok_r.r1019.diff - fixes incorrect zones parsing at Windows (due the use of non reentrant version of strtok_r). For example, with command line "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv".
x264_debug_defines.r1019.diff - add defines '_DEBUG' / 'NDEBUG' when compile with gcc (using 'configure').
x264_error_memoryleaks.03.r1019.diff - fixes different memoryleaks when error happens durring 'x264_encoder_open', 'x264_ratecontrol_new', 'parse_zone', 'parse_zones'. Also fix incorrect memory allocation 'z->param' in 'parse_zone' (allocated with 'malloc' but frees with 'x264_free').
x264_fix_crash_cqp_and_vbv.r1019.diff - fixes crash with command line "x264.exe --qp 26 --vbv-maxrate 20000 --vbv-bufsize 25000 -o test.mkv foreman_cif_352x288.yuv".
x264_fix_stats_file_work.r1019.diff - add some workarounds for work with stats file (not very important for x264 CLI, but useful for applications which use x264 as library and expects "one in - one out" behaviour, for example x264vfw).
x264_multithreading_bug_check.r1019.diff - enables one bug check for multithreading for release builds which originally used only for debug builds.
x264_thread_pool.r1019.diff - adds thread-pool feature (slighly improves multithreading).
x264_vaqmod.05.r1019.diff - some modifications of VAQ (adds support for command line options '--aq-metric' and '--aq-sensitivity').

'misc' dir:
x264_disable_hadamard_ac_on_mod4_stack.r1019.diff - disables 'hadamard_ac' SSE2/SSSE3 optimizations when compiled with VS due the crash (general-protection exception) (fixed version of http://mailman.videolan.org/pipermail/x264-devel/2008-October/005069.html).
x264_vs_project.r1019.diff - removes 'eval.c' from VS project files (http://mailman.videolan.org/pipermail/x264-devel/2008-October/005050.html).
x264_x64_compilation.r1019.diff - fixes error "LNK2001: unresolved external symbol x264_pixel_avg2_w20_cache64_mmxext" when compiling for x64 platform (at least in VS).
'vs2008' dir - project files for VS2008 (not only update of current project files).

'batch' dir - same patches as in 'independent', but keeps in mind possible conflicts in applying.

[Dark Shikari]

x264_cost_mv_memoryleaks.r1019.diff - fixes memoryleaks of mvs cost arrays (not very important for x264 CLI, but useful when using x264 as shared library).How is this a memory leak? These arrays will be initialized only once, no matter how many times you instance x264 as a shared library, and will be shared between all running processes.

Your change, as far as I can tell, actually breaks things because if you instanced x264 twice using the same library and one of the encodes finished before the other, it would proceed to free all the arrays used by the second instance, instantly crashing the other encode. In other words, with this patch, it becomes impossible to make multiple simultaneous encoder_encode calls from a single application.

Patch tentatively rejected.x264_debug_defines.r1019.diff - add defines '_DEBUG' / 'NDEBUG' when compile with gcc (using 'configure').Patch rejected, a significant bit of crash-avoidance code is under NDEBUG, and this patch disables it, risking crashes during encoding. I see you have another patch which makes this not dependent on NDEBUG; does that even leave NDEBUG used anywhere else in the entire program? I'd rather just remove NDEBUG completely.
x264_cosmetic.r1019.diff - cosmetic fix for warning "C4028: formal parameter 2 different from declaration" when compiling with VS2008.
x264_fix_crash_cqp_and_vbv.r1019.diff - fixes crash with command line "x264.exe --qp 26 --vbv-maxrate 20000 --vbv-bufsize 25000 -o test.mkv foreman_cif_352x288.yuv".
x264_disable_hadamard_ac_on_mod4_stack.r1019.diff - disables 'hadamard_ac' SSE2/SSSE3 optimizations when compiled with VS due the crash (general-protection exception) (fixed version of http://mailman.videolan.org/pipermail/x264-devel/2008-October/005069.html).
x264_vs_project.r1019.diff - removes 'eval.c' from VS project files (http://mailman.videolan.org/pipermail/x264-devel/2008-October/005050.html).Patches approved.
x264_x64_compilation.r1019.diff - fixes error "LNK2001: unresolved external symbol x264_pixel_avg2_w20_cache64_mmxext" when compiling for x64 platform (at least in VS).Patch rejected; the bug is in mc-c.c, not in the assembly file:

#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
#endif
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
should be
#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
#endif
x264_custom_strtok_r.r1019.diff - fixes incorrect zones parsing at Windows (due the use of non reentrant version of strtok_r). For example, with command line "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv".Tentatively rejected until you explain exactly what the problem is. "incorrect" does not tell me anything.
x264_error_memoryleaks.03.r1019.diff - fixes different memoryleaks when error happens durring 'x264_encoder_open', 'x264_ratecontrol_new', 'parse_zone', 'parse_zones'. Also fix incorrect memory allocation 'z->param' in 'parse_zone' (allocated with 'malloc' but frees with 'x264_free').Tentatively approved, pengvado will need to look at this one.
x264_fix_stats_file_work.r1019.diff - add some workarounds for work with stats file (not very important for x264 CLI, but useful for applications which use x264 as library and expects "one in - one out" behaviour, for example x264vfw).Patch rejected. x264's API is explicitly not one-in-one-out. VFW workarounds will never ever be accepted into the main tree for any reason.
compiling for x64 platformYou got x264 working on x64 Windows? Can you post the assembly calling convention patch you used?

[akupenguin]

These arrays will be initialized only once, no matter how many times you instance x264 as a shared library, and will be shared between all running processes.
Shared between all invocations of x264 within one process (which is sufficient to make it not a leak). Shared between processes only if they forked after initializing x264. Further sharing would violate virtual memory protections. Unfortunately there's no way to allow sharing between multiple processes without writing the entire contents of the array literally in the executable (and it requires some contortions in the source code too).

+#undef strtok_r //pthread.h can already define own variant (non reentrant version)
What is a non reentrant version of strtok_r? The sole difference between strtok and strtok_r is that strtok_r is reentrant and strtok isn't.

[MasterNobody]

How is this a memory leak? These arrays will be initialized only once, no matter how many times you instance x264 as a shared library, and will be shared between all running processes.

Your change, as far as I can tell, actually breaks things because if you instanced x264 twice using the same library and one of the encodes finished before the other, it would proceed to free all the arrays used by the second instance, instantly crashing the other encode. In other words, with this patch, it becomes impossible to make multiple simultaneous encoder_encode calls from a single application.
May be you right.
Patch rejected, a significant bit of crash-avoidance code is under NDEBUG, and this patch disables it, risking crashes during encoding. I see you have another patch which makes this not dependent on NDEBUG; does that even leave NDEBUG used anywhere else in the entire program? I'd rather just remove NDEBUG completely.
The main idea of defining NDEBUG is to disable assert checks in release builds (to get little more speed).
Patch rejected; the bug is in mc-c.c, not in the assembly file:
#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
#endif
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
should be
#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
#endif
But that is exactly what I change in my patch (it doesn't change any assembly file).
Tentatively rejected until you explain exactly what the problem is. "incorrect" does not tell me anything.
"incorrect" means that you will get "x264 [error]: failed to parse zones" for command line: "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv"
Patch rejected. x264's API is explicitly not one-in-one-out. VFW workarounds will never ever be accepted into the main tree for any reason.
That was expected.
You got x264 working on x64 Windows? Can you post the assembly calling convention patch you used?
No. x264_x64_compilation.r1019.diff and vs2008 project files was the first step before hacking assembly files (with no luck).
What is a non reentrant version of strtok_r? The sole difference between strtok and strtok_r is that strtok_r is reentrant and strtok isn't.
I mean this from pthread.h:
#if !defined(__MINGW32__)
#define strtok_r( _s, _sep, _lasts ) \
( *(_lasts) = strtok( (_s), (_sep) ) )
#endif /* !__MINGW32__ */

[Dark Shikari]

The main idea of defining NDEBUG is to disable assert checks in release builds (to get little more speed).There are no asserts in speed-significant portions of the code. Those in non-speed-significant sections allow us to catch bugs in release builds.But that is exactly what I change in my patch (it doesn't change any assembly file).Oops, I apparently fail at reading. In that case, approved."incorrect" means that you will get "x264 [error]: failed to parse zones" for command line: "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv"Well that's obvious; asm isn't supposed to be an option allowed in zones.

[MasterNobody]

Well that's obvious; asm isn't supposed to be an option allowed in zones.
It fails not because of 'asm' option (I use it only to show the worst variant for zones). It will fail even without 'asm' (with command line: "x264.exe --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv"). The course of the fail is nested use of 'strtok' (because in Windows there is no 'strtok_r') in 'parse_zones'->'parse_zone'->'x264_param_parse' (in worst case of using 'asm' option) which is non reentrant and after second call with not NULL first param in 'parse_zone' will return incorrect results in 'parse_zones' (will return NULL for second zone).

[skystrife]

2^10 GET!

x264.1024.modified.exe (http://www.mediafire.com/?d0jidzinmnm) - Alternate Download (http://skystrife.com/x264/x264.1024.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[kemuri-_9]

no fixing of the broken windows zone parser/strtok_r?

[bob0r]

[03:12] (pengvado): to fix the problem on windows, you would have to implement strtok_r in windows's libc
[03:12] (pengvado): anything else is a kludge, not a fix
[03:22] (pengvado): it's worse than nothing because it offends my aesthetics

[ACrowley]

Question : I follow the Level 4.1 HP Compliance Restriction for my x264 DXVA Compliant encodes

I always follow these Rules from Refernce Frames/resolution

|-----------|---------|
|Resolution | no. ref |
|-----------|---------|
| 1280x544 | 12 |
| 1280x720 | 9 |
| 1920x800 | 5 |
| 1920x816 | 5 |
| 1920x1080 | 4 |

Where there Changes last Time ? I do my encodes with megui Profil which is identical to Sharktooth DXVA HD HQ Profile,% 5 Ref Frames/1920x800/3 B frames/Level 4.1 HP and without B Pyramid, always with latest x264 Build from techhouse
DXVA works perfect with Cyberlink,Nero oder MPC HC Decoder.

But now i noticed that aencode with newest x264 Build in 1280x544 with 12 Ref Frames doesnt work with DXVA anymore ? Encodes with 12 Ref Frames on 1280x544 was fine in the Past so far i can remenber.
But now it only works with 9 Ref Frames ?
--pass 2 --bitrate 5150 --stats "E:\mo.stats" --level 4.1 --ref 9 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --deblock -2:-2 --subme 8 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 40000 --vbv-maxrate 50000 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "E:\mohikaner.mp4" "E:\m.avs"

1280x544 ,9 Ref Frames works fine with DXVA. The same with 12 Ref Frames not.

So, are there new Level 4.1 HP -Ref Frames Compliance Rules ?

[MasterNobody]

And what about:
x264_error_memoryleaks.03.r1019.diff - fixes different memoryleaks when error happens durring 'x264_encoder_open', 'x264_ratecontrol_new', 'parse_zone', 'parse_zones'. Also fix incorrect memory allocation 'z->param' in 'parse_zone' (allocated with 'malloc' but frees with 'x264_free').

Is it also rejected? If it is rejected than I want to know why (may be I can fix things that akupenguin/pengvado doesn't like in it).

[kemuri-_9]

that was addressed by both Dark Shikari and Akupenguin after you originally posted the patches.

well thanks for the info at least on the strtok_r not going to be fixed, so i just made my own patch for ratecontrol.c to get it to work on winblows.

[Sagekilla]

@ACrowley: DPB for Level 4.1 must be width * height * refs * 1.5 bytes <= 12441600 bytes so doing simple math you can get max refs:

1920x1080 = 4 refs
1920x816 = 5 refs (round down from 5.29)
1920x800 = 5 refs (round from 5.4)
1280x720 = 9 refs
1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.

[Betsy25]

@ACrowley: DPB for Level 4.1 must be width * height * refs * 1.5 bytes <= 12441600 bytes so doing simple math you can get max refs:

1920x1080 = 4 refs
1920x816 = 5 refs (round down from 5.29)
1920x800 = 5 refs (round from 5.4)
1280x720 = 9 refs
1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.

Hi,

Does the reference frames calculation also hold truth when using the Unrestricted level, and for lower resolutions ?

[Sagekilla]

That's the DPB for level 4.1. If you want to get L4.1 compatibility you must use a max DPB value of 12441600 bytes. Unrestricted means you're not conforming to levels or profiles, so DPB doesn't apply.

TBH, you only need to worry about DPB if you're encoding for compatibility. In this case, Level 4.1 is required for hardware acceleration and PS3 requires 4.1 for playback too.


tl;dr: DPB doesn't matter for unrestricted.

[Ranguvar]

that was addressed by both Dark Shikari and Akupenguin after you originally posted the patches.

well thanks for the info at least on the strtok_r not going to be fixed, so i just made my own patch for ratecontrol.c to get it to work on winblows.

Post please? I use Linux, but I'd still like to see it.

[Snowknight26]

Don't forget to round the height and width up to the 16 when calculating the # of reference frames.

[Comatose]

I'm also interested.

[video_magic]

Just saying thanks to everybody who has contributed their skills and time to x264, I've been amazed at the results I've been getting, including thankyou to MasterNobody - really appreciated here everybody.

[kemuri-_9]

Post please? I use Linux, but I'd still like to see it.

strtok_r is only used in three places, once in the param parser and twice in zone parsing.
because zone parser has two calls to strtok, using a non reentrant strtok causes the break.

(wtg winblows for not having strtok_r, causing the whole situation)
(if you could change asm in zones, then it would be a triple call - as that's where it's used in the param parser)
(^ this situation would really need a reentrant strtok)

so as such there's two ways of solving the current situation:
1. alter the zone parser to use only one call to strtok so a non reentrant strtok can be used. (as the one posted below does)
2. properly implement strtok_r. (as MasterNobody's patch does)

if a truly reentrant strtok_r was required in more locations, option #2 would be the choice to take.
But as there's only one spot, we can get away with doing #1, which has less code to get added.

So it's pretty much up to the person which fix they would want for this situation.
here's the patch for fix method #1:
x264_win_zone_parse_fix_r1024.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_r1024.diff)

[akupenguin]

While Microsoft isn't likely to care, you might be able to get a strtok_r implementation into mingw, and that would help more than just x264.

I might consider the patch that adds only 4 lines. But I seriously have a policy of not working around other people's bugs, no matter how easy it would be.

[Sharktooth]

more than a bug, that is a lack of implementation.

[Dark Shikari]

While Microsoft isn't likely to care, you might be able to get a strtok_r implementation into mingw, and that would help more than just x264.

I might consider the patch that adds only 4 lines. But I seriously have a policy of not working around other people's bugs, no matter how easy it would be.O rly? (http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=16b8f79bb6825053b6dd0eebb1d24c1bdf112fbb) ;)

[akupenguin]

You're right, I'm not being consistent. I'll go remove that kludge too.

[Dark Shikari]

You're right, I'm not being consistent. I'll go remove that kludge too.Already gone, when we added pixel.var().

[MasterNobody]

Here is updated my patch collection for x264 (for revision 1024): http://stashbox.org/290274/bm_x264_patch_collection.r1024.zip
Besides updating of some patches and removing of commited I also add new patch:
x264_inv_qscale_factor_memoryleak.r1024.diff - to fix new memoryleak after http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=7cdaf638c3777f2b38fb60181dde7ed4de614cc1

[Dark Shikari]

Here is updated my patch collection for x264 (for revision 1024): http://stashbox.org/290274/bm_x264_patch_collection.r1024.zip
Besides updating of some patches and removing of commited I also add new patch:
x264_inv_qscale_factor_memoryleak.r1024.diff - to fix new memoryleak after http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=7cdaf638c3777f2b38fb60181dde7ed4de614cc1Oops, seems I forgot to free that one as well... I'm getting into a rather bad habit of this.

I'll commit it along with the next batch of fixes.

[Audionut]

Revision 1026

x264-r1026.rar (http://rapidshare.com/files/162602312/x264-r1026.rar)

To many changes since my last build.

[kemuri-_9]

are there any other known kludges that aren't planned to be fixed us windoze users should be aware of?

[Snowknight26]

x264-r1026.rar (http://rapidshare.com/files/162602312/x264-r1026.rar)

Would be nice if you either included pthreadGC2.dll in the rar or compiled x264 with it.

[Audionut]

Hmm. I've broken something.

[Snowknight26]

Still occurs.

[Snowknight26]

Nope, still requires pthreadGC2.dll.

[Audionut]

Final fixed working version.
Thanks Snowknight26.

x264-r1026b.rar (http://rapidshare.com/files/162654279/x264-r1026b.rar)

[ACrowley]

@ACrowley: DPB for Level 4.1 must be width * height * refs * 1.5 bytes <= 12441600 bytes so doing simple math you can get max refs:

1920x1080 = 4 refs
1920x816 = 5 refs (round down from 5.29)
1920x800 = 5 refs (round from 5.4)
1280x720 = 9 refs
1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.


THX :)
Works fine now with 11 Ref Frames.

[azulazules]

@Sagekilla
Confused... Even though some DXVA enabled player cannot decode more than 11 refs (whatever the resolution the video is), isn't it 12MB (=12582912 Bytes) the DBP for h264 High@4.1?

Then High@4.1 for 1280x544 limit is 12 ref = integer(12MB*1024²/(1280px*544px*1.5Bytes)), or is it not ?

[Atak_Snajpera]

Then High@4.1 for 1280x544 limit is 12 ref = integer(12MB*1024²/(1280px*544px*1.5Bytes)), or is it not ?
Read carefully!

1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.

[Sagekilla]

I don't have the spec on hand, but I don't think the DPB for High@4.1 isn't 12 MB even, but ~11.86 MB (12441600).

[kemuri-_9]

Spec says that the MaxDPB for Levels 4.0 & 4.1 is 12880 KB;
12880 KB / 1024 (KB/MB) ~ 12.57 MB

it's listed in Table A-1, which is on page 283, (305 in the PDF (http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200711-I!!PDF-E&type=items))

[azulazules]

:cool: thanks Kemuri for your answer and the document.

Then max REF for 1280x544 at High@4.1 is really 12.
BTW: 12MB is 12288kB. :-)

[kemuri-_9]

yeah, the calculator failed me on that one :rolleyes:

[ACrowley]

Is there anything new about B-Pyramid ?
I mean Sharktooth has disabled B-Pyramid in his DXVA megui Profiles...

I encode DXVA Compliant....i always used B-Pramid in my encodes ,and i never had any Playback Problmes with mpc-hc or Cyberlink Decoder etc.

Is it safe to use B pyramid in DXVA Compliant encodes or not ?

[juGGaKNot]

Is it safe to use B pyramid in DXVA Compliant encodes or not ?

I also need this answer.

[LoRd_MuldeR]

Is it safe to use B pyramid in DXVA Compliant encodes or not ?I also need this answer.
As long as you calculate the number of ref frames accordingly, it should be safe to use b-pyramid.

[azulazules]

As long as you calculate the number of ref frames accordingly, it should be safe to use b-pyramid.

If I am right, then b-pyramid could make x264 produce video stream that could break DXVA.

The information that I read is that b-pyramid does break the DPB limits depending on the source video.
http://forum.doom9.org/showthread.php?t=140223

If #ref is set to X [--ref X] and b-pyramid is set, then x264 can actually produce X+Y refs video streams thus breaking DPB limit (which is 12MB for High@4.1).

[LoRd_MuldeR]

If I am right, then b-pyramid could make x264 produce video stream that could break DXVA.

The information that I read is that b-pyramid does break the DPB limits depending on the source video.
http://forum.doom9.org/showthread.php?t=140223

If #ref is set to X [--ref X] and b-pyramid is set, then x264 can actually produce X+Y refs video streams thus breaking DPB limit (which is 12MB for High@4.1).

That's why you have to take b-pyramid into account when you calculate the number of ref frames, right?

See this thread, for example:
http://forum.doom9.org/showthread.php?t=142758

(And no, as far as I understand, x264 requires the decoder to cache X+1 refs with "--ref X" and "--b-pyramid" set)

[skystrife]

x264.1028.modified.exe (http://www.mediafire.com/?ymtjozkd53n) - Alternate Download (http://skystrife.com/x264/x264.1028.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_r1024.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[ACrowley]

As long as you calculate the number of ref frames accordingly, it should be safe to use b-pyramid.


Casn you give me an example ?

i encode to 1920x800. So i use Level 4.1 HP with 5 Reframes

1920x800 / 816 = 5 Ref Frames
1920x1080 = 4 Refframes
1280x720 = 9
1280x544 =11

So, how do i have to claulate the Ref Frames accroding to these Rules ?

[Disabled]

Casn you give me an example ?

i encode to 1920x800. So i use Level 4.1 HP with 5 Reframes

1920x800 / 816 = 5 Ref Frames
1920x1080 = 4 Refframes
1280x720 = 9
1280x544 =11

So, how do i have to claulate the Ref Frames accroding to these Rules ?
x264 requires the decoder to cache X+1 refs
Thus you have to use one ref frame less: 4 with 1920x800, 3 with 1080p, 8 with 720p and 10 with 1280x544