GNOME Bugzilla – Bug 761154
gst-examples: new repository with examples
Last modified: 2016-08-30 14:20:25 UTC
There were some discussions late past year to create a new repository to contain a collection of examples. There are 2 questions to answer: 1) Which examples are already available and should be merged? So far, we have: * http-launch Ideas to write: * Camerabin example * Streaming client + recording Less relevant: 2) Do we want a single build infrastructure or should every example have its own build?
There's also the playout example from gst-plugins-bad and the GstPlayer applications that would be good to have. I would make overall build infrastructure, but maybe just use meson or something simple instead of having a huge amount of autotools stuff in there?
Updated using meson: http://cgit.freedesktop.org/~thiagoss/gst-examples/log/
What I was hoping for for the examples repository was more like a representative list of small example applications do that various interesting things and have been written as examples/demos, so demonstrate best practices, clear code, etc. They should IMHO be higher-level and better than most of the silly things we have in tests/icles and tests/examples. I'll have a list of ideas somewhere, just need to find it. GstPlayer API examples sounds good to me. A nice camerabin example that uses GstDeviceProvider might also be nice.
What about something like the following directory structure then for now: playback/... (the GstPlayer apps) network/http-launch network/... (RTP, RTSP, WebRTC, ... things, could also have something that uses the camera) encoding/... (some GstTranscoder thing, a sound recorder, transmageddon, ...) hardware/... (some "cheese"-style app, ...) graphics/... (things with effects, GL things, ...) misc/... (whatever) I would create a repository that has the GstPlayer applications and http-launch like that for now, and then people can propose new things to be added and we can decide for each of them individually instead of us being blocked here forever because of trying to find the perfect scheme :)
(In reply to Sebastian Dröge (slomo) from comment #4) > What about something like the following directory structure then for now: > > playback/... (the GstPlayer apps) To be exact: playback/player/android playback/player/ios playback/player/gtk [...]
In general I think we can either categorise like $group/$exampleN/{android,ios,etc} or ${android,ios,etc.}/$group/$exampleN etc. Would there be any reasons to go for the second option (e.g. build system related or such) ? Ignoring for a second that it gets messy if you write something that works on multiple systems. Otherwise I think this makes all sense in principle. I'd want to bikeshed the exact top-level categories a little, but if there's no reason to go for categorisation scheme #2 then > playback/player/android > playback/player/ios > playback/player/gtk works for me and you could make a start merging the GstPlayer examples there while we figure out the rest.
I would go for $group/$example and in the case of GstPlayer there are just platform specific applications. For other examples this might not be the case, or it might be different. I would also be fine with e.g. playback/player-android, playback/player-ios, etc. but a subdirectory seemed useful. In the end, we can always move things around later if needed. It's GIT, not CVS. The other categories we can bikeshed once someone actually wrote the code and proposed it for integration. No point in doing that now :)
My approach can be found here: https://cgit.freedesktop.org/~slomo/gst-examples Commandline and GTK GstPlayer apps are integrated into the build system, the android/ios/qt ones not. For android/ios you would use Android Studio / XCode, for the Qt one QtCreator (and it has a qmake based build system as a result of that). Good to go, comments, ...? :)
I think it's good to go, let's make a start on this! Obligatory bikeshedding: - maybe it should be streaming/ instead of network/ ? (undecided) - would be nice to prefix/suffix some of the apps with gst- in case someone wants to package the examples Both of these can be trivially done later, so no need to block on that IMHO.
Ok, pushed then. Those things can be worried about at a later point then