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. |
12th March 2006, 18:58 | #1 | Link |
clueless n00b
Join Date: Oct 2001
Location: somewhere over the rainbow
Posts: 10,579
|
x264 cli bugreports
This thread is for x264.exe bugeports only. VfW users please go here
__________________
For the web's most comprehensive collection of DVD backup guides go to www.doom9.org |
12th March 2006, 22:59 | #3 | Link | |
Does it really matter?
Join Date: Jun 2004
Location: Chicago, IL
Posts: 1,542
|
Quote:
|
|
16th March 2006, 23:42 | #8 | Link |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
Note of informative character.
There was an AQ patch aplied for revs 466 and higher. AQ from Sharktooth old build (380-400) wasn't at state of art but somehow brings better quality at (very) low bitrate. New unofficial AQ patch of 466 doesn't do even half of that. Some guys are still compiling new rev + AQ patch for test only. Last edited by IgorC; 16th March 2006 at 23:48. |
17th March 2006, 05:20 | #9 | Link | |
Registered User
Join Date: Jan 2005
Posts: 191
|
Quote:
|
|
28th June 2007, 14:14 | #10 | Link |
Registered User
Join Date: Jun 2007
Posts: 1
|
Grey frames in x264 encoded HD videos using ffmpeg
Hi I already shot this to the x264-devel mailinglist and got an answer there. Unfortunately I could not do much with the answer, because it was technically to special for me.
Maybe here someone can help me: ------------------ Original message: ------------------ I am trying to encode different movies to h264 using ffmpeg and x264. The system where the encoding happens, is a 64bit Gentoo linux (stage 3). I tried different parameters of ffmpeg but can not get rid of the grev fog in black areas of the videos. The problem appears only on some frames and lasts different times. It seems that it depends on the GOP setting: When I set GOP to high (300 or more), the problem apears only some times but always on the same input files and the same time. ffmpeg shows an output of the library telling something about an overflow. I will attach some screenshots of the problem and a logfile. Greetings G.K. GOP size of 18 user ~> ffmpeg -y -i Speedball2_Trailer3.mov -vcodec h264 -b 7000k -bf 3 -g 18 -s 1280x720 -acodec mp3 -ab 96k Speedball2_Trailer3.avi FFmpeg version SVN-r9361, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --enable-libxvid --enable-libmp3lame --enable-libfaac --enable-gpl --enable-libx264 --enable-libfaad --enable-shared libavutil version: 49.4.0 libavcodec version: 51.40.4 libavformat version: 51.12.1 built on Jun 19 2007 10:33:31, gcc: 4.1.1 (Gentoo 4.1.1-r3) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ac7d7afc040]negative ctts, ignoring Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Speedball2_Trailer3.mov': Duration: 00:01:53.0, start: 0.000000, bitrate: 8215 kb/s Stream #0.0(eng): Audio: mpeg4aac, 48000 Hz, stereo Stream #0.1(eng): Video: h264, yuv420p, 1280x720, 29.01 fps(r) Output #0, avi, to 'Speedball2_Trailer3.avi': Stream #0.0: Video: libx264, yuv420p, 1280x720, q=2-31, 7000 kb/s, 29.01 fps(c) Stream #0.1: Audio: libmp3lame, 48000 Hz, stereo, 96 kb/s Stream mapping: Stream #0.1 -> #0.0 Stream #0.0 -> #0.1 [libx264 @ 0x2ac7d7fcb790]using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow! Press [q] to stop encoding [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 frame= 10 fps= 0 q=4.0 size= 15kB time=0.2 bitrate= 607.8kbits/s frame= 20 fps= 20 q=4.0 size= 20kB time=0.6 bitrate= 291.2kbits/s [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 frame= 27 fps= 17 q=2.0 size= 110kB time=0.8 bitrate=1133.2kbits/s frame= 32 fps= 16 q=4.0 size= 243kB time=1.0 bitrate=2064.4kbits/s (...) frame= 229 fps= 13 q=6.0 size= 7151kB time=7.8 bitrate=7553.6kbits/s [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 frame= 236 fps= 13 q=4.0 size= 7179kB time=8.0 bitrate=7354.3kbits/s (...) frame= 255 fps= 13 q=2.0 size= 7212kB time=8.7 bitrate=6828.8kbits/s [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377 frame= 262 fps= 13 q=4.0 size= 7277kB time=8.9 bitrate=6703.5kbits/s frame= 269 fps= 13 q=2.0 size= 7402kB time=9.1 bitrate=6638.8kbits/s [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4219 [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4219 frame= 276 fps= 13 q=4.0 size= 7580kB time=9.4 bitrate=6623.1kbits/s (...) frame= 289 fps= 13 q=4.0 size= 8072kB time=9.8 bitrate=6731.7kbits/s [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4141 [libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4141 frame= 293 fps= 13 q=3.0 size= 8342kB time=10.0 bitrate=6860.5kbits/s frame= 299 fps= 13 q=6.0 size= 8635kB time=10.2 bitrate=6957.1kbits/s frame= 304 fps= 13 q=7.0 size= 8928kB time=10.3 bitrate=7073.6kbits/s (...) no more errors here... (...) frame= 3280 fps= 8 q=-1.0 Lsize= 94184kB time=113.0 bitrate=6826.9kbits/s video:92660kB audio:1325kB global headers:0kB muxing overhead 0.211337% [libx264 @ 0x2ac7d7fcb790]slice I:186 Avg QP:20.54 size: 51168 [libx264 @ 0x2ac7d7fcb790]slice P:912 Avg QP:21.22 size: 41287 [libx264 @ 0x2ac7d7fcb790]slice B:2182 Avg QP:23.47 size: 21864 [libx264 @ 0x2ac7d7fcb790]mb I I16..4: 54.4% 0.0% 45.6% [libx264 @ 0x2ac7d7fcb790]mb P I16..4: 50.0% 0.0% 0.0% P16..4: 26.8% 0.0% 0.0% 0.0% 0.0% skip:23.2% [libx264 @ 0x2ac7d7fcb790]mb B I16..4: 22.2% 0.0% 0.0% B16..8: 42.0% 0.0% 0.0% direct: 3.5% skip:32.3% [libx264 @ 0x2ac7d7fcb790]final ratefactor: 19.80 [libx264 @ 0x2ac7d7fcb790]SSIM Mean Y:0.9796557 [libx264 @ 0x2ac7d7fcb790]kb/s:6714.0 Same video with GOP size of 500: FFmpeg version SVN-r9361, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --enable-libxvid --enable-libmp3lame --enable-libfaac --enable-gpl --enable-libx264 --enable-libfaad --enable-shared libavutil version: 49.4.0 libavcodec version: 51.40.4 libavformat version: 51.12.1 built on Jun 19 2007 10:33:31, gcc: 4.1.1 (Gentoo 4.1.1-r3) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2b2e462d5040]negative ctts, ignoring Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Speedball2_Trailer3.mov': Duration: 00:01:53.0, start: 0.000000, bitrate: 8215 kb/s Stream #0.0(eng): Audio: mpeg4aac, 48000 Hz, stereo Stream #0.1(eng): Video: h264, yuv420p, 1280x720, 29.01 fps(r) Output #0, avi, to 'Speedball2_Trailer3.avi': Stream #0.0: Video: libx264, yuv420p, 1280x720, q=2-31, 7000 kb/s, 29.01 fps(c) Stream #0.1: Audio: libmp3lame, 48000 Hz, stereo, 96 kb/s Stream mapping: Stream #0.1 -> #0.0 Stream #0.0 -> #0.1 [libx264 @ 0x2b2e467a4790]using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow! Press [q] to stop encoding [libx264 @ 0x2b2e467a4790]OVERFLOW levelcode=4377 [libx264 @ 0x2b2e467a4790]OVERFLOW levelcode=4377 frame= 11 fps= 0 q=4.0 size= 16kB time=0.2 bitrate= 531.6kbits/s (...) no more errors here (...) video:92413kB audio:1325kB global headers:0kB muxing overhead 0.211776% [libx264 @ 0x2b2e467a4790]slice I:7 Avg QP:20.43 size: 44850 [libx264 @ 0x2b2e467a4790]slice P:824 Avg QP:21.02 size: 44524 [libx264 @ 0x2b2e467a4790]slice B:2449 Avg QP:22.98 size: 23531 [libx264 @ 0x2b2e467a4790]mb I I16..4: 54.0% 0.0% 46.0% [libx264 @ 0x2b2e467a4790]mb P I16..4: 54.3% 0.0% 0.0% P16..4: 24.3% 0.0% 0.0% 0.0% 0.0% skip:21.4% [libx264 @ 0x2b2e467a4790]mb B I16..4: 22.7% 0.0% 0.0% B16..8: 42.8% 0.0% 0.0% direct: 3.8% skip:30.8% [libx264 @ 0x2b2e467a4790]final ratefactor: 19.50 [libx264 @ 0x2b2e467a4790]SSIM Mean Y:0.9798082 [libx264 @ 0x2b2e467a4790]kb/s:6696.5 While GOP below 10 produces a lot of errors... ------ Reply: ------ When encoding CAVLC in Baseline or Main profile, there is a limit on the size of any one DCT coefficient. This limit can only be reached with very low QP or with extreme quantization matrices, so it shouldn't normally be a problem, but ffmpeg has lousy defaults (such as min QP=2) which allow such extreme cases. And even though larger values are allowed in High profile (it needs them to represent higher sample depth), I haven't implemented that in x264. There is no direct relation between GOP size and overflow, though I-frames are lower QP than P-frames and I-blocks are more likely to contain large coefficients than P-blocks. (pick any one of the following) What you can do about it without modifying any source code: Enable CABAC. Set min QP to something reasonable (like x264's default 10). What you can do about it with modifying source code: Add codec-specific defaults in ffmpeg so that h264 doesn't default to insane settings. Make x264 encode that coefficient using High profile's larger level_code, resulting in a syntactically valid stream but violating profile constraints. Make x264 re-encode the macroblock with a higher QP. Make x264 re-decode the macroblock so that the reconstructed picture matches the bitstream; there will still be an artifact but it will be localized to a few blocks and fixed in the next frame. Last edited by mindphuk; 28th June 2007 at 14:18. |
28th June 2007, 15:45 | #11 | Link | |
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
Quote:
To get an encode with reasonable quality instead of trash, you should also tweak other parameters. Take a look at Robert Swain's FFmpeg x264 encoding guide. |
|
10th December 2007, 01:48 | #12 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
Same input file, same options but different produced file
I found that x264 produces different files for my sample file when using next options:
Code:
x264.exe -B 800 --8x8dct -A p8x8,i8x8,i4x4 --me umh --subme 6 --trellis 2 --threads 5 --quiet --no-psnr --no-ssim -o output.264 test.avi |
10th December 2007, 04:12 | #14 | Link |
x264aholic
Join Date: Jul 2007
Location: New York
Posts: 1,752
|
Especially with that many threads.. If you're encoding at sub-HD resolutions on a dual core, you'll run into that kind of problem. Unless you actually have more than 2 cores I'd advise against using that many threads.
|
11th December 2007, 00:47 | #16 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
As check rightly said it must be deterministic indifferently how much threads it use if not using --non-deterministic option. If you add --non-deterministic to my options all files will be different, but without it only some rare files are different (that is why I create 100 files) due to some bug (it is not proposed behavior surely).
|
7th January 2008, 15:54 | #18 | Link |
Registered User
Join Date: Dec 2004
Location: Melbourne, AU
Posts: 1,963
|
The matroska writer seems to leak small amounts of memory. I made some small changes to matroska.c:
Code:
static void mk_destroyContexts(mk_Writer *w) { mk_Context *cur, *next; for (cur = w->freelist; cur; cur = next) { next = cur->next; free(cur->data); free(cur); } for (cur = w->actlist; cur; cur = next) { next = cur->next; free(cur->data); free(cur); } for (cur = w->frame; cur; cur = next) { next = cur->next; free(cur->data); free(cur); } for (cur = w->root; cur; cur = next) { next = cur->next; free(cur->data); free(cur); } w->freelist = w->actlist = w->root = w->frame = NULL; } |
18th June 2008, 04:00 | #19 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Hey, I updated to the newest rev of x264 (r886), and i'm coming across some problems when running it after compilation in VC9.
It constantly throws exceptions when trying to run it with asm optimizations. However, when i turn off asm it runs just fine. So has there been a regression in the asm code to be incompatible with VC? since the precompiled mingw one on the site still runs fine... --- in the VC debugger it prints off movaps xmm0,xmmword ptr [esi+ecx] for Unhandled exception at 0x004373a2 in x264.exe: 0xC0000005: Access violation reading location 0x00000000. --- Running on an AMD Athlon 64 X2 4200+ (Manchester) on XP x64 detected ASM opts (when enabled) are MMX2 and SSE2Slow |
Thread Tools | Search this Thread |
Display Modes | |
|
|