[FFmpeg-devel] Merge from ffmpeg 1.1.3 to 2.1.2 port for CE

[Hermann, Sven (SCR US)]

Yes, multithreading is disabled:

[h264 @ 0xaa320] Warning: not compiled with thread support, using thread emulation



I also use CONFIG_MEMALIGN_HACK, but still got  the following message about alignment of stack variables.



"Compiler did not align stack variables. Libavcodec has been miscompiled

and may be very slow or crash. This is not a bug in libavcodec,

but in the compiler. You may try recompiling using gcc >= 4.2."



I added the --disable-asm and --disable-yasm options to check the impact. The warning about the stack variables from above disappeared, but the issue still remains the same.



The input buffer should be plenty big. It is allocated to MAX_BUFFER_SIZE + START_CODE_SIZE + FF_INPUT_BUFFER_PADDING_SIZE (2000000 + 4 + 16)







-----Original Message-----
From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Michael Niedermayer
Sent: Tuesday, January 28, 2014 10:24 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Merge from ffmpeg 1.1.3 to 2.1.2 port for CE



On Tue, Jan 28, 2014 at 09:19:26PM +0000, Hermann, Sven (SCR US) wrote:

> Hi,

>

> I inherited a project where we have ported a ffmpeg version to Windows CE.

> It is built in Cygwin with MinGW in a quite big process. But that just as background.

>

> I recently tried to port the new version (2.1.2) to this build process, and have since massive problems with my application.

>

> The Application is a Video Stream Player for IP Cameras. This means, I don't have to deal with encoding frames or such. My Stream (H264 and MPEG4) is tunneled through live555 and I get a callback with the frame available. Now this frame is sent to ffmpeg to decode.

>

> With ffmpeg 1.1.3, this worked just fine, and since I ported 2.1.2, I get an crash in a call to avcodec_decode_video2(). I tried to trace this further down. But since I am cross compiling with a terrible Cygwin and Visual Studio setup this is rather painful. However, I could trace it all the way down to decode_nal_units() in h264.c (I am debugging the H264 decoder first).

>

> On this level I cannot really tell anymore what is going on since I debug ffmpeg with printf() insertions (I know, terrible... but I have no way to actually debug ffmpeg on my ce device).

> I enabled all the traces for this level, and get the following:

>

> [h264 @ 0xaa320] Unknown NAL code: 0 (0 bits)

> [h264 @ 0xaa320] Unknown NAL code: 0 (1934 bits)

> [h264 @ 0xaa320] non-existing PPS 127 referenced

> [h264 @ 0xaa320] decode_slice_header error

> [h264 @ 0xaa320] non-existing PPS 159 referenced

> [h264 @ 0xaa320] decode_slice_header error

> [h264 @ 0xaa320] Unknown NAL code: 29 (1390 bits)

> [h264 @ 0xaa320] non-existing PPS 7 referenced

> [h264 @ 0xaa320] decode_slice_header error

> [h264 @ 0xaa320] Unknown NAL code: 0 (234 bits)

> [h264 @ 0xaa320] Unknown NAL code: 0 (106 bits)

> [h264 @ 0xaa320] Unknown NAL code: 0 (74 bits)

> [h264 @ 0xaa320] Unknown NAL code: 0 (0 bits)

> [h264 @ 0xaa320] Unknown NAL code: 0 (12 bits)

> .

> .

> .

> [h264 @ 0xaa320] Unknown NAL code: 0 (0 bits)

> [h264 @ 0xaa320] Unknown NAL code: 0 (0 bits)

> Unhandled exception at 0x422171c3 in PanelMediaPlayer.exe: 0xC0000005: Access violation.

>

>

> I looked at the example of how to decode, and seem to do it the right way. Any Idea what I might do wrong? Any help is appreciated. I spent days debugging this issue now, and don't get any further.



a very wild guess, your allocated input buffer is

FF_INPUT_BUFFER_PADDING_SIZE bigger than the size set in AVPacket ?

also i assume you tried with asm and multithreading disabled ?

if not please try and reporrt back if that makes a difference

and as you mention windows, i assume you enable CONFIG_MEMALIGN_HACK

or somehow else ensured malloc() returns well aligned memory



[...]

--

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB



Old school: Use the lowest level language in which you can solve the problem

            conveniently.

New school: Use the highest level language in which the latest supercomputer

            can solve the problem without the user falling asleep waiting.

This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation