Is it possible to use GStreamer without a graphic interface running?

Question

I am setting up my first application using GStreamer and one of the requirements is that the environment must be optimized, so no graphic interface. I have Arch Linux running on a Pandaboard (ARMv7 - TI OMAP4 - Rev 3.2) with NO graphics. Just text terminal.

All I want to do for now is to play a movie. Second step will be a fast prototype for a custom media player.

As a beginner with GStreamer I might be doing something that makes no sense, really, but all of the examples at http://docs.gstreamer.com/display/GstSDK/Basic+tutorials compile correctly on the board but none of them work.

Also all of the commands like gst-inspect-0.10 and gst-launch-0.10 fail.

The questions are:

1. Is it possible to make GStreamer work from pure shell??
2. And create an application that uses GStreamer that works in pure shell??

Thank you very much!

Any help highly appreciated.

Answer 1

This question is not quite as weird as it sounds IF you realize that the poster is an embedded systems guy.

A lot of accelerated system-on-chip designs have dedicated, accelerated, and in some cases DRM-isolated video output hardware and subsystems. These are totally unrelated to "graphical user interface" displays-- though they frequently steal memory from them. (When a GUI IS present, it is VERY common to have a hardware compositor overlay one on top of the other. This means that you can see an on-screen display over your movie, but you can't hack the box's OSD to do screen grabs from DRM-protected content, for example.)

So, the poster may very well be saying, "I have to SSH into this rust-bucket, and the HDMI port doesn't work yet, for some damn reason. Can I at least tell whether or not the accelerated video sink is working, so that I can tell my project manager that we can give people Christmas off this year?"

However, the first thing that should be done is to verify if the software-only demultiplexer(s) and software-only decoder(s) are working. Then, test the hardware-accelerated decoder, then the hardware-accelerated demuxer (if you have one). Only then would you test the hardware-accelerated video rendering sink.

To do piecemeal tests like this, you need to familiarize yourself with a command-line tool called "gst-launch". To find out what pieces are available, you also need to get used to "gst-inspect". Finally, you need to install GraphViz somewhere and learn how to get GStreamer to dump ".dot" file debugging graphs for inspection.

Your tests should start with instantiating a file read and dumping it into oblivion, like this:

gst-launch filesrc location=foo.mkv ! fakesink

Then demultiplexing it into audio and video streams and throwing each of those out:

gst-launch filesrc location=foo.mkv ! queue ! matroskademux name=demux demux. ! queue ! fakesink demux. ! queue ! fakesink

Believe me, the syntax gets more arcane from there. NONE of those symbols does what you expect, including the spaces. Please read the documentation carefully. Basically, ! is "connect", ".name" means "input side of name", "name." means "output side of name", and what a space does completely depends on what's on other side of it. You will have to read through a lot of examples and use it for a while before it feels usable, that's just how it works. I strongly recommend putting long launch lines into shell scripts so that you can clean them up and use variable substitution.

A full decode and render typically looks something like this:

gst-launch filesrc location=foo.mkv ! queue ! matroskademux name=demux demux. ! queue ! vp8dec ! queue ! videoconvert ! queue ! autovideosink demux. ! queue ! opusdec ! queue ! audioconvert ! audioresample ! queue ! autoaudiosink

...and anything more complex than that gets downright horrifying. It's fun!

I have a few recommendations:

1. Shoot GStreamer 0.10 in the head until it is dead, dead, dead.
2. DO NOT EVER use anything older than about GStreamer 1.3.6 for embedded systems work. Ever. EVER. SERIOUSLY.
3. If at all possible, use GStreamer 1.8.2 or more recent.
4. Familiarize yourself with the weird history of what happened with the hardware-accelerated GStreamer branches and side projects, especially for IMX6.
5. Use "aasink" to render video/images to ASCII animations on consoles during early testing.
6. Trying to push Vorbis or Theora out over multicast is madness. The compression dictionaries are variable, not fixed, but they are NOT ENCODED IN THE STREAMS. The mechanism for moving them around out-of-band is terrifying and incomplete, and even worse if you want to try jamming them into an SDP file. Wait for MAJOR updates to lots of unrelated libraries and a half-dozen RFCs, or pick a different format.

No. 5 brings us back around to the original question taken EVEN MORE literally-- "I want to watch a movie without a GUI".

You can in fact literally do this, using the ASCII Art Video Rendering Sink, "aasink". It is not available in all distros by default, you may have to build it. In fact, you should plan to fully reconfigure and rebuild not only all of GStreamer, but as many of its support libraries as you can tolerate, optimized for your target.

If you turn it on, you will get a "Matrix"-esque view of your video stream on your terminal, provided the data rate is fast enough, your terminal emulation is reasonably complete, you remember to run the "reset" command once in a while, and your terminal is resized to a small size.

Your graph will, however, still stall unless the audio is going somewhere. To that end, there is also "monoscope", which will render audio to a waveform view. But that would normally require a GUI... UNLESS... see where this is going? You can build a gst-launch line that will render video AND audio into an ASCII sequence, by using one of the compositor plugins to overlay them. Horrifying, but satisfying!

Hope those help! And everybody else, keep in mind that if a poster's question makes no sense for your desktop, it may still make A LOT of sense on something else.

Answer 2

If the basic tutorials are not running then you may have to check if all the elements are getting created correctly.

"None of them work" means what ... ?
What is the error that you get, or simply a black screen. It must print some logs or the program stops after sometime without showing anything.

Check if the autovideosink element is available and creates correctly.

Ans 1. In my opinion, it won't be possible to have the video showing up if graphic interface X (ximagevsink) is not available

Ans 2. If basic tutorials are not working properly, I don't think an application will.

Answer 3

Short answer: 1. Yes 2. Yes

Slightly longer: I don't quite get what you are asking? You want to play a movie, but not using graphics? Anyways, typically only GStreamer video-sinks would do anything towards the GFX-side of your environment (like X with ximagesink), and most other elements is pretty much just C-code doing things like muxing/demuxing, encoding/decoding and different pipe-fittings (valve, tee, funnel etc.)