Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th January 2012, 08:32   #1  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 213
x264 v2145 64bit bug?

Hi,

First of all I want to say that I have to go to work and I haven't further investigated, but after a quick test with latest x264 v2145 64bit from x264.nl I'm having image corruption as you can see here:



I've used the usual settings I've being using since long time ago without any problem with previous versions:

Code:
x264-64.exe "sample.m2ts" --bluray-compat --preset veryslow --tune film --force-cfr --b-pyramid strict --open-gop --bitrate 20000 --level 4.1 --aud --nal-hrd vbr --pic-struct --sar 1:1 --vbv-bufsize 30000 --keyint 24 --ipratio 1.1 --vbv-maxrate 38000 --threads auto --slices 4 --thread-input --stats "D:\stats.stats" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --pass 1 --output NUL

x264-64.exe "sample.m2ts" --bluray-compat --preset veryslow --tune film --force-cfr --b-pyramid strict --open-gop --bitrate 20000 --level 4.1 --aud --nal-hrd vbr --pic-struct --sar 1:1 --vbv-bufsize 30000 --keyint 24 --ipratio 1.1 --vbv-maxrate 38000 --threads auto --slices 4 --thread-input --stats "D:\stats.stats" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --pass 2 --output "test.264"
Has anybody found the same problem?
chompy is offline   Reply With Quote
Old 17th January 2012, 08:35   #2  |  Link
mariush
Registered User
 
Join Date: Dec 2008
Posts: 589
Did you try exporting that m2ts file to a raw YUV file to see if the bug is not in the decoding libraries?
mariush is offline   Reply With Quote
Old 17th January 2012, 08:55   #3  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
Having reported to mail-list already. I believe it to be a bug in CABAC trellis. Use --trellis 0 to turn trellis off and see if those frames are still corrupt or not.

Last edited by 06_taro; 17th January 2012 at 08:57.
06_taro is offline   Reply With Quote
Old 18th January 2012, 09:39   #4  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 213
I've tried with avisynth and I get the same kind of corruptions, so this isn't a problem related to ffmpeg/libav... So as 06_taro has said it seems to be a bug in new CABAC optimizations made in last release.
chompy is offline   Reply With Quote
Old 18th January 2012, 13:06   #5  |  Link
Magix_995
Registered User
 
Join Date: Feb 2009
Posts: 9
No problem w/Trellis=2 here ...
Hmmm
Magix_995 is offline   Reply With Quote
Old 18th January 2012, 16:54   #6  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 213
Quote:
Originally Posted by Magix_995 View Post
No problem w/Trellis=2 here ...
Hmmm
I'm also using --trellis 2 (default value for veryslow preset), are you using 64bit or 32bit x264?

I've had to return to r2120 to get rid of these corruptions.
chompy is offline   Reply With Quote
Old 18th January 2012, 17:05   #7  |  Link
Magix_995
Registered User
 
Join Date: Feb 2009
Posts: 9
I use kmod x64 build from komisar...

Tested on B/W ...
Magix_995 is offline   Reply With Quote
Old 18th January 2012, 17:40   #8  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
Not all the videos encoded by rev2145 with trellis are corrupt. I tested on about 20 clips, and only 4 of them were broken.
06_taro is offline   Reply With Quote
Old 19th January 2012, 09:24   #9  |  Link
shroomM
Registered User
 
Join Date: Dec 2005
Location: Slovenia
Posts: 55
Fixed:
http://git.videolan.org/gitweb.cgi?p...c2b9635cf9d58d
shroomM is offline   Reply With Quote
Old 19th January 2012, 13:49   #10  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 480
Does anyone know if the x264.nl builds are already fixed as the page now lists this fix in the r2145 changelog.
Rumbah is offline   Reply With Quote
Old 19th January 2012, 14:09   #11  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
x264.nl has just updated to r2146 (try F5, if you can't see it yet).
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 19th January 2012, 14:17   #12  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 480
Ah, thanks, now I can see it.
Rumbah is offline   Reply With Quote
Old 19th January 2012, 14:29   #13  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,297
Can someone with broken results (chompy and/or 06_taro) confirm that new 2146 version fix the problem ?
As one of the files modified is an asm x64 specific file, one confirmation of fix should at least be with an x64 version.

Last edited by jpsdr; 19th January 2012 at 18:11.
jpsdr is offline   Reply With Quote
Old 19th January 2012, 14:40   #14  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
Confirmed. All the broken frames are fine with rev2146.
06_taro is offline   Reply With Quote
Old 19th January 2012, 20:35   #15  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 213
With my test file r2146 also works ok, no more corruption.
chompy is offline   Reply With Quote
Old 20th January 2012, 00:14   #16  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 480
Wow, the speed increase is great, for my typical PSP encode it's 36% for the 32bit version. Only 11% for the 64bit version but as my Q9650 is only used by three quartes I guess another part of x264 aside from CABAC is the bottleneck there. Probably b-adapt 2 with 8 b-frames (preset veryslow).
Rumbah is offline   Reply With Quote
Old 21st January 2012, 07:13   #17  |  Link
jassenjj
Registered User
 
Join Date: Jan 2012
Posts: 5
Can you please compare the speed in the 32 and the 64bit versions? I always use the 64bit version but with your numbers of speed increase what's the final result?
jassenjj is offline   Reply With Quote
Old 21st January 2012, 15:15   #18  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 480
I used an uncompressed 480x272 YV12 file off a RAM disk.
The results are:
Code:
r2106 RAM
Source: Q:\AviSynth Script (neu) (2).avs
Preset: Veryslow
Tuning: Film
Profile: Main
Params: --level 3 --ref 3 --b-pyramid none

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 7001 frames, 56.57 fps, 220.19 kb/s
encoded 7001 frames, 55.51 fps, 220.19 kb/s
encoded 7001 frames, 56.64 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 7001 frames, 62.16 fps, 220.19 kb/s
encoded 7001 frames, 76.56 fps, 220.19 kb/s
encoded 7001 frames, 73.28 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 7001 frames, 76.37 fps, 220.19 kb/s
encoded 7001 frames, 76.61 fps, 220.19 kb/s
encoded 7001 frames, 77.51 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 7001 frames, 77.55 fps, 220.19 kb/s
encoded 7001 frames, 77.30 fps, 220.19 kb/s
encoded 7001 frames, 77.64 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 7001 frames, 77.54 fps, 220.19 kb/s
encoded 7001 frames, 76.99 fps, 220.19 kb/s
encoded 7001 frames, 77.50 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 7001 frames, 62.41 fps, 220.19 kb/s
encoded 7001 frames, 77.04 fps, 220.19 kb/s
encoded 7001 frames, 77.00 fps, 220.19 kb/s

r2146 RAM

Source: Q:\AviSynth Script (neu) (2).avs
Preset: Veryslow
Tuning: Film
Profile: Main
Params: --level 3 --ref 3 --b-pyramid none

[Type: 32-Bit, Pipe Buffer Size: 0 MByte]
encoded 7001 frames, 75.10 fps, 220.19 kb/s
encoded 7001 frames, 75.65 fps, 220.19 kb/s
encoded 7001 frames, 76.23 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 0 MByte]
encoded 7001 frames, 86.33 fps, 220.19 kb/s
encoded 7001 frames, 86.78 fps, 220.19 kb/s
encoded 7001 frames, 86.76 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 1 MByte]
encoded 7001 frames, 86.58 fps, 220.19 kb/s
encoded 7001 frames, 72.98 fps, 220.19 kb/s
encoded 7001 frames, 86.79 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 2 MByte]
encoded 7001 frames, 86.54 fps, 220.19 kb/s
encoded 7001 frames, 86.40 fps, 220.19 kb/s
encoded 7001 frames, 72.94 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 4 MByte]
encoded 7001 frames, 73.35 fps, 220.19 kb/s
encoded 7001 frames, 73.17 fps, 220.19 kb/s
encoded 7001 frames, 75.01 fps, 220.19 kb/s

[Type: 64-Bit, Pipe Buffer Size: 8 MByte]
encoded 7001 frames, 74.16 fps, 220.19 kb/s
encoded 7001 frames, 86.93 fps, 220.19 kb/s
encoded 7001 frames, 86.84 fps, 220.19 kb/s
Rumbah is offline   Reply With Quote
Old 21st January 2012, 16:45   #19  |  Link
jassenjj
Registered User
 
Join Date: Jan 2012
Posts: 5
Wow, this is what I call an answer!
Thank you very much - this is really informative...

It is a little bit strange that with bigger pipe buffer some of the results are worse, but I won't make big conclusions from this.
jassenjj is offline   Reply With Quote
Old 22nd January 2012, 15:03   #20  |  Link
shroomM
Registered User
 
Join Date: Dec 2005
Location: Slovenia
Posts: 55
Wow, a great answer, indeed!

The speed difference between the 32-bit and 64-bit with 2MB Pipe Buffer Size is definitely noticeable.
shroomM is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:39.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.