x264: Maybe a bug? [Archive]

Aktan

18th January 2009, 07:34

Hi all,

I'm using MeGUI to encode a video game video and I found something interesting. I'm using x264 1077 - Skystrife's patched build and while trying to encode the video with constant quant of 1, x264 keeps crashing. I've narrowed it down to 1 Frame in which it still crashes. The source is an AVI using Lagarith video codec (lossless). Since it is an AVI, I just created a simple AVS script like so:

AVISource("Bad frame.avi")

Here is the command line I tried to encode it with and it still crashes:

x264.exe --qp 1 --output "C:\Temp Encode\out.mp4" "C:\Temp Encode\Bad frame.avs"

I also tried with quant 2 and it still crashes.

Now the interesting part is if I tried with quant 0 (lossless) it doesn't crash. Because of this, I don't think it is AviSynth or my source AVI.

I have attached the bad frame so that all may take a look.

Anyone got any ideas? Is this maybe a bug? Or maybe it is because of the wacky resolution (though that doesn't explain why --qp 0 works and why most of the video there is no problems)?

Dark Shikari

18th January 2009, 07:48

Lagarith is rather notorious for causing weird crashes (I've found the decoder to, honestly, be an unreliable piece of crap sometimes...). Try converting the source to something else like HuffYUV instead.

If you still get the crash, grab or make a debug build and post a backtrace of the crash.

Aktan

18th January 2009, 15:13

I've converted the frame to Huffyuv (YV12 aka ffdshow version) and I still have the same problem.

Where can I grab a debug build? I'm also unsure how to get a backtrace.

Here is an attachment of the frame in Huffyuv.

Dark Shikari

18th January 2009, 15:16

Aktan

18th January 2009, 16:05

Okay I've installed GDB.

Just for fun I tried it on the non-debug x264.exe and when doing the command "bt" I noticed it was very very long. Do you want me to post the whole thing?

Dark Shikari

18th January 2009, 16:05

Okay I've installed GDB.

Just for fun I tried it on the non-debug x264.exe and when doing the command "bt" I noticed it was very very long. Do you want me to post the whole thing?The bt of a non-debug x264 will just be give a ton of "??" because the function symbols aren't in the executable.

To post very long things, use pastebin.

Aktan

18th January 2009, 16:40

I tried the debug build from this post: http://forum.doom9.org/showthread.php?p=1217218#post1217218

and since it wasn't compiled with MP4 support I encoded to MKV and it worked fine! Since the debug build was "x264 core:65 r1065 681544e" which is an older version, I thought that was the reason why it now works, but then I tried the non-debug x264.exe with output to MKV also and it didn't crash! So from this I think it is in the MP4 writing code but I have no idea. I'll try to find a debug build with MP4 support.

Dark Shikari

18th January 2009, 16:41

kemuri-_9

18th January 2009, 20:42

Aktan

19th January 2009, 00:21

this might be some more bugged gdb problems...
as you can occasionally run a program and it crashes...
but when running it exactly the same through mingw's gdb it doesn't crash.

i updated the debug build to r1082 +pthreads +gpac, so try again with that anyways.

Sorry I didn't clarify. What I mean was I ran it outside of GDB both debug and non-debug and if it was output to MKV, there is no crash. This had nothing to do with GDB.

Thanks for the updated debug build, I'll try it out when I get a chance.

Aktan

19th January 2009, 00:56

1. Install GDB.

2.
gdb ./x264debugbuild.exe (I think there may be some in the current patches thread--if not, just wait and someone nice will probably post one for you)
set args --this --that --and --the --other --thing
run
(wait for crash)
(post output)
bt
(post output)
disass $pc-30 $pc+30
(post this too)

Okay outputs:

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) cd c:
Working directory C:\.
(gdb) file x264_debug.exe
Reading symbols from C:\x264_debug.exe...done.
(gdb) run --qp 1 --output "C:\out.mp4" "C:\Bad frame Huffyuv.avs"
Starting program: C:\x264_debug.exe --qp 1 --output "C:\out.mp4" "C:\Bad frame Huffyuv.avs"
warning: DllMain: hModule=0x00de0000, ulReason=1, lpReserved=0x00000000, gRefCnt
= 0

warning: DllGetClassObject() CLSID: CAVIFileSynth

warning: 00037770->CAVIFileSynth::CAVIFileSynth()

warning: 00037770->CAVIFileSynth::AddRef() gRefCnt=1, m_refs=1

warning: 00037770->CAVIFileSynth::QueryInterface() {00000001-0000-0000-c000-0000
00000046} (IClassFactory)

warning: 00037770->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 00037770->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: DllGetClassObject() result=0x0, object=00037778

warning: 00037770->CAVIFileSynth::CreateInstance()

warning: 000377C8->CAVIFileSynth::CAVIFileSynth()

warning: 000377C8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=1

warning: 000377C8->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 000377C8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 000377C8->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 00037770->CAVIFileSynth::CreateInstance() result=0x0, object=000377C8

warning: 000377C8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 000377C8->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 00037770->CAVIFileSynth::Release() gRefCnt=1, m_refs=0

warning: 00037770->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 1

warning: 000377C8->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 000377C8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 000377C8->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 000377C8->CAVIFileSynth::QueryInterface() {00020025-0000-0000-c000-0000
00000046} (unsupported!)

warning: 000377C8->CAVIFileSynth::QueryInterface() {0000010b-0000-0000-c000-0000
00000046} (IPersistFile)

warning: 000377C8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 000377C8->CAVIFileSynth::QueryInterface() {00020020-0000-0000-c000-0000
00000046} (IAVIFile)

warning: 000377C8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=3

warning: 000377C8->CAVIFileSynth::Load("C:\Bad frame Huffyuv.avs", 0x0)

warning: 000377C8->CAVIFileSynth::Release() gRefCnt=2, m_refs=2

warning: 000377C8->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 000377C8->CAVIFileSynth::GetStream(*, 73646976(vids), 0)

Program received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---
0x00deef9e in ?? () from C:\WINDOWS\system32\avisynth.dll
(gdb) bt

bt output at: http://pastebin.com/m4fa33545

(gdb) disass $pc-30 $pc+30
Dump of assembler code from 0xdeef80 to 0xdeefbc:
0x00deef80: mov %dh,%al
0x00deef82: or $0x0,%al
0x00deef84: nop
0x00deef85: nop
0x00deef86: nop
0x00deef87: nop
0x00deef88: nop
0x00deef89: nop
0x00deef8a: nop
0x00deef8b: nop
0x00deef8c: nop
0x00deef8d: nop
0x00deef8e: nop
0x00deef8f: nop
0x00deef90: mov 0xc(%esp),%eax
0x00deef94: mov 0x8(%esp),%ecx
0x00deef98: mov 0x4(%esp),%edx
0x00deef9c: push %eax
0x00deef9d: push %ecx
0x00deef9e: mov 0x2c(%edx),%ecx
0x00deefa1: call 0xdeefb0
0x00deefa6: ret $0xc
---Type <return> to continue, or q <return> to quit---
0x00deefa9: nop
0x00deefaa: nop
0x00deefab: nop
0x00deefac: nop
0x00deefad: nop
0x00deefae: nop
0x00deefaf: nop
0x00deefb0: push %ebx
0x00deefb1: mov 0x8(%esp),%ebx
0x00deefb5: push %ebp
0x00deefb6: push %esi
0x00deefb7: push %edi
0x00deefb8: lea 0x8(%ecx),%edi
0x00deefbb: mov %edi,%esi
End of assembler dump.
(gdb)

Aktan

5th February 2009, 02:26

Just wondering, was this problem I was having ever verified as a bug or did I do something wrong?

Dark Shikari

5th February 2009, 02:50

Just wondering, was this problem I was having ever verified as a bug or did I do something wrong?The crash is in Avisynth.dll, not x264, as can be seen by the backtrace.

Aktan

5th February 2009, 05:13

The crash is in Avisynth.dll, not x264, as can be seen by the backtrace.

I'm confused. If indeed it is Avisynth.dll, why would it work then if I output to MKV or if I change it to --qp 0? Is this a case where GDB for windows is funky and outputs the wrong backtrace or something?

squid_80

5th February 2009, 05:51

Try upgrading avisynth to 2.5.8, there is a bug in huffyuv that can trigger a crash in avisynth in rare situations (lagarith may have a similar bug, since it's based on huffyuv).

Dark Shikari

5th February 2009, 06:10

Try upgrading avisynth to 2.5.8, there is a bug in huffyuv that can trigger a crash in avisynth in rare situations (lagarith may have a similar bug, since it's based on huffyuv).Lagarith is just buggy, I'd recommend avoiding it. It seems to cause lots of weird crashes.

squid_80

5th February 2009, 07:02

That's fine advice but he's having the same problem with a huffyuv source.

Aktan

6th February 2009, 02:57

Try upgrading avisynth to 2.5.8, there is a bug in huffyuv that can trigger a crash in avisynth in rare situations (lagarith may have a similar bug, since it's based on huffyuv).

I'm using version 2.5.8, so I don't think that's the problem. Also it works with different parameters for x264 consistently and it also crashes consistently

Sagekilla

6th February 2009, 04:50

Aktan

7th February 2009, 09:12

If it still crashes with different x264 params, that further points towards avisynth being the culprit. It may be an issue relating to decoding that specific frame (with avisource, or whatever else in that chain)

Maybe I didn't make it clear enough, I'm sorry.

There are certain parameter as shown in my first post that it won't ever crash, while there are other parameters where it would crash. If indeed it is avisynth, what does x264 do that ask avisynth for a frame different due to different parameters set to x264?

The examples I have attach is of only 1 single frame. Could someone see if what I posted also happens to them? That is it crashes if it is output to MP4 and the only parameter is --qp 1. Could someone also verify that it does NOT crash if the out is set to MP4 and the only parameter is --qp 0?

LoRd_MuldeR

7th February 2009, 14:24

There are certain parameter as shown in my first post that it won't ever crash, while there are other parameters where it would crash. If indeed it is avisynth, what does x264 do that ask avisynth for a frame different due to different parameters set to x264?

Well, it's quite possible that something in Avisynth (or one of the filters/decoders it calls) goes wrong that corrupts memory. That doesn't necessarily lead to a crash. For example if you overwrite a random memory location (e.g. due to an invalid/uninitialized pointer) that's no problem, as long as that memory location was unused anyway. But if it was used, you may get strange crashes that seem to occur at random code. It may very well depend on your encoding parameters whether the crash is triggered or not. Nevertheless these parameters are not the origin of the problem...

Aktan

7th February 2009, 17:24

Well, it's quite possible that something in Avisynth (or one of the filters/decoders it calls) goes wrong that corrupts memory. That doesn't necessarily lead to a crash. For example if you overwrite a random memory location (e.g. due to an invalid/uninitialized pointer) that's no problem, as long as that memory location was unused anyway. But if it was used, you may get strange crashes that seem to occur at random code. It may very well depend on your encoding parameters whether the crash is triggered or not. Nevertheless these parameters are not the origin of the problem...

I think I kind of see what you mean. The only think that strike me as weird though is that you said "random" memory location. Wouldn't that mean it sometimes crash and sometimes doesn't no matter what parameters I choose?

LoRd_MuldeR

7th February 2009, 17:37

I think I kind of see what you mean. The only think that strike me as weird though is that you said "random" memory location. Wouldn't that mean it sometimes crash and sometimes doesn't no matter what parameters I choose?

Well, it may be random, which makes it even harder to find the source of the problem. Nevertheless it would also be possible that there is a problem in Avisynth (or one of the filter/decoders it involves) which always corrupts the same memory location. Depending on the x264 parameters chosen, this may or may not interfere with x264. So you can reliably reproduce the crash with certain x264 settings, while other settings reliably work okay. Still the origin of the problem is not in x264 itself. I don't say that this is the case here, but you must take that case into account.

Here is one thing you could test:
Let Avisynth run in its own process (e.g. av2yuv.exe) and pipe the "raw" video data over to the x264.exe process.
Then each process has got its own separate address space and you'll see what process crashes (if any).

You may use that tool to do the test, given that your system is x64-capable:
http://www.mediafire.com/?my0rodm4mwf

You can also run it manually like that:
pipebuf.exe avs2yuv.exe "C:\TEMP\sample.avs" -raw - : x264.exe --crf 22 --subme 9 --me umh --analyse all \
--bframe 4 --b-adapt 2 --ref 6 --b-pyramid --trellis 2 --weightb --mixed-refs --threads auto --progress \
--frames 2262 --fps 2997/100 --output "C:\my output.mkv" - 352x288 : 4

Aktan

7th February 2009, 20:29

Okay following LoRd_MuldeR, I got avs2yuv.exe from here:
http://akuvian.org/src/avisynth/avs2yuv/

Instead of pipping, I opt to just store it in a temporary file since it is just 1 frame so I did the following command:
avs2yuv.exe "Bad frame Huffyuv.avs" out.temp

Then I start x264_debug.exe (x264 core:65 r1082 bde164d) inside of GDB and got the same information Dark Shikari requested as it still crashes:

(gdb) run --qp 1 --output "test.mp4" out.temp 256x224
Starting program: C:\x264_debug.exe --qp 1 --output "test.mp4" out.temp 256x224
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 1.2
mp4 [info]: initial delay 0 (scale 25)

Program received signal SIGSEGV, Segmentation fault.
0x7c96d811 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll

(gdb) bt
#0 0x7c96d811 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll
#1 0x00030000 in ?? ()
#2 0xfc44def3 in ?? ()
#3 0x40000060 in ?? ()
#4 0x01c98959 in ?? ()
#5 0x00030000 in ?? ()
#6 0x0023f694 in ?? ()
#7 0x0023f970 in ?? ()
#8 0x0023f8e4 in ?? ()
#9 0x7c90e900 in strchr () from ntdll.dll
#10 0x00000000 in ?? () from
#11 0x00000000 in ?? () from
#12 0x7c9101bb in ntdll!RtlAppendStringToString () from ntdll.dll
#13 0x77c2c3c9 in msvcrt!free () from C:\WINDOWS\system32\msvcrt.dll
#14 0xfc44deeb in ?? ()
#15 0x00030000 in ?? ()
#16 0x0023f9c0 in ?? ()
#17 0x6d9dbb16 in ?? ()
#18 0x00019210 in ?? ()
#19 0x0023f888 in ?? ()
#20 0x002bd77a in ?? ()
#21 0x0023f9c0 in ?? ()
#22 0x7c90e900 in strchr () from ntdll.dll
---Type <return> to continue, or q <return> to quit---
#23 0x7c96d9b8 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll
#24 0x00000001 in ?? ()
#25 0x0023f9d0 in ?? ()
#26 0x7c949e1c in ntdll!LdrFindEntryForAddress () from ntdll.dll
#27 0x00030000 in ?? ()
#28 0x50000061 in ?? ()
#29 0xfc44def3 in ?? ()
#30 0x00030000 in ?? ()
#31 0xfc44def3 in ?? ()
#32 0x40000060 in ?? ()
#33 0x00018000 in ?? ()
#34 0x77c5fce0 in msvcrt!_iob ()
#35 0x00018000 in ?? ()
#36 0x0023f904 in ?? ()
#37 0x77c3edb2 in msvcrt!_flsbuf () from C:\WINDOWS\system32\msvcrt.dll
#38 0x0023f988 in ?? ()
#39 0x77c35c94 in msvcrt!_except_handler2 ()
from C:\WINDOWS\system32\msvcrt.dll
Previous frame inner to this frame (corrupt stack?)

(gdb) disass $pc-30 $pc+30
Dump of assembler code from 0x7c96d7f3 to 0x7c96d82f:
0x7c96d7f3 <ntdll!RtlpNtMakeTemporaryKey+32039>: add %ch,%al
0x7c96d7f5 <ntdll!RtlpNtMakeTemporaryKey+32041>: pop %es
0x7c96d7f6 <ntdll!RtlpNtMakeTemporaryKey+32042>: cmp %bh,%cl
0x7c96d7f8 <ntdll!RtlpNtMakeTemporaryKey+32044>: inc %esi
0x7c96d7fa <ntdll!RtlpNtMakeTemporaryKey+32046>: inc %ebp
0x7c96d7fb <ntdll!RtlpNtMakeTemporaryKey+32047>: out %al,$0x1
0x7c96d7fd <ntdll!RtlpNtMakeTemporaryKey+32049>: or %edi,0xc(%ebp)
0x7c96d800 <ntdll!RtlpNtMakeTemporaryKey+32052>: push $0x0
0x7c96d802 <ntdll!RtlpNtMakeTemporaryKey+32054>: push %esi
0x7c96d803 <ntdll!RtlpNtMakeTemporaryKey+32055>: call 0x7c96c687 <ntdll
!RtlpNtMakeTemporaryKey+27579>
0x7c96d808 <ntdll!RtlpNtMakeTemporaryKey+32060>: mov 0x10(%ebp),%ebx
0x7c96d80b <ntdll!RtlpNtMakeTemporaryKey+32063>: lea 0xfffffff8(%ebx),
%edi
0x7c96d80e <ntdll!RtlpNtMakeTemporaryKey+32066>: mov %edi,0xffffffd4(%
ebp)
0x7c96d811 <ntdll!RtlpNtMakeTemporaryKey+32069>: movzwl (%edi),%eax
0x7c96d814 <ntdll!RtlpNtMakeTemporaryKey+32072>: shl $0x3,%eax
0x7c96d817 <ntdll!RtlpNtMakeTemporaryKey+32075>: mov %eax,0xffffffd0(%
ebp)
0x7c96d81a <ntdll!RtlpNtMakeTemporaryKey+32078>: push $0x7c96d9dc
0x7c96d81f <ntdll!RtlpNtMakeTemporaryKey+32083>: push %edi
---Type <return> to continue, or q <return> to quit---
0x7c96d820 <ntdll!RtlpNtMakeTemporaryKey+32084>: push %esi
0x7c96d821 <ntdll!RtlpNtMakeTemporaryKey+32085>: call 0x7c96c52b <ntdll
!RtlpNtMakeTemporaryKey+27231>
0x7c96d826 <ntdll!RtlpNtMakeTemporaryKey+32090>: test %al,%al
0x7c96d828 <ntdll!RtlpNtMakeTemporaryKey+32092>: je 0x7c96d97f <ntdll
!RtlpNtMakeTemporaryKey+32435>
0x7c96d82e <ntdll!RtlpNtMakeTemporaryKey+32098>: cmp 0x7c97cf50,%ebx
End of assembler dump.

It doesn't crash if I use --qp 0 nor does it crash when I output to MKV.

Now I think avisynth is out of the picture and can be ruled out it isn't avisynth

I've attached the raw frame.

Any ideas?

Note: I did notice when it worked the output MP4 frame is a little messed up (Colors and placement are off). I don't think this would cause the crash, but I really have no idea.

LoRd_MuldeR

7th February 2009, 20:44

Note: I did notice when it worked the output MP4 frame is a little messed up (Colors and placement are off).

Try like this:

avs2yuv.exe "Bad frame Huffyuv.avs" -raw out.yuv

better?

BTW: If you upload the file at http://mediafire.com/ or a similar service you can simply post the link, so we don't need to wait for approval of your attachment...

--[EDIT]--

Can't reproduce any crash with your sample:

F:\DeLpHi\x264_x64_launcher>x264 --qp 0 --output crashtest.mkv --progress c:\out
.yuv 256x224
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 1.2
x264 [info]: slice I:1 Avg QP: 0.00 size: 48728
x264 [info]: mb I I16..4..PCM: 0.0% 0.0% 99.6% 0.4%
x264 [info]: kb/s:9745.6

encoded 1 frames, 66.67 fps, 9835.60 kb/s

F:\DeLpHi\x264_x64_launcher>x264 --qp 1 --output crashtest.mkv --progress c:\out
.yuv 256x224
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 1.2
x264 [info]: slice I:1 Avg QP: 0.00 size:105859 PSNR Mean Y:63.58 U:62.35
V:62.71 Avg:63.20 Global:63.20
x264 [info]: mb I I16..4: 45.1% 0.0% 54.9%
x264 [info]: SSIM Mean Y:0.9999951
x264 [info]: PSNR Mean Y:63.581 U:62.347 V:62.705 Avg:63.198 Global:63.198 kb/s:
21171.80

encoded 1 frames, 62.50 fps, 21265.20 kb/s

F:\DeLpHi\x264_x64_launcher>x264 --qp 26 --output crashtest.mkv --progress c:\ou
t.yuv 256x224
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 1.2
x264 [info]: slice I:1 Avg QP:23.00 size: 45050 PSNR Mean Y:38.45 U:40.29
V:40.94 Avg:39.05 Global:39.05
x264 [info]: mb I I16..4: 0.0% 0.0% 100.0%
x264 [info]: SSIM Mean Y:0.9984538
x264 [info]: PSNR Mean Y:38.447 U:40.287 V:40.939 Avg:39.054 Global:39.054 kb/s:
9010.00

encoded 1 frames, 62.50 fps, 9103.40 kb/s

F:\DeLpHi\x264_x64_launcher>x264 --crf 22 --output crashtest.mkv --progress c:\o
ut.yuv 256x224
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 1.2
x264 [info]: slice I:1 Avg QP:25.00 size: 41302 PSNR Mean Y:36.56 U:38.88
V:38.90 Avg:37.21 Global:37.21
x264 [info]: mb I I16..4: 0.0% 0.0% 100.0%
x264 [info]: SSIM Mean Y:0.9975844
x264 [info]: PSNR Mean Y:36.561 U:38.878 V:38.896 Avg:37.207 Global:37.207 kb/s:
8260.40

encoded 1 frames, 66.67 fps, 8363.20 kb/s

--[EDIT2]--

Weird, when I output to .mp4 instead of .mkv it will crash indeed :eek:

So I'd suspect the mp4 muxer (that is gpac)

Aktan

7th February 2009, 21:08

Thanks LoRd_MuldeR for verifying that it wasn't just me.

Yea I had the suspicion before with Dark Shikari (maybe?) that it was GPAC. Right now my workaround is just output to MKV instead of MP4.

LoRd_MuldeR

7th February 2009, 21:11

Yea I had the suspicion before with Dark Shikari (maybe?) that it was GPAC. Right now my workaround is just output to MKV instead of MP4.

Should be no big deal. You need to re-mux anyway in order to add the audio part...

(There even was a poll to remove gpac from x264 builds recently)

Aktan

7th February 2009, 21:21

Should be no big deal. You need to re-mux anyway in order to add the audio part...

(There even was a poll to remove gpac from x264 builds recently)

Yea this problem if indeed was GPAC wouldn't be a big deal. I just wanted confirmation it is GPAC and only GPAC so I can avoid future crashes.

If indeed it is only GPAC, I guess x264 devs can't do anything to fix it?

kemuri-_9

7th February 2009, 23:07

Edit:
well crap... i hate saying stuff before i test fully, like always find myself ending up being wrong...

my x64 build completes the encode without crashing, however the output is corrupted as well.

it might be a windows issue... i'll try on some linux systems and see if there's a problem as well...

Aktan

23rd February 2009, 03:28

Edit:
it might be a windows issue... i'll try on some linux systems and see if there's a problem as well...

Did you ever get a chance to find out? :thanks:

kemuri-_9

23rd February 2009, 06:18

i originally tried a bit back and gpac didn't want to compile on my linux box...

trying again now and it's working on linux and windows.
seems that something was fixed lately in the 0.4.6 update.

Aktan

24th February 2009, 04:19

i originally tried a bit back and gpac didn't want to compile on my linux box...

trying again now and it's working on linux and windows.
seems that something was fixed lately in the 0.4.6 update.

Cool thanks for the info! :thanks:

Aktan

1st March 2009, 16:34

As of build 1115 from Skystrife, this problem still exist. I think it is because he has not updated the GPAC code in his compiles. I'm not sure if he follows this thread but could someone notify him about this issue and ask if he could update his GPAC code? :thanks: