Jump to content

Two small problems with subtitles


mitsu

Recommended Posts

Two small problems with the latest 3.6.0.2:

 

1. Closed captioningb delay does not work with teletext subtitles. This is a problem becuase Canal+ subtitles come a few seconds too early.

 

2. When changing channel when a teletext subtitle is being shown the subtitle hangs on the screen forever. Or to be exact it stays on the screen until a new subtitle is shown.

Link to comment
Guest Lars_MQ

1. nothing we can do about it, teletext subtitles are shown as soon as the channel transmit them, delay not possible.

 

2. Please explain further: Does the other channel has also subtitles? Does it happen when switching to a channel with no subtitle? If it's the first, it's a minor annoyance, if it's the second, it's a bug...

Link to comment
1. nothing we can do about it, teletext subtitles are shown as soon as the channel transmit them, delay not possible.

 

2. Please explain further: Does the other channel has also subtitles? Does it happen when switching to a channel with no subtitle? If it's the first, it's a minor annoyance, if it's the second, it's a bug...

 

1. Well, I have trust on you (more than you seem to have :bye:).

 

2. The other channel has subtitles as well (most of our channels have). Subtitles disappear if the other channel does not have subtitles. Annoyance, yes. Minor if the next subtitle shows up soon. Sometimes it may take minutes.

Link to comment
1. nothing we can do about it, teletext subtitles are shown as soon as the channel transmit them, delay not possible.

Maybe for teletext but not for dvb_subtitles. At least for dvb_subtitles the rendering timing is wrong. This can be easily reproduced. e.g.: on BBC the subs are too early in the DVBViewer. Streaming to vlc will show the subs much better synchronized.

 

btw. this is known for quite a while :)

Link to comment
  • 3 weeks later...

@mitsu:

 

I subscribe to Canal+ here in Denmark and I too have problem 1. (subtitles displays too early), but only when I watch a recorded TS-file. No problems watching live TV.

 

Is there any difference for you on live and recorded TV?

 

 

 

@Anyone more skillfull than me (should be a lot around):

 

Well I actually have the same problem with Danish channels DR1, DR2 and TV2.

 

I have tried to burn a DVD (ProjectX -> DVDAuthorGUI). Then subtitles were in sync again :bye:

 

A TS-snippet (37MB) can be downloaded here (I hope)

 

http://delphi1248.diinoweb.com/files

 

Folder: Canal

Username: delphi1248

Password: abc

 

 

 

The log file when demuxing this snippet using projectX:

 

 

<<< session infos >>>

8. februar 2007  18:30:11 CET
ProjectX 0.90.03.01 (01.02.2006)

-> working with collection 0

-> save normal log file
-> write all video data
-> write all other data
-> patch c.d.flagged infos of pictures
-> add sequence end code
-> set resolution in SDE 
-> PVA: strictly specs. for audio streams
-> VOB: determine diff. Cell timelines
-> TS: ignore scrambled packets
-> TS: enhanced search for open packets
-> TS: join file segments (of Dreambox®)
-> TS: generate PMT stream dependent
-> get only enclosed PES/TS packets
-> concatenate different recordings
-> ensure 1st PES-packet start with video
-> generate PCR/SCR from PTS

-> write output files to: 'D:\'

-> Input File 0:  'D:\Winners and Sinners 2_02-08_Mix.ts' (38.986.876 bytes)
-> Filetype is TS (generic PES Container)
-> demux
-> Service ID 0x6D
-> PMT 0x6D refers to these usable streams:
Video:
PID: 0x442
Audio:
PID: 0x443(dan)
Teletext:
PID: 0x44B(eng_i100 sve_i101 nor_i201 dan_i501 fin_i601 sve_s199 nor_s299 dan_s599 fin_s699 )
Subpict.:
n/a

ok> PID 0x443 has PES-ID 0xC0 (MPEG Audio) (9212 #50) 
ok> PID 0x44B has PES-ID 0xBD (private stream 1) (TTX)  (11092 #60) 
!> PID 0x6D (PMT) (18612 #100) -> ignored
ok> PID 0x442 has PES-ID 0xEA (MPEG Video) (77644 #414) 
!> PID 0x0 (PAT) (205108 #1092) -> ignored
-> video basics: 720*576 @ 25fps @ 0.7031 (16:9) @ 10000000bps, vbvBuffer 112
-> starting export of video data @ GOP# 0
!> dropping useless B-Frames @ GOP# 0 / new Timecode 00:00:00.000
packs: 204293 100% 38986876

-> Video: fr/ ct/ 1p/ cg/ og/ dg -> 1450/ 1/ 121/ 121/ 0/ 0
-> Video length: 1450 frames @ 00:00:58.000
-> GOP summary: min. 20, max. 24 fields; contains interlaced frames
-> avg. nom. bitrate 4707819bps (min/max: 2207600/5519200)
-> set first sequenceheader bitrate to 5519200bps
---> new File: D:\\Winners and Sinners 2_02-08_Mix.m2v

--> MPEG Audio (0xC0) on PID 0x443
-> check CRC of AC-3 / MPEG-Audio L1,2
-> delete CRC in MPEG-Audio Layer1,2
-> add frames
Audio PTS: first packet 08:31:07.628, last packet 08:32:06.164
Video PTS: start 1.GOP 08:31:08.122, end last GOP 08:32:06.122
-> adjusting audio at video-timeline
!> missing syncword @  11744, @ 00:00:00.000
!> found syncword @ 12496
-> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 256kbps, CRC @ 00:00:00.000
audio frames: wri/pre/skip/ins/add 2416/0/0/0/0 @ 00:00:57.984 done...
---> new File: 'D:\Winners and Sinners 2_02-08_Mix.mp2'

--> Teletext on PID 0x44B (SubID 0x10)

-> export format: sup
-> special ttx page termination (test)
-> temp. file: Winners and Sinners 2_02-08_Mix.tt (946358 bytes)
-> looking for page number 199
Teletext PTS: first packet 08:31:07.639, last packet 08:32:06.399
Video PTS: start 1.GOP 08:31:08.122, end last GOP 08:32:06.122
->adjusting teletext at video-timeline
-> provider: FAB Teletext System
-> program: CANAL+ 
10 pages of No. 199 written...
---> new File: D:\\Winners and Sinners 2_02-08_Mix[199].sup

-> export format: sup
-> special ttx page termination (test)
-> temp. file: Winners and Sinners 2_02-08_Mix.tt (946358 bytes)
-> looking for page number 299
Teletext PTS: first packet 08:31:07.639, last packet 08:32:06.399
Video PTS: start 1.GOP 08:31:08.122, end last GOP 08:32:06.122
->adjusting teletext at video-timeline
-> provider: FAB Teletext System
-> program: CANAL+ 
10 pages of No. 299 written...
---> new File: D:\\Winners and Sinners 2_02-08_Mix[299].sup

-> export format: sup
-> special ttx page termination (test)
-> temp. file: Winners and Sinners 2_02-08_Mix.tt (946358 bytes)
-> looking for page number 599
Teletext PTS: first packet 08:31:07.639, last packet 08:32:06.399
Video PTS: start 1.GOP 08:31:08.122, end last GOP 08:32:06.122
->adjusting teletext at video-timeline
-> provider: FAB Teletext System
-> program: CANAL+ 
10 pages of No. 599 written...
---> new File: D:\\Winners and Sinners 2_02-08_Mix[599].sup

-> export format: sup
-> special ttx page termination (test)
-> temp. file: Winners and Sinners 2_02-08_Mix.tt (946358 bytes)
-> looking for page number 699
Teletext PTS: first packet 08:31:07.639, last packet 08:32:06.399
Video PTS: start 1.GOP 08:31:08.122, end last GOP 08:32:06.122
->adjusting teletext at video-timeline
-> provider: FAB Teletext System
-> program: CANAL+ 
10 pages of No. 699 written...
---> new File: D:\\Winners and Sinners 2_02-08_Mix[699].sup

summary of created media files:
.Video (m2v):	1450 Frames	00:00:58.000		'D:\\Winners and Sinners 2_02-08_Mix.m2v'
Audio 0 (mp2):	2416 Frames	00:00:57.984	0/0/0/0	'D:\Winners and Sinners 2_02-08_Mix.mp2'
Teletext 0:	10 pages of No. 199		'D:\Winners and Sinners 2_02-08_Mix[199].sup'
Teletext 1:	10 pages of No. 299		'D:\Winners and Sinners 2_02-08_Mix[299].sup'
Teletext 2:	10 pages of No. 599		'D:\Winners and Sinners 2_02-08_Mix[599].sup'
Teletext 3:	10 pages of No. 699		'D:\Winners and Sinners 2_02-08_Mix[699].sup'
=> 36.068.933 bytes written...
-> we have 5 warnings/errors.

Link to comment
@mitsu:

 

I subscribe to Canal+ here in Denmark and I too have problem 1. (subtitles displays too early), but only when I watch a recorded TS-file. No problems watching live TV.

 

You are right. This happens only when watching a recording (I seldom watch live TV).

Probably .ts -> .ts conversion with ProjectX would correct the timing. I will check this

today.

Link to comment
You are right. This happens only when watching a recording (I seldom watch live TV).

Probably .ts -> .ts conversion with ProjectX would correct the timing. I will check this

today.

TS -> TS won't change anything. Besides, the time stamps are not wrong. The culprit is the rendering method of dvbv. A/V is done in the directshow graph considering the time stamps whereas subtitles are done by dvbv unsynchronized. During live watching this can be corrected by a fixed delay. Apparently this is not working during playback. VLC could be the solution :bye:

Link to comment
TS -> TS won't change anything. Besides, the time stamps are not wrong.

 

Are there any tools for changing the time stamps in the .ts?

 

I have done as follows:

- demux the subtitles to an .srt file using ProjectX

- adjust .srt delay using Subtitle Workshop

 

Would be nice to be able to adjust subtitle delays (with .srt and also with

all other subtitles, teletext and DVB) real-time like in BSPlayer.

Link to comment
Are there any tools for changing the time stamps in the .ts?

I don't think so, and why would you do that? IMHO there's nothing wrong with the time stamps when playback with vlc is ok. Authoring a dvd is another subject.. :bye:

Link to comment
I don't think so, and why would you do that? IMHO there's nothing wrong with the time stamps when playback with vlc is ok.

 

For some reason VLC audio does not work for me (SPDIF digital output with Soundblaster USB). I also need AC3Filter functionality which is not avalable in VLC (encoding everything to 5.1 channel AC3 audio).

 

Anyway, I like DVBV and want to use it as my media center front-end.

 

As long as there is not change coming to DVBV the time stamps are wrong from my point of view.

Changing the time stamps would correct the problem.

Link to comment
As long as there is not change coming to DVBV the time stamps are wrong from my point of view.

Changing the time stamps would correct the problem.

..yes, you're right. The mountain has to come to the prophet. :bye:

Link to comment
Delay with respect to what?

..IMHO it's not related to anything. As soon as the subs are received and decoded they will be rendered and shown after this fixed delay. Manipulating the time stamps will only mess up the recording but will have no effect on the presentation time.

Link to comment
..IMHO it's not related to anything. As soon as the subs are received and decoded they will be rendered and shown after this fixed delay. Manipulating the time stamps will only mess up the recording but will have no effect on the presentation time.

 

Ok, thanks for the clarification.

 

Imho the "time" when dvb-subs are sent and received is irrelevant. They are just supposed to be sent before they are supposed to be displayed - of course. But assuming a constant "delay" from the arrival to display is simply wrong. The width of the time window between the arrival and display is like 4 secons where I live. So, there is a mismatch of +-2 seconds for "lipsync"...

 

There is a valid pts in the packet... why shoud it be modified? It should be simply honoured imho.

 

With txt-subs the situation is of course different, they are suppsed to be displayed immediately when received. The provider knows this and behaves accordingly. With dvb-subs there is no need to make such an assumption. The provioder knows also this and behaves accordingly.

 

With txt-subs there are no problems for me, their timing is razor sharp with DVBViewer.

Edited by emmel
Link to comment
There is a valid pts in the packet... why shoud it be modified? It should be simply honoured imho.

agreed, that's how it should be but for the time being the subs are standalone and not part of the directshow scheme. At least that's how I've understood it :bye:

Link to comment

Right. But the fact that txt-subs are always shown accurately makes me believe that there is indeed a good syncronization between the source and rendered through dshow. At least the latence has to be known and/or controlled, as there is always a really good lipsynch between the txt-subs and av.

 

Now pardon my french, I don't want to sound rude - I really appreciate the work done by the devs - but what exactly is the problem with dvb-subs? The dshow explanation does not convince me against the performance of txt-subs. Txt-subs are razor sharp in what comes to timing, whereas dvb-subs are displayed in an non acceptable way. What exactly is the difference between txt- and dvb-subs assuming some sort of unique and accurate timing information is available for both methods?

 

[edit] I'd just like to add that I'm really happy with the program as is, it really is a excellent piece of software. I (almost) always have the txt-sub alternative available, so no problem.

Edited by emmel
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...