Bdale Garbee |
2004-06-29
|
Bdale Garbee, for your viewing pleasure. Finished three minutes ago at GUADEC, already on a webserver. Just because we like you.
Present Perfect |
||||||||||||||||||||||||
|
Bdale Garbee, for your viewing pleasure. Finished three minutes ago at GUADEC, already on a webserver. Just because we like you.
Dead tired today because of excessive IRC-ing. Today Wim and I chased the bug in the server streaming from Norway (which we haven't even been to yet, so thanks a lot Rolf for all the work you've done for us !) where at random points in the stream we get weird artifacts and psychedelic colors. After fixing a bunch of other bugs that we theorized upon then verified with testcases, and plugging those, we still hadn't nailed it. After four hours I decided to start right over, going over everything, and dmesg was providing me with a clue - lots of frame read underruns from the webcam. It seemed to produce about 30% incomplete frames. More conjecturing, testing, hypothetising and verifying and then it dawned on us that maybe the fact that the webcam is serving both video and audio over USB might be problematic in the kernel. And yes, using sinesrc as the audio source material seems to give a bug-free video stream. Luckily we are planning to stream from line-in at GUADEC so we won't run into that problem. Now that we know what's causing the funny artifacts we have no problem recommending you to watch them on the low-quality stream or the high quality stream. Second red herring was me being stupid. I was fixing alsasrc so that it provides a clock that matches the data it's producing, but I also wanted to keep around a status struct object for ALSA in the element so that it didn't need to be allocated all the time. Instead of changing _alloca to _malloc however I kept _alloca, then couldn't figure out for an hour why the simple pipelines kept on crashing. Duh. The bright side is I probably will never forget to use malloc over alloca in these cases anymore.
Hectic work week. Today for example was a holiday but we're all to wired up to take it :) I would just sit at home stressing about stuff still to finish anyway. Finally got a gst-plugins release out. Apart from the usual bitching by the usual suspects it went out fine, though I am starting to loathe the general "wait and see and complain afterwards" attitude I have to deal with. I'd much prefer people actually doing testing on the prereleases I make instead of just complaining why they don't know what's going on. But I guess it's a natural human tendency - people don't like doing boring stuff like testing before releasing and people feel it is someone else's job to keep them in the loop 24/7. On some good notes, the streaming is coming along nicely. Wim has done quite some tweaking and testing to the effect that you can CTRL-Z the server, bg it, and then when you fg it after some time it manages to pick back up and stay synchronized. While creating a bunch of components today that basically took a live audio/video feed (synchronized of course) and encoded it to a) a high-quality Ogg/Theora + Vorbis stream, b) a low-quality one, c) a vorbis-only ogg stream, d) a multipart smoke + mulaw stream, and e) the a) stream captured to disk, we noticed something funny going on with the video. It started getting fringes and colourful effects. It took some thinking to realize that tcpserversink is probably dropping some buffers for some clients when CPU is close to 100% and not everything is getting enough CPU slices. Good that we picked that out today - Wim says it should be a fairly simple fix to just split it into two threads and keep a GArray of buffers around to make sure that a) clients get all buffers without dropping and b) slow clients get dropped without obstructing the fast clients. Also fun - the servers in Norway got installed this week by Rolf, and he gave me access. It took me about half an hour, including building CVS code and configuring a bunch of files, to set up the machine for streaming. Nice to be able to get packages from the projects I work on, fedora.us, GStreamer, and kernel modules combined, and just Have It Work. So, here's hoping we are ready to stream ...
Ok, so finally.
Work is progressing. Zaheer is joining in on the fun, he was able to stream from his DV camera using theora, and watch the stream on his Mac OSX machine. Meanwhile, Wim has changed the muxer somewhat so it does a nicer job of doing live streaming by making the Ogg pages smaller. Johan is doing great work on the python classes and making sure they can launch from a nice config file, so that we can wrap up the code and hand it to Matthias for live testing soon. Today I set up a relay server on a university machine using our code, and it works quite well. From that server, you can check the jpeg-like stream with audio (you need Java for this), or if you're brave and you have a player that supports Theora alpha3, try http://birgit.urgent.fm:8801, which is the relayed Ogg stream (with only Theora) from our server here. For tonight, I turned on some crap music from the office's broadcasting system and I left on the lights in case you want to see something. The view is the centre square in front of our office with the fountain, so don't expect to see much after 10 PM CET. And of course, if it's down or stuttering, all of that is still possible. This stuff is fun to hack on. Started getting my toes slightly wet in the server python code as well today. |
|||||||||||||||||||||||
|