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 12th March 2006, 18:58   #1  |  Link
Doom9
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
Doom9 is offline   Reply With Quote
Old 12th March 2006, 22:53   #2  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
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!
foxyshadis is offline   Reply With Quote
Old 12th March 2006, 22:59   #3  |  Link
ChronoCross
Does it really matter?
 
ChronoCross's Avatar
 
Join Date: Jun 2004
Location: Chicago, IL
Posts: 1,542
Quote:
Originally Posted by foxyshadis
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!
what kind of stats are you talking about? Are you talking about Time, fps, bitrate?
ChronoCross is offline   Reply With Quote
Old 12th March 2006, 23:03   #4  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Sorry, I meant --stats "x.stats" for use if the crf is unsatisfactory and a second pass needs to be run at a higher bitrate.
foxyshadis is offline   Reply With Quote
Old 13th March 2006, 09:36   #5  |  Link
GodofaGap
Registered User
 
Join Date: Feb 2006
Posts: 823
Do you have "--pass 1" in your commandline?
GodofaGap is offline   Reply With Quote
Old 13th March 2006, 10:21   #6  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
No, and it works with it. That's why I was so confused, since I was sure it'd been working last week! Thanks.
foxyshadis is offline   Reply With Quote
Old 13th March 2006, 13:41   #7  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
Well, then you didn't tell it to output stats.
"--stats" 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.
akupenguin is offline   Reply With Quote
Old 16th March 2006, 23:42   #8  |  Link
IgorC
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.
IgorC is offline   Reply With Quote
Old 17th March 2006, 05:20   #9  |  Link
hpn
Registered User
 
Join Date: Jan 2005
Posts: 191
Quote:
Originally Posted by IgorC
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.
Looking at the source both AQ patches (398 and 466) seem almost identical. Akupenguin just replaced "h->mb.pic.i_stride[x]" with "FENC_STRIDE" (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 "is better", 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
hpn is offline   Reply With Quote
Old 28th June 2007, 14:14   #10  |  Link
mindphuk
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.
mindphuk is offline   Reply With Quote
Old 28th June 2007, 15:45   #11  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,641
Quote:
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.
nm is offline   Reply With Quote
Old 10th December 2007, 01:48   #12  |  Link
MasterNobody
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
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).
Attached Files
File Type: rar test.rar (115.2 KB, 88 views)
MasterNobody is offline   Reply With Quote
Old 10th December 2007, 03:01   #13  |  Link
imcold
pencil artist
 
imcold's Avatar
 
Join Date: Jan 2006
Location: Slovakia
Posts: 201
It may be because using threads leads to non-deterministic encoding, so it's rather a feature.
__________________
fevh264 - open-source baseline h.264 encoder
imcold is offline   Reply With Quote
Old 10th December 2007, 04:12   #14  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
Quote:
Originally Posted by imcold View Post
It 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.
Sagekilla is offline   Reply With Quote
Old 10th December 2007, 06:59   #15  |  Link
check
phjbdpcrjlj2sb3h
 
check's Avatar
 
Join Date: Sep 2005
Location: Western Australia
Posts: 1,691
No, x264 should still be deterministic with multiple threads. It is only not when you set --non-deterministic.
check is offline   Reply With Quote
Old 11th December 2007, 00:47   #16  |  Link
MasterNobody
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).
MasterNobody is offline   Reply With Quote
Old 11th December 2007, 07:50   #17  |  Link
imcold
pencil artist
 
imcold's Avatar
 
Join Date: Jan 2006
Location: Slovakia
Posts: 201
I see... sorry, my bad.
__________________
fevh264 - open-source baseline h.264 encoder
imcold is offline   Reply With Quote
Old 7th January 2008, 15:54   #18  |  Link
squid_80
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;
}
which seems to have fixed it. I didn't really spend much time on it though, should probably be checked more closely.
squid_80 is offline   Reply With Quote
Old 18th June 2008, 04:00   #19  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
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
kemuri-_9 is offline   Reply With Quote
Old 18th June 2008, 05:51   #20  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by kemuri-_9 View Post
So 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.
Dark Shikari 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 21:15.


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