After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 761154 - gst-examples: new repository with examples
gst-examples: new repository with examples
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: dont know
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-01-27 00:37 UTC by Thiago Sousa Santos
Modified: 2016-08-30 14:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thiago Sousa Santos 2016-01-27 00:37:48 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?
Comment 1 Sebastian Dröge (slomo) 2016-01-27 12:50:30 UTC
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?
Comment 2 Thiago Sousa Santos 2016-02-03 21:08:21 UTC
Updated using meson: http://cgit.freedesktop.org/~thiagoss/gst-examples/log/
Comment 3 Tim-Philipp Müller 2016-02-03 21:19:11 UTC
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.
Comment 4 Sebastian Dröge (slomo) 2016-08-26 14:21:38 UTC
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 :)
Comment 5 Sebastian Dröge (slomo) 2016-08-26 14:27:04 UTC
(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
[...]
Comment 6 Tim-Philipp Müller 2016-08-26 14:51:44 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2016-08-26 15:16:43 UTC
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 :)
Comment 8 Sebastian Dröge (slomo) 2016-08-29 08:14:41 UTC
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, ...? :)
Comment 9 Tim-Philipp Müller 2016-08-30 13:39:44 UTC
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.
Comment 10 Sebastian Dröge (slomo) 2016-08-30 14:20:25 UTC
Ok, pushed then. Those things can be worried about at a later point then