App crashes after a while on H264 error


#1

Our app randomly crashes after a while (multiple days) with the following errors in the console:

[h264 @ 0000028FA25FD280] get_buffer() failed
[h264 @ 0000028FA25FD280] thread_get_buffer() failed
[h264 @ 0000028FA25FD280] decode_slice_header error
[h264 @ 0000028FA25FD280] no frame!

These errors keep repeating for a while, sometimes also showing the following error:

[h264 @ 0000028FA25FE100] Missing reference picture, default is 0

At some point, the errors stop but the app is unresponsive. However the console window is still active and can still receive OSC data, see image.

We do use video playback in our application and even though it’s not being rendered to the screen when the app crashes, I realize it’s still being decoded in the background. However it does not seem like we call any methods on the nap::Video object at the time of the crash.

Has anyone seen this before?


#2

Interestingly, after the crash, the app is unable to start properly as well. It shows the following console output and then seems to exit but without any errors.

After a computer reboot, the app starts normally again.

[debug] Looking for 'C:/NAP-0.2.0-Win64-2018.12.19T16.13/projects/random/Random-0.2.0-Win64-2018.12.19T16.20/project.json'...
[debug] Loaded module mod_napapp v0.2.0
[debug] Loaded module mod_napartnet v0.2.0
[debug] Loaded module mod_napaudio v0.2.0
[debug] Loaded module mod_napcameracontrol v0.2.0
[debug] Loaded module mod_napfont v0.2.0
[debug] Loaded module mod_napimgui v0.2.0
[debug] Loaded module mod_napinput v0.2.0
[debug] Loaded module mod_napmath v0.2.0
[debug] Loaded module mod_naposc v0.2.0
[debug] Loaded module mod_naprender v0.2.0
[debug] Loaded module mod_napscene v0.2.0
[debug] Loaded module mod_napsdlinput v0.2.0
[debug] Loaded module mod_napvideo v0.2.0
[debug] Loaded module mod_random v0.2.0
[debug] Looking for 'C:/NAP-0.2.0-Win64-2018.12.19T16.13/projects/random/Random-0.2.0-Win64-2018.12.19T16.20/config.json'...
[info] initializing service: nap::SceneService
[info] initializing service: nap::InputService
[info] initializing service: nap::RenderService
OpenGL INFO: initialized glew successfully
OpenGL INFO: vendor: Microsoft Corporation
OpenGL INFO: shading language: (null)
[info] initializing service: nap::ArtNetService
[info] initializing service: nap::FontService
[info] initializing service: nap::IMGuiService
[info] initializing service: nap::OSCService
[info] initializing service: nap::SDLInputService
[info] initializing service: nap::VideoService
[info] initializing service: nap::audio::AudioService
[info] Portaudio initialized.
[info] Available audio devices on this system:
[info] MME:
[info] 0: Microsoft Sound Mapper - Input 2 inputs 0 outputs
[info] 1: Microphone Array (Realtek High  4 inputs 0 outputs
[info] 2: Microsoft Sound Mapper - Output 0 inputs 2 outputs
[info] 3: Realtek Digital Output (Realtek 0 inputs 2 outputs
[info] Windows WDM-KS:
[info] 0: Output (AMD HD Audio HDMI out #4) 0 inputs 2 outputs
[info] 1: SPDIF Out (Realtek HDA SPDIF Out) 0 inputs 2 outputs
[info] 2: Microphone Array (Realtek HD Audio Mic Array input) 4 inputs 0 outputs
[info] 3: Stereo Mix (Realtek HD Audio Stereo input) 2 inputs 0 outputs
[info] 4: Speakers (Realtek HD Audio output) 0 inputs 2 outputs
[info] Portaudio stream started: , , 1 inputs, 2 outputs, samplerate 44100, buffersize 1024

#3

Heya,

Looks like a video threading issue. If I remember correctly the video is started on initialization and never stopped (loops forever). A quick fix would be to start video playback when going into video mode and stop playback when exiting. Although this isn’t a proper solution I can’t think of an actual code solution based on the information above. Looks like an internal FFMPEG issue but will have to debug a session to figure out the crash.

So in the video select component in your app: don’t start the video on initialization. Only when switching context and stop it when switching to another context.

. Also: if you are still using the default videos try another set, the default videos have very few keyframes and are encoded on a mac with very sparse settings to keep the file size low. My hunch is that with a more default encoded video the problem might go away. After some research I found out that this is a relatively common ffmpeg keyframe related problem that we don’t handle correctly completely.

How many times has this occurred? Hope this helps!


#4

Ow, the reason why your app doesn’t completely crash is that video runs on it’s own (multiple) threads. The OSC receiver also receives and logs messages on it’s own thread. This could be related to the crash you are experiencing but again, not sure. Video is a complex beast in NAP and we never ran video continuously for multiple days in a row.


#5

I see!

Yeah when I realized that the video keeps playing in the background it occured to me that we can toggle playback based on mode as well, should be a quick fix.

I think it happened about 2 or 3 times so far, about once a week.

I’ll try more videos later too when I got some time on my hands.

Thanks!


#6

Perfect, should be a quick and easy fix for now. I absolutely hate ffmpeg, it’s a beast of a nightmare to implement and comes with it’s own set of quirks. I’ll add it to our backlog as a bug. I’ll run a test on my end in debug mode on a dedicated machine and hopefully trigger the same bug.


#7

Hey, NAP 0.4.0 ships with a new video player that also fixes a package (frame) leak when switching / looping videos using FFmpeg. Could be a fix for this issue.