Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Question: Closed Caption? Goto page Previous  1, 2, 3, 4  Next
Post new topic  Reply to topic View previous topic :: View next topic 
PostPosted: Thu Oct 06, 2005 12:55 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




The problem is that to change everything to use Xlib functions like XDrawString, I would have to rewrite huge amounts of xine and mplayer. These applications already have closed caption decoders that use OSD. They didn't use Xlib functions, probably for good reasons. I would have to replace hundreds of lines of code and for no apparent reason. And open source projects don't appreciate people changing massive amounts of their code. In fact the mplayer people spat on one simple change I suggested recently! Smile

Quote:
You mentioned something about out-of-order and resorting to PTS. You might be able to depend on the MPEG temporal frame order to assemble the text, but you probably will have to use the PTS to know when to display it, or scroll it if necessary.

The PTS seems to be working and it solves both problems.

Quote:
You can also use the temporal frame order for checking if any frames have dropped out. Not sure how you would handle that on display, maybe with spaces or some character to indicate something was missed.

But most frames don't have caption data so it's impossible to say whether any data was lost.

Quote:
The NTSC CC I've seen was like watching an old ASR33 teletype, because it was displaying the text so slowly and only in capitals. I haven't yet seen DTVCC so I don't know how fast the text updates.

EIA-608 (the NTSC captioning) can do much more than that. To be FCC compliant, it has to support lowercase, italics, and many control codes. They have "paste on" captions that appear instantly as well as scrolling captions.

Some captioning is only in caps, usually live events where there's someone typing them in real time. Some dramas are also captioned in capitals with sounds in lowercase ("(phone rings) HELLO?") and some use upper and lowercase properly with the sounds in italics ("(phone rings) Hello?"). There is no one practice that everyone follows.

Quote:
I can understand the reasons for the elaborate methods for doing DVD subpicture blending, because of the nature of the DVD subpictures and the fact that some cards do not have OSD, but for CC text it seems like overkill, to me.

But notice that their menus don't use Xlib functions either. If you take a look at how they render text, it's pretty complicated, especially the sections that support FreeType fonts.
Quote:
I don't know if the EU has mandatory CC, but if they don't, it might explain why XDrawString never occured to our friends in Germany and Hungary and elsewhere in the world.

Europe has Teletext which is a hugely popular text-based system that delivers lots of data, much more than just captions. It doesn't appear to be supported in xine or mplayer at all. Teletext is included in the DVB-T standard but it looks like the data is sent in a separate stream instead of embedded with the video.

Quote:
You might want to make sure the CC text doesn't overwrite the subpicture area, in case someone is playing a DVD that has both subtitles and CC, but as far as I can tell there are no subpictures for DTV. Not sure how you would go about reconciling that for DVD. Instruct the user to use one or the other? CC has descriptive text like [RAINDROPS FALLING] that are usually missing from DVD subpictures that have dialogue only.

The text captions that can be included in DVD's have a different tag than the tag with ATSC captions so those will be displayed by the old code.
View user's profile Send private message
PostPosted: Fri Oct 07, 2005 4:26 am Reply with quote
Guest
 




Scott Larson wrote:
The problem is that to change everything to use Xlib functions like XDrawString, I would have to rewrite huge amounts of xine and mplayer. These applications already have closed caption decoders that use OSD. They didn't use Xlib functions, probably for good reasons. I would have to replace hundreds of lines of code and for no apparent reason. And open source projects don't appreciate people changing massive amounts of their code. In fact the mplayer people spat on one simple change I suggested recently! Smile


I wasn't suggesting replacing anything, just adding some functions to do the Xlib stuff. I guess it's hopeless. Over-engineering has screwed the pooch. I spit on mplayer, myself. It doesn't even bother to mute the audio when bad A52 packets are received. Makes me want to choke the developers with my bare hands so I can hear them squeal like their poorly designed code. Sorry for wasting your time, but I really do appreciate you taking the time to reply and set my dumb ass straight.
PostPosted: Sat Oct 08, 2005 1:27 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




There's a huge amount of code in xine and mplayer for OSD stuff (especially the menus) and I can only assume it's all there for a reason. I can guarantee that anyone planning on replacing the code and checking it in will be wasting their time. Most Open Source projects will always have the problem of not having a real QA process to test major changes and multimedia projects are the worst since they have to support all kinds of crazy ill-defined standards that sometimes change for no reason.

But the OSD code that's there should work. The XvMC jumpiness should be solved by changing how mplayer queues free surfaces. Tthe bug also happens when using the menus or displaying other info on the OSD but since those things aren't on the screen very long, they're not much of a problem. Captions are on the screen almost all of the time so the bug will drive you nuts.

Now I don't know an easy way to get the EIA-608 code in mplayer to support fonts, underlining, colors, and a lot of other control codes that have always been in the standard. The code was designed to display ASCII and Unicode characters only. Whoever wrote it just wanted to get some characters on the screen and didn't care about the standard. It may be easier to add DTVCC support instead since the mplayer people understandably prefer people to add new code rather than change existing code.

The xine code appears to have more support for EIA-608 but I haven't gotten to the bottom of it yet.
View user's profile Send private message
PostPosted: Sat Oct 08, 2005 1:40 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Anonymous wrote:
It doesn't even bother to mute the audio when bad A52 packets are received. Makes me want to choke the developers with my bare hands so I can hear them squeal like their poorly designed code.

I've been using nothing but mplayer for two years and I've never had a problem with bad A52 packets causing any distracting audio at all. Most of the time I can't even tell they're missing and I get them all the time on our WB station which is running half-power right now.

It's understandable that no one has added code to do this because the demux code that detects a bad packet is a layer or two away from the code that would mute the audio. They want you to follow the unwritten rules of what layer does what, so something simple like this can end up requiring new functionality in several different areas of the code.

It's great that they want to keep the layers of code separate, but it would have been better to have had that policy for the tons of existing code that's already breaking those rules. The worst thing you can do is model new code against code that's already there. It's guaranteed to get rejected! Very Happy
View user's profile Send private message
mplayer makes a52 squeal like a pig
PostPosted: Sun Oct 09, 2005 7:12 am Reply with quote
Guest
 




Scott Larson wrote:
I've been using nothing but mplayer for two years and I've never had a problem with bad A52 packets causing any distracting audio at all.


Maybe your soundcard is using pass-through and the corrupted packets are being rejected by the surround receiver. No such luck here, CT5880 with S/P-DIF coax. The chip has no pass-through mode, so the S/P-DIF output is simply a digital mirror of the PCM output.

However, xine doesn't squeal like a pig. Why is that? I spit and something that rhymes with spit on mplayer.
PostPosted: Mon Oct 10, 2005 10:13 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Over the years I've used three different soundcards (an old Soundblaster, one on the motherboard and a Soundblaster Live!) and now I'm using a 5.1 receiver through SP/DIF (AC-3). With all these setups, CRC errors on A52 packets have always just caused mplayer (at worst) to drop the sound just like xine.

I think your problem is dependent on your unusual setup and that's why no one has fixed it. Have you asked about this on the mplayer-users list? It may be easy to fix but no one knows about the problem.
View user's profile Send private message
PostPosted: Mon Oct 10, 2005 10:45 am Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Hey Scott..

Could you make the subs appear as normal subs so that they can be processed as normal subs? e.g. position on screen, dump to file (would be very helpful as we could backup subs after re-encode)
View user's profile Send private message Visit poster's website
PostPosted: Mon Oct 10, 2005 11:10 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dorphell wrote:
Could you make the subs appear as normal subs so that they can be processed as normal subs?

That would depend on what that means exactly. Smile

Quote:
e.g. position on screen,

EIA-608 does support placing the captions on different areas of the screen. I've seen it and the standard mentions it but I haven't found the control code that does that. Also, mplayer will make it difficult to implement this because, like I've said, the EIA-608 code that's there is really designed to do nothing more than print ASCII characters at the bottom of the screen.

Quote:
dump to file (would be very helpful as we could backup subs after re-encode)

My latest version of the patch has a CAPTION_LOG #define that will print the captions to stderr instead of displaying them on the screen. This is nice for avoiding the jumpy XvMC problem.
View user's profile Send private message
PostPosted: Mon Oct 10, 2005 12:20 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Quote:
My latest version of the patch has a CAPTION_LOG #define that will print the captions to stderr instead of displaying them on the screen. This is nice for avoiding the jumpy XvMC problem.


Does it print time-codes in a way that with a script or some sort of post-processing of the log, you can later on convert it to a usable subtitle format? SRT, SC, etc?
View user's profile Send private message Visit poster's website
PostPosted: Mon Oct 10, 2005 8:48 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I'm not familiar with those formats. The #define just prints the plain text. The PTS isn't available in that part of the code but I guess it could be changed with some work if you needed a timecode.
View user's profile Send private message
PostPosted: Tue Oct 11, 2005 3:37 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




The SRT format was created by a program called SubRip. It's a simple ASCII based format.

It goes something like this:

1 00:02:26,407 --> 00:02:31,356
Blah blah balh
haha

2 00:02:31,567 --> 00:02:37,164
Foooooooooooooo foo foo
Etc etc etc

But anyway, I don't really care what format it is as long as mplayer can use it as subtitles. It would be neat to save those once I throw away the original transport stream.

I'll play around with that CAPTION_LOG, maybe i'll be able to get mplayer to print some timestamps.

Actaully.. if you could extract the time each caption is suppose to be displayed, that would help too as mplayer has a sub format that uses that. i.e.:

# first number : wait this much after previous subtitle disappeared
# second number : display the current subtitle for this many seconds

15 3
A long long, time ago...

0 3
in a galaxy far away...

--------
Can you extract those 2 variables from the PTS data and print it along with the caption while CAPTION_LOG is defined?
View user's profile Send private message Visit poster's website
PostPosted: Tue Oct 11, 2005 4:21 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dorphell wrote:
The SRT format was created by a program called SubRip. It's a simple ASCII based format.

Oh yes. People on the mplayer-dev mailing list are at each other's throats arguing over the "simple ASCII based format" files this thing generates right now. Rolling Eyes
Quote:
Can you extract those 2 variables from the PTS data and print it along with the caption while CAPTION_LOG is defined?

As you'll see in the patch, the PTS isn't passed to the code that prints the captions but it certainly could be used to create these timecodes if it were passed.

Don't forget there's still a stupid bug that's dropping two characters sometimes. I really gotta hunt that down.
View user's profile Send private message
PostPosted: Tue Oct 11, 2005 5:32 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Scott Larson wrote:
Don't forget there's still a stupid bug that's dropping two characters sometimes. I really gotta hunt that down.


I don't know if you're aware of this or not, but this bug is somewhat random... it happened to me just now with caption that 5 minutes ago was shown and this stream has been on my HD for a few days, so there was no change, and no change in how I played the file.
View user's profile Send private message Visit poster's website
PostPosted: Wed Oct 12, 2005 8:59 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I don't understand what you're saying. Five minutes? Few days? No change?
View user's profile Send private message
PostPosted: Wed Oct 12, 2005 2:45 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Sorry, I'll rephrase...

I recorded the show show Medium from NBC on Monday. That's been sitting on my hard drive.

Yesterday, I played this file with `mplayer -subcc medium.ts` and watched a certain scene. The captions were perfect.

About 5 minutes later, I ran the same command and watched that same scene but one of the captions was missing 2 characters so I assumed this is the same bug you were talking about... character pairs being dropped sometimes.

The caption was something like:
DOCTOR: You'll be fine.

and when it failed it displayed:
CTOR: You'll be fine.

Hope that cleared it up.
View user's profile Send private message Visit poster's website
Question: Closed Caption?
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 3 of 4  
Goto page Previous  1, 2, 3, 4  Next
  
  
 Post new topic  Reply to topic  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin