Update: Core OF now compiles, but ofDirectShowPlayer is not the default player on MinGW/CB.

Regression from d6d5c854109f

The quickest solution is to leave it out, but it will require us to revert to a different default video player.

@prisonerjohn your thoughts?

Here is reference to past conversations:

http://forum.openframeworks.cc/t/a-directshow-video-player-for-openframeworks/14154

Issue: openFrameworks does not run in the web browser.

Solution: the emscripten backend for the LLVM compiler generates JavaScript, many C++ OpenGL projects have been demonstrated running in the browser with WebGL.

Is anyone interested in this?

Hi,

I just updated my system, and it seems gstreamer breaks any video playback. Getting this when running the videoPlayer example:

[notice ] ofGstUtils: Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";

[notice ] ofGstUtils: Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0", gst.vaapi.Display.GObject=(GstObject)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";


(videoPlayerExample:12633): GStreamer-Base-CRITICAL **: 16:43:43.970: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink

(videoPlayerExample:12633): GStreamer-Base-CRITICAL **: 16:43:43.970: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink

(videoPlayerExample:12633): GStreamer-Base-CRITICAL **: 16:43:43.971: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink

(videoPlayerExample:12633): GStreamer-Base-CRITICAL **: 16:43:43.971: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink

(videoPlayerExample:12633): GStreamer-Base-CRITICAL **: 16:43:43.971: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink

(videoPlayerExample:12633): GStreamer-Base-CRITICAL **: 16:43:43.971: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink

(videoPlayerExample:12633): GStreamer-Base-CRITICAL **: 16:43:43.972: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink
[ error ] ofGstUtils: startPipeline(): unable to pause pipeline after 5s[ error ]
ofGstUtils: gstHandleMessage(): embedded video playback halted for plugin, module qtdemux0  reported: Internal data stream error.[warning] ofGstVideoUtils: update(): ofGstVideoUtils not loaded

Needless to say, this is a HUGE bug. Please, please, please wait with upgrading gstreamer until this is fixed.

Running this on Arch Linux, oF version 0.11.2. Tested on xorg (bspwm) and wayland (sway).

EDIT: tested now with the latest nightly build, of_v20220210_linux64gcc6_nightly, and getting the same result.

This branch uses glfw as the window system and ditches glut. But ofAppGlutWindow can still be used by modifying main.cpp

to use glfw:

ofSetupOpenGL(ofGetWindowManager(), 640,480, OF_WINDOW);    

to use glut:

ofAppGlutWindow window;
ofSetupOpenGL(&window, 1024,768, OF_WINDOW);

I was using this branch for the last couple of weeks on ubuntu and think it is pretty stable. But it needs compiled libs for mac & windows. The glfw version I use is a fork of the official glfw repo https://github.com/underdoeg/glfw

We should not merge this before those compiled libs are in there.

I send this pull request mainly to have a place to get a discussion going. It'd be great if someone could try this and test if it works for them too :)

Bringing in:

• @LeoColomb
• @DomAmato
• @liquidzym
• @prisonerjohn

Todo:

• [ ] Build all libs for VS2015 x64 using repos pointed to by current apothecary scripts
• [ ] Test Project Generator
• [ ] Test addons (e.g. OpenCV)

#include <ofMain.h>
#include "ofAppGLFWWindow.h"

class ofApp : public ofBaseApp
{
  public:
    void draw();
};

void ofApp::draw()
{
  glClearColor(0.1, 0.1, 0.1, 1);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

  ofSetColor(ofColor::tomato);
  ofDrawCircle(ofGetWindowRect().getCenter(), 80.0f);
}

int main()
{
  ofGLFWWindowSettings settings;
  settings.setGLVersion(2, 1);
  ofCreateWindow(settings);

  return ofRunApp(new ofApp());
}

On OpenGL 2.1:

With settings.setGLVersion(3, 3);:

It's not just ofDrawCircle, every draw command is not working.

This happened after multidraw branch merge, before that programmable renderer worked fine.

ping @arturoc I guess :)

There are two long-standing issues with projectGenerator which prevent generated projects from building if an addon includes non-system frameworks on OS X. This has affected ofxSyphon for a long time and is a frequent support headache.

The issues are ofZach/projectGeneratorSimple#56 and ofZach/projectGeneratorSimple#58.

Assuming this projectGenerator is intended for OF 0.9, it would be tremendous to have those fixed before the release of 0.9.

OS X all versions, Xcode all versions, OF 0.8.4 and git HEAD

Hello -

I made an application which is asynchronously loading many short movie files (from 1 to 5 seconds a file) over a long period of time. This means countless loadAsync, play and pause commands.

I used a recent git master version https://github.com/openframeworks/openFrameworks/commit/27b09aae8c2108cb78cd1b18140ba6ab1040a891 where @i-n-g-o made some changes and I tested them quite extensively (https://github.com/openframeworks/openFrameworks/pull/3736).

Compiling the same application against current oF master creates certain instabilities and runtime crashes. I'll try to give some more details about the bugs, but I need some time to gather them. I just noticed that since the commit above some major changes were made to the AVFoundationPlayer.

Best, Urs

Hey all!

[EDIT] It seems that we don't have c++11 support right now with on osx. The issue primarily is that we have to use libc++ with c++11, which does not support legacy tr1 namespace symbols. To fix this bug we need to write a c++11 version which does not use tr1 namespace.

This could either involve:

1. Writing a win/linux/mac C++11 implementation without tr1
2. Writing a special implementation for libc++ without tr1 for osx

I think the only difference between 1 and 2 is more testing is required for 1. (i.e. the code should look identical).

[/EDIT]

In ofTypes I edited:

#if (_MSC_VER)
#include <memory>
#else
#include <tr1/memory>
// import smart pointers utils into std
namespace std {
    using std::tr1::shared_ptr;
    using std::tr1::weak_ptr;
    using std::tr1::static_pointer_cast;
    using std::tr1::dynamic_pointer_cast;
    using std::tr1::const_pointer_cast;
    using std::tr1::enable_shared_from_this;
    using std::tr1::__dynamic_cast_tag;
}
#endif

to:

#if (_MSC_VER || true) // <----basically hacked here
#include <memory>
using std::shared_ptr;
#else
#include <tr1/memory>
// import smart pointers utils into std
namespace std {
    using std::tr1::shared_ptr;
    using std::tr1::weak_ptr;
    using std::tr1::static_pointer_cast;
    using std::tr1::dynamic_pointer_cast;
    using std::tr1::const_pointer_cast;
    using std::tr1::enable_shared_from_this;
    using std::tr1::__dynamic_cast_tag;
}
#endif

now i get complaints on __dynamic_cast_tag. And ran out of google results. ideas?

/Volumes/SHARED/openFrameworks/libs/openFrameworks/types/ofTypes.h:169:36: No type named '__dynamic_cast_tag' in namespace 'std'

This adds support to build for Android using the Android Studio and the Gradle-Experimental plugin. It is based on the work @HalfdanJ did with the gradle build process in #5059 but starting with a fresh copy of the master branch. The PR also changes how data is handled in Android Studio and inside the app closing #2995. The PR adds support for creating and updating projects with the project generator. The PR makes android build faster the VS2015 builds 👍.

This also depends on an apothecary update to build projects with opencv. I'll make that PR shortly to apothecary but I have the libs in a zip for people to test apps in my dropbox.

This should remove a bunch of the weird android setup procedures with Eclipse and allow Android builds to be more easily maintained when the NDK is updated.

cc: @arturoc

This updates openFrameworks to compile for OS X 10.7 and 10.8 SDKs by bringing the ofxQTKit addons into the core.

For Video Playback the default is now ofQTKitPlayer instead of ofQuicktimePlayer in all cases.

Video Capture the new ofQTKitGrabber will be used in 10.7 and 10.8, while the legacy ofQuicktimeGrabber is used on 10.6 allowing access to the video settings dialog.

The video settings dialog is not available if compiling against 10.7 or 10.8.

Additionally there is an example "osxHighPerformanceVideoPlayerExample" that shows how to take advantage of some of the QTKit features (gpu decoding, fast scrubbing and alpha channel)

i find myself merging this functionality in half my ofParameter-using projects: a T member value to store the init value, and a reInit() method to bring back the value.

this adds some model power to ofParameters and lowers code duplication risks of having to store the "default values" in another structure that mirrors the ofParameter hierarchy. there is also a getInit() which is useful to perform scaling centred on the default value (which might not be in the geometric center of a given T range, but needs to be at the center of knob, for instance).

the value is stored transparently and the reInit() method uses the parameter's set() to propagate the events (so for instance ofxGui responds as expected) -- it does the right thing with default-constructed and "not-setup" ofParameters (ex: a naked ofParameter will be set back to 0 and an ofColor to white). as far as i can tell it is fully backwards-compatible as it does not modify existing behavior, and only adds the footprint of one T.

navigating ofParameter.h is not so explicit... I matched the setMax()/getMax() behavior, plus the assignments where a value is passed. I chose the label "Init" (over "default") as it's short and works as well as a noun (variable) and a verb (methods).

ofParameter<float> zoom {"zoom", 1.0f, 0.1f, 10.0f}; // no difference from current usage
// mess with the zoom, then:
zoom.reInit();

#changelog #types

Here is an example: https://audioselect.handmadeproductions.de/ https://github.com/Jonathhhan/ofEmscriptenExamples/tree/main/audio_select_draft Audio out select does not work yet (maybe with a hack): https://guidou.github.io/setsinkid-demo.html But it is planned: https://github.com/w3ctag/design-reviews/issues/766

Right now I need to make some changes to Emscriptens audioWorklet branch, because I process the audio on the JS side, while the audioWorklet branch expects the audio to be processed on the c++ side. This is a simple Emscripten audioWorklet test / example: https://github.com/juj/emscripten/blob/audio_worklets/test/webaudio/tone_generator.c And this is how I implemented it: https://github.com/Jonathhhan/openFrameworks/blob/emscripten_3.1.9_audioWorklet/addons/ofxEmscripten/src/ofxEmscriptenSoundStream.cpp https://github.com/Jonathhhan/openFrameworks/blob/emscripten_3.1.9_audioWorklet/addons/ofxEmscripten/libs/html5audio/lib/emscripten/audio_worklet.js It would be nice to change the implementation in a way, that it runs without any modifications of the Emscripten source code.

Its quite minimalistic, but seems to work well. Here is an example patch: https://github.com/Jonathhhan/ofEmscriptenExamples/blob/main/webmidi_draft/src/ofApp.cpp https://mtest.handmadeproductions.de/