Add one to the list of things that might make people think I'm a geek:
* Looking at your bookshelf for a book on the Linux kernel and realizing that you own four.
On a separate note, the Senate passed a bill granting immunity to all the telecoms for participating in illegal wiretapping for the NSA. How quickly we forget that the reason in the late 1970's that Congress came up with the FISA court in the first place was to stop the executive branch from illegal surveillance (See Project SHAMROCK). If you're really interested in how FISA came about, pick up a copy of James Bamford's The Puzzle Palace in paperback. It's a really good read.
Wednesday, July 9, 2008
I've decided: ATSC Closed Captioning is a bitch
So I didn't get much development work done last night. I did however get Leopard installed on my MacBook, reformatted my old iBook with 10.3 so I could give it to Packy for Parrot development, bisected the v4l-dvb tree to isolate a bug, and watched that really stupid National Treasure movie.
Tonight I got back to working on the ATSC closed captioning. "In our last episode", I had gotten Kaffeine to render the caption data, but the characters were not shown in the correct order. It turns up this is because the characters are arriving in transport order, and they need to be resequenced into picture frame order before they can be announced to the CC decoder (since the render information for a packet is dependent on previous events).
So now I'm going to need some sort of ordered linked list, where I insert packets as they arrive and periodically flush the list into the decoder if the render event with the lowest PTS matches the PTS currently being viewed. I will also have to keep track of when I last flushed the buffer so I don't insert events into the list that have already been rendered in the previous frame.
Oh yeah, and it has to share code with the existing DVD CC rendering, so I have to work within the constraints of the existing code and not break anything.
Tonight I got back to working on the ATSC closed captioning. "In our last episode", I had gotten Kaffeine to render the caption data, but the characters were not shown in the correct order. It turns up this is because the characters are arriving in transport order, and they need to be resequenced into picture frame order before they can be announced to the CC decoder (since the render information for a packet is dependent on previous events).
So now I'm going to need some sort of ordered linked list, where I insert packets as they arrive and periodically flush the list into the decoder if the render event with the lowest PTS matches the PTS currently being viewed. I will also have to keep track of when I last flushed the buffer so I don't insert events into the list that have already been rendered in the previous frame.
Oh yeah, and it has to share code with the existing DVD CC rendering, so I have to work within the constraints of the existing code and not break anything.
Monday, July 7, 2008
Kaffeine ATSC Closed Captioning Working... Almost
I made changes to Xine to start the libsupcc plugin and parse the EIA-608 closed caption info, and it's showing up in Kaffeine.
The only problem I'm having now is that because the frames can arrive out of order, the closed caption info is garbled (it's rendering the right characters but in the wrong sequencing). For example, "Hello world." is being rendered as "eHlloo Wlr.d"
I need to write some sort of sequencer to handle this. It might also have something to do with field1/field2 correlation. But it's certainly progress to see stuff show up on the display and it not be complete garbage.
The only problem I'm having now is that because the frames can arrive out of order, the closed caption info is garbled (it's rendering the right characters but in the wrong sequencing). For example, "Hello world." is being rendered as "eHlloo Wlr.d"
I need to write some sort of sequencer to handle this. It might also have something to do with field1/field2 correlation. But it's certainly progress to see stuff show up on the display and it not be complete garbage.
Sunday, July 6, 2008
More on ATSC closed captioning under Kaffeine
I got the Xine built from source now, and did some more debugging trying to figure out how the closed captioning support works. There is code for EIA-608 (used for DVD support), but there doesn't appear to be any way to load the plugin externally - it only kicks in if Xine detects closed captioning present in the stream (and the means of detection varies by standard).
Unfortunately, I don't think I can force it on/off, so I'm going to have to patch Xine to detect the info.
After some digging around through the spec and the MythTV source code, I figured out that the CC data is in the user_data section of the VOB. It's covered in ATSC a/53 Part 4 Section 6.2.3.1. For now I would be happy even if I just got the older style EIA-608 working.
I'm still not sure though how I'm going to correlate the CC stream locale information with the content contained in the PSIP EIT-0 entry (so the user knows which languages the various CC streams are in). I think the DVD code in Xine has some sort of convention for defining a callback, but I don't know how to use it yet.
At least in the short term, if I can get the content decoded I can just refer to them as "CC1,CC2,CC3,CC4", which is what Elgato EyeTV2 does (I don't have EyeTV3 so I can't say if they have improved it).
Unfortunately, I don't think I can force it on/off, so I'm going to have to patch Xine to detect the info.
After some digging around through the spec and the MythTV source code, I figured out that the CC data is in the user_data section of the VOB. It's covered in ATSC a/53 Part 4 Section 6.2.3.1. For now I would be happy even if I just got the older style EIA-608 working.
I'm still not sure though how I'm going to correlate the CC stream locale information with the content contained in the PSIP EIT-0 entry (so the user knows which languages the various CC streams are in). I think the DVD code in Xine has some sort of convention for defining a callback, but I don't know how to use it yet.
At least in the short term, if I can get the content decoded I can just refer to them as "CC1,CC2,CC3,CC4", which is what Elgato EyeTV2 does (I don't have EyeTV3 so I can't say if they have improved it).
Saturday, July 5, 2008
ATSC closed captioning under Kaffeine
Spent a good portion of last night reading about the various specs for closed captioning under ATSC (a/65, a/53, EIA-608, EIA-708). Pretty interesting stuff.
There are actually two separate versions of CC info sent in digital television, the first being the old fashioned "line 21" closed captioning with a single font, limited to Latin characters, and little control over how it is rendered (originally used for analog NTSC). The newer version of the protocol, which is targeted at digital, is much more advanced in that it supports eight fonts, different font colors/backgrounds, UNICODE characters, and control over where it is rendered on screen.
It's an area that I still needed to get working under Kaffeine.
Unfortunately both EIA-608 and EIA-708 are specifications that have to be paid for (a little over $100 each). It's annoying when a FCC mandated standard isn't freely available.
After digging into the code, it turns up though that Kaffeine relies on Xine to do the subtitle parsing and rendering (Kaffeine just lets you pick whether to turn it on/off and which stream to view). This is good in the sense that any work I do will benefit other applications that use libxine, but it's bad because it's another project I have to figure out how to build from source, and it appears I have already broken my Ubuntu box trying to compile it.
On the upside, there is already partial support for both EIA-608 and EIA-708 in libxine because it's used for DVD playback. So in theory I just have to get xine to detect the presence of CC from the PMT block. Once I do this, Kaffeine should "just work" without any changes. If this works out, I won't have to buy the EIA specs at all.
Why the hell did the ATSC bury the CC data in the video stream, instead of separating it out into another MPEG program stream like DVB does?
On a sidenote, debugging Kaffeine is a bitch:
There are actually two separate versions of CC info sent in digital television, the first being the old fashioned "line 21" closed captioning with a single font, limited to Latin characters, and little control over how it is rendered (originally used for analog NTSC). The newer version of the protocol, which is targeted at digital, is much more advanced in that it supports eight fonts, different font colors/backgrounds, UNICODE characters, and control over where it is rendered on screen.
It's an area that I still needed to get working under Kaffeine.
Unfortunately both EIA-608 and EIA-708 are specifications that have to be paid for (a little over $100 each). It's annoying when a FCC mandated standard isn't freely available.
After digging into the code, it turns up though that Kaffeine relies on Xine to do the subtitle parsing and rendering (Kaffeine just lets you pick whether to turn it on/off and which stream to view). This is good in the sense that any work I do will benefit other applications that use libxine, but it's bad because it's another project I have to figure out how to build from source, and it appears I have already broken my Ubuntu box trying to compile it.
On the upside, there is already partial support for both EIA-608 and EIA-708 in libxine because it's used for DVD playback. So in theory I just have to get xine to detect the presence of CC from the PMT block. Once I do this, Kaffeine should "just work" without any changes. If this works out, I won't have to buy the EIA specs at all.
Why the hell did the ATSC bury the CC data in the video stream, instead of separating it out into another MPEG program stream like DVB does?
On a sidenote, debugging Kaffeine is a bitch:
- I don't know the ins/outs of libtool so I had to "make install" to get debug libraries
- I ran around in circles for half an hour only to realize my debug libraries weren't being used. I was running the kaffeine binary out of my working directory, but it was using the libraries that shipped with Ubuntu
- Kaffeine forks at startup so I have to run it in one window and then attach to the running pid ("--sync" doesn't appear to work)
- KDE Debug (kdbg) appears to be crap.
- I need a new office chair for my desk because my back is bothering me from using what used to be one of Gran's kitchen chair's.
Thursday, July 3, 2008
Perhaps David Banner needs anger management therapy?
I think perhaps David Banner should stop focusing on exotic genetic or radiation treatments and get some anger management counseling.
Sure, I can appreciate him turning into the Hulk under some circumstances. Like in the pouring rain with a flat tire, he injures himself when his tire iron slips and then he turns into the Hulk. I can get that.
But last night I watched an episode where he turned into the Hulk because he didn't have enough change for a payphone:
While we're on the subject, I can think of times when turning into the Hulk could be a good thing. Like this morning when some asshole in a Cadillac SUV blew through a red light while talking on his cellphone and nearly ran me over. Why couldn't I have turned into the Hulk then? I'd squish his car like a tin can!
Sure, I can appreciate him turning into the Hulk under some circumstances. Like in the pouring rain with a flat tire, he injures himself when his tire iron slips and then he turns into the Hulk. I can get that.
But last night I watched an episode where he turned into the Hulk because he didn't have enough change for a payphone:
- David runs up to old rotary payphone and dials "0" for Operator. No answer.
- Calls information and the operator gets the number for police department, but the person can't connect the call for him.
- Dials police department. "Please insert another 35 cents."
- "I DON'T HAVE 35 CENTS!!!!" Eyes turn white. Shirt starts to tear.
While we're on the subject, I can think of times when turning into the Hulk could be a good thing. Like this morning when some asshole in a Cadillac SUV blew through a red light while talking on his cellphone and nearly ran me over. Why couldn't I have turned into the Hulk then? I'd squish his car like a tin can!
Tuesday, July 1, 2008
Subscribe to:
Posts (Atom)