wingolog

Because I egocentrically syndicate myself on advogato, which only shows your most recent post, I've shied away from multiple postings at a time. The result is mashing a bunch of topics into one writing product. This practice has its, um, aspects.

The biggest minus for me is that I have to have all of my thoughts finished at the same time. I'm going to experiment with shorter writings on marginally more focused topics. We'll see how it goes; advo folks might want to look at my last entry, which is more advo-related.

hack hack hack!

Today was Friday at Fluendo. Although I do bitch a lot about various things work-related, the fact that we have a day a week to hack on what we like is hot. It's cunning though, being at the end of the week, as the momentum of the week's projects bleed a bit onto the last day, but still. Hack hack.

So today my goal was to figure out what was up with the GUADEC video and audio archives. People are all up on my case about this, and wha? I just don't have the time I used to. (Reasons for this are in a book I'm working on.)

Anyway, so this is a prelude to the sequel to my last post on conference streaming. What I wanted to say was something about ensuring that you get archives on disk, and then to edit them later.

However I was running into problems. Sometimes totem was having trouble playing the files, for example. Wha? Also there were some sound level issues. Amusingly, in the sala d'actes, an unbalanced cable converter was picking up the radio, for example.

More disturbingly, all players (gstreamer, xine, mplayer, vlc) were playing unsynchronized audio and video for some talks. How could this be? I was getting proper timestamps from the DV feed, but somehow in the encoding process we are producing bad ogg timestamps (granulepos values)? Wha? The italics totally indicate internal dialog.

A little background: the 2005 Guadec video archives suck. I say this having been a part of the process of their creation. Most do not pass oggz-validate. This is because of problems in the GStreamer ogg muxer back then.

Oh man we were pissed, in the American sense. How could we produce bad ogg. Us the exponents of ogg. Gar. So Thomas fixed the ogg muxer For Once And For All, and the world was happy.

Another background: the way that we produced those videos was by watching the talks, then when a new speaker started, we pressed a button in a flumotion-admin client that we had running, which would tell the "disker" flumotion component to start a new file. Because we didn't have any decent cutting tools, we had to rely on this to produce files per-talk. It was a bit of work, but it produced decent results. At least we could do it from anywhere with network access.

Fast forward to 2006. I had streamed a couple of conferences, and thought that it was a pain in the ass to have to have someone rotate the conference archives manually. This was a selfish desire, that although I was the person responsible for streaming, I wanted to enjoy the conference too -- always having to rotate the videos is a drag. So I wrote a lossless cutter for ogg/theora+vorbis, the intention being to let the video capture to disk all the time, then just cut out the talks you want.

So I cut the talks. I get some segfaults, patch some code, update to latest CVS, have to patch it some more, but in the end I get cuts which I believe to be correct. Only problem is, the audio is completely off. As in, 10 seconds out of sync. This should not be possible. I mean, my GStreamer talk (not yet posted) was about synchronization. I know how to do this. What was up?

Well. Long story short, after despairing to Thomas, we figure that if the CPU usage spikes, such that the theora encoder takes too long and we get behind, that it could be that we have to drop frames. This will happen on the capture end of things, if what is processing the raw data is not reading fast enough. In theory this is fine. The encoder will still receive correctly-timestamped data. However, GStreamer's Vorbis and Theora encoders were internally assuming perfect streams (no dropped data), so internally they disregarded the timestamps they were given, choosing instead to produce continuous streams.

The end result is that our GUADEC archives are perfect, in one sense: they present no problems for oggz-validate or for ogginfo (the two programs you should use to validate ogg files). However they are incorrect. In the event of dropped data, the audio and video become unsynchronized.

This is even more of a problem for the long files I chose to record. What a PITA. I have broken files that I will need to manually patch at certain points to resync the vorbis and theora ideas of granulepos. This means we need even more custom tools. Ug.

So the end is that seekers of GUADEC archives will have to wait a bit.

what I meant to say

Writecode. Indeed what I meant to say was that after recognizing the bogus behavior of GStreamer's vorbis and theora encoders, that Mike Smith and I set out to fix them. He hacked up patches while I hacked unit tests. All I wanted to say was that it was really nice to hack GStreamer, after so long away, and that C is fun sometimes.

also wha is the new what