calling close() while playing in direct mode with audio will throw segmentation fault

[Patrick Gutlich]

Calling close() while playing a video in direct mode with audio will throw segmentation fault.
When you disable audio, setings.enableAudio=false it doesn't crash.

The same segfault happens when the video is done playing at the end and you call close()

Tested on 'example-direct-mode' with OF 0.10.1 on a rpi3b+ (256mb GPU split)

[Jason Van Cleave]

Can you provide some sample code? This is working for me in ofApp::update and ofApp::draw

if(ofGetFrameNum() == 400)
    {
        ofLog() << "closing";
        
        omxPlayer.close();
    }

[Patrick Gutlich]

Oh I see I gave the wrong example name. I was using example-playback-controls, set settings.enableTexture = false; and while the video was playing pressed the 'q' key.
It's playing the default BigBunny mov

It's openFrameworks 0.10.1 on a fresh latest raspbian,
with the latest git commit of ofxOMXPlayer (but tried latest release as well)
on a Pi3B+ with a 1280x800 (touch) monitor without internal speakers!

I have another pi here, a Pi3B, still running of 0.10.0
I'll do some more testing and try your code example above as well.

[Patrick Gutlich]

ok, using the example-direct-mode on openframeworks 0.10.1:
I have to set either enableAudio or useHDMIForAudio to false (monitor without internal speakers!)
otherwise nothing is drawn to screen but it doesn't segfault when using your piece of code above.

[Jason Van Cleave]

ok cool - what I am guess is happening is the audio player is failing to open because of the monitor type. It's not in the example but ofxOMXPlayer::setup returns a bool so you could check via

bool didOpen = omxPlayer.setup(settings);

[Patrick Gutlich]

Ah!
Now I see that if I use the same bool construct as doPause
and call omxPlayer.close(); in update ()
it doesn't segfault.

probably a Threading thing?

[Jason Van Cleave]

yeah - often you don't want to do things on key press if there are graphics involved. it's safer to set a variable and then do the method in update or draw (so it happens on the main thread)

[Patrick Gutlich]

Ok thanks for the help!

The omxPlayer.close() on pressing 'q' is there in the example-playback-controls on git.
I think we should remove it there and use a doClose bool construct.
would you like me to Fork an PR?

[Jason Van Cleave]

thanks - I may do it internally

e.g. set a doClose variable in ofxOMXPlayer::close

then actually close here:

https://github.com/jvcleave/ofxOMXPlayer/blob/master/src/ofxOMXPlayer.cpp#L313

However I am a bit worried how it would effect the destructor as I don't think it would wait for the onUpdate call. Will have to test