But passing the file name as argument to a py.test invocation selects only the doctest from that file (wtf!?). Instead, you need to call it like this:

This is documented in the section advanced test selection and running modes of the py.test documentation, although I fail to see how this is advanced.

There were a number of interesting Talks. I especially liked the talk of our DPL, and those about piuparts and git-buildpackage. In contrast to the other LinuxTag talks, we had a livestream of our talks and recorded (most) of them. The kudos for setting this up goes to Alexander Wirt, who spent quite a few hours to get it up and running.

I have to apologize for being late in bringing my Notebook, which was intended to do the theora encoding of the livestream. This was a misunderstanding on my part, I should have known that this is not going to be setup in the night before show time… So to compensate the extra hours he had to put in for me, I offered to do the post processing of the videos.

Basic approach for post processing

The main goal of post processing the videos was (of course) to compress them to a usable size from the original 143 GB. I also wanted to have a title on each video, and show the sponsors at the end of the video.

My basic idea to implement that consisted of the following steps:

1. Create a title animation template.
2. Generate title animations from template for all talks.
3. Use a video editor to create a playlist of the parts title – talk – epilogue.
4. Run the video editor in batch mode to generate the combined video.
5. Encode the resulting video as ogg theora.

As always with technology, it turned out that the original plan needed a few modifications.

Title animations

Originally I wanted to use Blender for the title animation, but I knew it is quite a complicated bit of software. So I looked for something simpler, and stumbled across an article that pointed me towards Synfig Studio for 2D animation. This is also in Debian, so I gave it a try.

I was delighted that Synfig Studio has a command line renderer which is just called synfig and that the file format is XML, which would make it simple to batch-create the title animations. My title template can be found in this git repository.

Batch creation of title animations

I used a combination of make and a simple python script to replace the author name and the title of the talk into the synfig XML file. The data for all talks is another XML file talks.xml. Basically, I used a simple XPath expression to find the relevant text node and change the data using the ElementTree API of lxml python module.

The same could be done using XSLT of course (for a constant replacement, see this file) but I found it easier to combine two XML files in python.

Note that I create PNG files with synfig and use ffmpeg to generate a DV file from those. Originally, I had synfig create DV files directly but those turned out quite gray for some reason. I am now unable to reproduce this problem.

Combining the title animation with the talk

For joining the title animation with the talk, I originally went with OpenShot, which somebody of the video team had running at the conference. My idea was to mix a single video manually and just replace the underlying data files for each talk. I expected that this would be easy using the openshot-render command, which renders the output video from the input clips and the OpenShot project file. However, OpenShot stores the video lengths in the project file and will take those literally, so this did not work for talks of different play times…

I considered working with Kino or Kdenlive but they did not look more appropriate for this use case. I noticed that OpenShot and Kdenlive both use the Media Lovin’ Toolkit under the hood, and OpenShot actually serializes the MLT configuration to $HOME/.openshot/sequence.xml when rendering. I first tried to read that XML file from python (using the mlt python bindings from the python-mlt2 package) but did not find an API function to do that. So I just hard coded the video sequence in python.

I ran into a few gotchas on the way:

• it’s easy to segfault MLT from Python (something is wrong with the refcounting)
• generating ogg theora using MLT from Python (which uses libavformat) resulted in a bad audio/video synchronisation of the output (more than 1 second for 1 hour of video)
• generating dv from MLT and running ffmpeg2theora on the result is disk-bound on my quad core system – so use a pipe to ffmpeg2theora

Things to improve

While the results look quite okay for me now, there is a lot of room for improvement.

• What bothers me the most is the unequal audio volume between talks. We should apply something like replay gain for normalization. I did not find an easy way to add this to the processing pipeline, otherwise it would have been included already.
• Original recordings have different aspect ratios, so after combining them, there is a letterbox added. This is the case for Goswin’s talk on Multiarch for example. I’d rather have the title distorted or letter boxed, if I get around to it, I will fix it in the script.
• Most of the recordings concentrate on showing the slides. As we did not keep the raw camera data, but recorded the DVswitch output, we missed the opportunity to show the speaker more often in full screen. Looking at the same slide becomes quite boring after half a minute, so it would be better
  to show the speaker more often. That would require quite a bit of man power for post processing though, I have to admit that I did not watch all the hours of video.
• We could cut a bit off the talk at start and end, when the speaker discusses where he is available for questions. It is not of interest anymore after the conference is over.

Availability

• git repo (browsing): http://www.landschoff.net/git/?p=mdc-video.git;a=summary
• git repo (clone): git://landschoff.net/mdc-video
• Videos: http://meetings-archive.debian.net/pub/debian-meetings/2010/minidebconf-berlin/ (note: most of these are in german, apart from the DPL and the LXDE talk)

Now that most of the work is finished, I get the following error message from my python mock:

What’s going on here? This issue reminds me of a bug of my ancient Debian times which affected loading of GTK theme engines from python-gtk. The bug (#38138) is so old, it’s not even in the BTS archive anymore…

The problem is illustrated by the following example program (consisting of three files):

demo.c

1 2 3 4 5 6 7

#include <Python.h> void test_python() {     Py_Initialize();     PyRun_SimpleString("import threading\n"); }

main.c

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <stdio.h> #include <dlfcn.h> int main(void) {     const char *error;     void *handle = dlopen("./demo.so", RTLD_LAZY | EXTRA_RTLD_FLAGS);     void (*test_python)();     *(void**) &test_python = dlsym(handle, "test_python");     if ((error = dlerror())) {         fprintf(stderr, "%s\n", error);         return 1;     }     printf("Calling test_python @ %p in shared object @ %p.\n", test_python, handle);     (*test_python)();     dlclose(handle);     printf("Feels fine, finishing.\n");     return 0; }

run_it.sh

1 2 3 4 5 6 7 8 9 10 11 12 13

#! /bin/sh gcc -shared `python-config --includes` -o demo.so demo.c `python-config --ldflags` echo "Running example with default RTLD flags:" gcc -DEXTRA_RTLD_FLAGS=0 -o main main.c -ldl ./main echo echo "Passing RTLD_GLOBAL in addition:" gcc -DEXTRA_RTLD_FLAGS=RTLD_GLOBAL -o main main.c -ldl ./main echo

On my system, this results in the following output:

torsten@pulsar:~/sh_bug$ ./run_it.sh
Running example with default RTLD flags:
Calling test_python @ 0xb77084bc in shared object @ 0x96bc018.
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/threading.py", line 11, in 
    from time import time as _time, sleep as _sleep
ImportError: /usr/lib/python2.5/lib-dynload/time.so: undefined symbol: PyExc_ValueError
Feels fine, finishing.

Passing RTLD_GLOBAL in addition:
Calling test_python @ 0xb783f4bc in shared object @ 0x95e1018.
Feels fine, finishing.

Sucky. So embedding Python into an application is easy but if you want to use the interpreter and its modules from a plugin, you are out of luck. Somebody knows a way around this problem? The only solution I can think of is to link libpython.so into each of the python plugins.

Update: Work around

Small update: For my current problem, the work around is to run the application with the python library preloaded: LD_PRELOAD=/usr/lib/libpython2.5.so.1.0 app. Back to adding functionality…

This is the error message:

Traceback (most recent call last):
  File "foobar.py", line 9, in 
    main(**options)
TypeError: main() argument after ** must be a dictionary

The problem here is that the options result from OptionParser is instead of type optparse.Values, which is not derived from dict (huh?!). Quoting the Python language reference:

If the syntax **expression appears in the function call, expression must evaluate to a mapping, the contents of which are treated as additional keyword arguments.

Here are two ways to fix the problem:

I know I prefer (b), especially if there are many options to pass on. Another work around is used by the pylit project (extending the optparse.Values class).