Opus now/soon in gstreamer-plugins-bad-free

Opus is a new audio codec covering a wide range of use cases. You can read more about the codec (at least) here and here.

If you want to get started with it, just try a freshly rebuild gstreamer-plugins-bad-free package which packages the opus plugin.
You will be able to use the en- and decoders in your normal gst pipeline.

It should soon land as an update on Fedora near you.

[Update]
The update has landed in updates testing:

su -c 'yum update --enablerepo=updates-testing gstreamer-plugins-bad-free-0.10.23-11.fc18'

Easier streaming with presence-0.4.8

Presence is a small - but yet flexible - tool to do simple and high-quality streaming (using dirac+vorbis over RTP) in a local broadcast domain.
When not using the MDNS feature this can also be endpoints on any routable network.
Not shown on in the screen shot, but a feature, is picture-in-picture mode for secondary streams.

Anyhow, this new release (0.4.8) contains an improvement related to publishing a stream. It's now done in two clicks with reasonable defaults, even for low-end machines.

Install or update it now on Fedora 16/17/18:

$ sudo yum clean metadata
$ sudo yum install --enablerepo=updates-testing presence
# or
$ sudo yum update --enablerepo=updates-testing presence

Or - hero-like -using this one-click technology.

The release was motivated by my new Logitech HD Pro Webcam C920 which is working out of the box on Fedora - so YUV and MJPEG besides the (unsupported) h.264 support.

 

When looking at the video quality of this camera and two built-in cameras of laptops, this is clearly a big step forward in image quality - So a decent camera is always a good way to improve a video conference.

As said, the video quality is great - and using MJPEG it can deliver a 720p video with up to 24fps, so ideal for telepresence. 

Da - Presence lands in fedora

Finally, presence - that small video tool - has landed in the fedora-updates repo.

You can install it using:

$ sudo yum install presence

That's all there is to do.

Securing peer connections using IPSec

If some application or transport protocol doesn't specify a way to encrypt it's contents, it might be still enough to encrypt a lower layer.

IPSec is a way to encrypt IP packets (actually it is an alternative to IP).

The script after the break can be used to secure a connection - like an RTSP stream - between two peers using a pre shared key (psk).

presence is up for review.

To get presence into Fedora a so called "review" is needed - as you might know. If not it's a must to do one.
So if you needed something entertaining tonight, just grab a nice bottle of Beck's beer (or Bionade Holunder) and a box of Pringles (or Rosinen) and enjoy the few spec file lines.

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=754554

Presence and adjustable video quality.

Presence - a small vala, gstreamer, clutter and dirac/schroedinger - based bi-directional video tool, is configurable now.

You can actually use it to establish uni- or bi-directional audio/video streams in trusted/local networks. Sometimes this can be handy, as those streams can be set-up to have a much better quality than generic VoIP solutions ...
You can even receive more than one stream.

Currently you can adjust the video size, the compression quality and the framerate to get the optimal balance between performance and capabilities of the underlying hardware.
A next thing is to tune those parameters automagically - but I'll need to find out how to detect dropped frames or an increased latency. Additional there should be a way to adjust the latency/buffer on the receiving side, to match the amount of data coming in.

Find it on gitorious.

Presence now has »picture in picture (PiP)« mode.

The next branch of presence gained PiP support, this allows the parallel view of "secondary" streams besdes the primary one. Some refactoring needs to be done, before it lands in master.
Another thing on the todo list are more convenient dialogs. Maybe someone has some styling ideas?
If you wonder how I got Big Buck Bunny into presence, just continue reading.

Expressing vapi dependencies in automake.

Today I ran into trouble defining dependencies between different vala files I use within presence.
Automake allows to define dependencies based on targets (like a library libui.a or sources ui.c). But how can I add a dependency on a .vapi? (This dependency might be needed, because app is using some code from libui.)

If I just add a dependency on the library level, make fails when looking for the library while generating the C-Code. Look at the following example:

app_SOURCES = main.vala
app_LIBADD = libA.a libB.a

In the above example main.vala already needs informations about libA and libB when valac is generating the C-Code. But this doesn't work in a parallel build, when libA or libB's vapi is not yet generated.
So I needed to tell automake/make somehow to depend on the .vapi files of libA/libB - but how? Automake doesn't know about vapis and doesn't provide any targets for them.

But it seems as this can be solved like this: You can tell automake to depend on the .c file corresponding to your .vala (and so .vapi) file, as the .c file is generated at the same time the vapi is generated. And - oh wonder - automake has targets for the c files generated by valac, therefor it's possible to use the .c files as dependencies when you mention them in the _SOURCES part of the target in question.

app_SOURCES = main.vala libA.c libB.c
app_LIBADD = libA.a libB.a

Adding the .c files to the sources doesn't do any harm, but allows app to depend on the availability of (a) the vapis and (b) the libs for libA and libB. So dependencies on both levels (code generation and linking).

Have a look at this Makefile.am for my real world example.

There is a high probability that I've missunderstood or forgot something. Hints and comments are welcome.

Da sein - Introducing presence a tool for »videoconferencing«

Intended purpose: Use this application to transmitt audio and video in an n-to-m-peers fashion in quite high quality and with a hopefully low latency. This can be the case in scenarios like connecting video walls, e-lecture or simple bi-directional two people communication.

Intended audience and requirements: This application is designed for an elite circle of users who are in a situation with:

• no NAT problems, e.g. IPv6 users
• one multicast domain or access to their DNS records
• quite high bandwidth, like 2 Mb/s
• secured transport way, aka VPN or or non-public network
• multi-core systems (single core Intel Atoms are a no-go), but something like an AMD E-350
• Fedora 16

Design: Trageting a very specific need (near-realtime bi-directional a/v transmission in a good quality, not caring about bandwidth and security) this tool also doesn't follow public standars like RFCs, but more builds ontop of available features (e.g. gstreamers rtpgstpay). On the other side standards are use:

• RTSP stream control
• dirac video codec
• vorbis audio codec
• mdns service discovery
• Mx based interface
• Fulscreen mode
• IPv6 support

Currently presence is some kind of beta. Find out more on the appropriate page.