|
|
This thread is for x264.exe bugeports only. VfW users please go here
x264 won't output stats in crf mode even if told to. More feature request than bug. I guess I should have checked here before asking for it in Megui!
Originally Posted by foxyshadisx264 won't output stats in crf mode even if told to. More feature request than bug. I guess I should have checked here before asking for it in Megui!
what kind of stats are you talking about? Are you talking about Time, fps, bitrate?
Sorry, I meant --stats quot;x.statsquot; for use if the crf is unsatisfactory and a second pass needs to be run at a higher bitrate.
Do you have quot;--pass 1quot; in your commandline?
No, and it works with it. That's why I was so confused, since I was sure it'd been working last week! Thanks.
Well, then you didn't tell it to output stats.
quot;--statsquot; just specifies a filename, and is not required (there is a default name). You also need a --pass 1/2/3 to tell it what to do with the statsfile.
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.
Originally Posted by IgorCAQ 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.
Looking at the source both AQ patches (398 and 466) seem almost identical. Akupenguin just replaced quot;h-gt;mb.pic.i_stride[x]quot; with quot;FENC_STRIDEquot; (whatever that means) and aligned the new patch offsets with a most recent 466 revision, so at first I thought they were only cosmetic changes. But I just did 2 tests with both patches and got different encodes - the 398 encode was identical to an encode without --aq-strength and --aq-sensitivity at all (a phenomenon already discussed here), while the 466 produced a lower PSRN encode, but with better looking flat backgrounds (to my eyes). I'm still unsure which patch quot;is betterquot;, 398 or 466, or what sets of --aq-strength and --aq-sensitivity options really make difference and in what cases. It's obvious that AQ needs some thorough analysis by the devs in the future, that's why it's not in the SVN, so use AQ for nothing but tests only. I just posted both 398 and 466 AQ builds here
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 ~gt; 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 -gt; #0.0 Stream #0.0 -gt; #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 -gt; #0.0 Stream #0.0 -gt; #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.
What you can do about it without modifying any source code:
Enable CABAC.
Set min QP to something reasonable (like x264's default 10).
You were suggested to use ffmpeg parameters -coder 1 -qmin 10
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.
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
I think that this bug somehow connected with use of multithreading. I suggest that it is somewhere in encoder\analyse.c x264_mb_analyse_init function but I am not sure. For testing I attached archive with my samle file and cmd-file for automation (it produces 100 files with my options).
It may be because using threads leads to non-deterministic encoding, so it's rather a feature.
Originally Posted by imcoldIt may be because using threads leads to non-deterministic encoding, so it's rather a feature.
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.
No, x264 should still be deterministic with multiple threads. It is only not when you set --non-deterministic.
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).
I see... sorry, my bad.
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-gt;freelist; cur; cur = next) { next = cur-gt;next; free(cur-gt;data); free(cur); }
for (cur = w-gt;actlist; cur; cur = next) { next = cur-gt;next; free(cur-gt;data); free(cur); }
for (cur = w-gt;frame; cur; cur = next) { next = cur-gt;next; free(cur-gt;data); free(cur); }
for (cur = w-gt;root; cur; cur = next) { next = cur-gt;next; free(cur-gt;data); free(cur); }
w-gt;freelist = w-gt;actlist = w-gt;root = w-gt;frame = NULL;
}which seems to have fixed it. I didn't really spend much time on it though, should probably be checked more closely.
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
Originally Posted by kemuri-_9So has there been a regression in the asm code to be incompatible with VC?
Yes, SSE2 deblocking causes a crash with any compiler that doesn't correctly preserve stack alignment. |
|
Post at 2011-4-15 14:29
| This Author's Posts Only
