- From: John Birch <John.Birch@screensystems.tv>
- Date: Thu, 8 May 2014 15:55:38 +0000
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>, "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <0981DC6F684DE44FBE8E2602C456E8AB014F718282@SS-IP-EXMB-01.screensystems.tv>
Yes, you precisely identify the issues here…
The architectural limitations are very relevant, since often the caption player is operating at a significant ‘distance’ from the video player and may not share an equivalent priority in terms of processing power / latency etc.
For low frame rate video it is probably desirable to pre-empt the frame boundaries so that the intended presentation duration is matched as closely as possible, or slightly exceeded, rather than any reduction in on screen presentation.
Best regards,
John
John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems
Visit us at
Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand 5E4-01
P Before printing, think about the environment
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 08 May 2014 16:49
To: John Birch; public-tt@w3.org
Subject: Re: {minutes} TTWG Meeting 8/5/2014 - ISSUE-308
You raise an interesting point that is additional to what was discussed in the meeting: we did not, as you have just done, query the constraint in IMSC that the frame rate shall be the same as the related video; rather we discussed when the constraint (as currently defined) applies. However your point is certainly relevant to the issue as raised.
I stand by my sentence from when I raised the issue: "A solution to this is to use a more generic processing of times for synchronisation purposes."
The sentence in the working draft "Each intermediate synchronic document of the subtitle document is intended to be displayed on a specific frame and removed on a specific frame of the related video object." is in general not true: it is true at authoring time but not necessarily at playback time. The general (non-frame-specific) timing intention remains true regardless of the frame rate of the video object against which the captions are actually displayed.
I see two concrete problems with requiring frame alignment of intermediate synchronic document begin and end times.
1. It is (architecturally at least) more complicated to implement a player that must achieve frame alignment, especially if the video player is a separate module from the caption player. It may impose a requirement that frame boundary events are communicated from the video player to the caption player.
2. For low frame rate video playback temporal quantisation effects can be introduced that increase the effective word reading rate required, reducing overall accessibility. (I don't mean slowed down playback, but reduced frame rate without changing the rate of passage of time in the video)
Adding the issue number to the subject line so tracker will associate it with this thread.
Kind regards,
Nigel
On 08/05/2014 16:13, "John Birch" <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> wrote:
It is a consistent misconception that frame rates in subtitle files (e.g. IMSC) must be equivalent to the frame rate of the related video object.
“... There's no constraint on related objects unless
ttp:frameRate is specified
... If you want the document to be independent of video frame
rate don't use times with frames.
nigel: This is an editorial issue on §4.4 3rd paragraph: I
think what is meant is that if time expressions with frames are
used then the frame rate in the related video object must be
the same as that set.
pal: In fact if frames are to be used then ttp:frameRate must
be set in IMSC so they are equivalent, but I can add a note to
make this clearer.
“
This is NOT true for the majority of media assets.
Exceptions are media assets that have discontinuities (due to edits) in the timecode track or are being played at a slower of faster rate than intended (which is NOT a framerate issue).
Providing that a framerate (and where applicable any dropframe flag) is provided in the subtitle file, and providing that the equivalent ‘start of media’ timecode is known (or a common value is assumed e.g. 10:00:00:00), any time values used in a subtitle file can be converted into an elapsed time through the media. Note: the start of media timecode again does not have to be a value from the media asset. It is actually the starting value in the framerate scheme used inside the subtitle file… i.e. it shows what timecode value is equal to the zero’th frame. Similarly, in a media file, providing the framerate convention (and where applicable any dropframe flag) of the media is known, the correct video image at any arbitrary play point can be established.
Or to turn that on its head, during play back, a media player (or more accurately a ‘script’ running the player) can convert the media ‘timecode’ values (or elapsed time) into a timecode value represented in any other framerate - for the purposes of subtitle synchronisation.
Simply put, it is perfectly possible to implement, for example, a player that can play a subtitle file authored with a framerate of 25 fps against a media asset that is playing at 10 fps. The elapsed play time in both the subtitle track and the media is identical and proceeds at 1s / 1s, regardless of the labelling scheme and granularity of the framerate scheme. Of course, what may suffer is accuracy in the presentation of the subtitles (from intended) if the media framerate is lower than the subtitle file framerate.
What is true is that it is easier to synchronise a subtitle file with a media asset if they have the same framerate.
Best regards,
John
John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems
Visit us at
Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand 5E4-01
P Before printing, think about the environment
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 08 May 2014 15:46
To: public-tt@w3.org<mailto:public-tt@w3.org>
Subject: {minutes} TTWG Meeting 8/5/2014
Available at: http://www.w3.org/2014/05/08-tt-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Timed Text Working Group Teleconference
08 May 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/05/08-tt-irc
Attendees
Present
nigel, pal, jdsmith, plh
Regrets
mdolan, tmichel
Chair
nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]MPEG liaison re MIME Codecs parameter
2. [5]Action items pending review
3. [6]Issues discussed and raised over the past week
4. [7]Change Proposals
5. [8]AOB
* [9]Summary of Action Items
__________________________________________________________
<trackbot> Date: 08 May 2014
<scribe> scribeNick: nigel
MPEG liaison re MIME Codecs parameter
nigel: We'll discuss this next week. There's been a lot of
email discussion on this.
action-288?
<trackbot> action-288 -- Nigel Megitt to Create issue for
codecs parameter -- due 2014-05-08 -- PENDINGREVIEW
<trackbot>
[10]http://www.w3.org/AudioVideo/TT/tracker/actions/288
[10] http://www.w3.org/AudioVideo/TT/tracker/actions/288
close action-288
<trackbot> Closed action-288.
Action items pending review
action-246?
<trackbot> action-246 -- Nigel Megitt to Take deliverables of
draft charter to TAG for scrutiny -- due 2014-04-17 --
PENDINGREVIEW
<trackbot>
[11]http://www.w3.org/AudioVideo/TT/tracker/actions/246
[11] http://www.w3.org/AudioVideo/TT/tracker/actions/246
nigel: This is a placeholder action I gave myself when we were
reviewing the draft charter. I've reviewed TAG's remit and
compared with our deliverables and concluded there's no action.
close action-246
<trackbot> Closed action-246.
action-274?
<trackbot> action-274 -- Nigel Megitt to Discuss with david
singer possibilities for f2f before going ahead and adding ttwg
to tpac agenda. -- due 2014-03-27 -- PENDINGREVIEW
<trackbot>
[12]http://www.w3.org/AudioVideo/TT/tracker/actions/274
[12] http://www.w3.org/AudioVideo/TT/tracker/actions/274
nigel: I have requested TTWG meetings at TPAC. I have not had a
response yet.
plh: We need to confirm the F2F in September by July at the
latest.
close action-274
<trackbot> Closed action-274.
Issues discussed and raised over the past week
issue-307?
<trackbot> issue-307 -- Conformance language and processor
profile rather than content profile. -- raised
<trackbot>
[13]http://www.w3.org/AudioVideo/TT/tracker/issues/307
[13] http://www.w3.org/AudioVideo/TT/tracker/issues/307
pal: I've added a note to the issue. I agree re language use
and consistency.
... IMSC is primarily a content profile.
nigel: I'm concerned with using the term profile for content
profile when it's defined as 'processor profile' in TTML1. We
know what 'content profile' means informally but it's defined
in TTML1 as a processor profile.
pal: I can amend to be explicit about content profiles too.
nigel: We should also make sure that content profile language
is aligned in TTML2 with what we want to use in IMSC
pal: One proposal is to use 'content profile'. In practice
everybody will use 'profile' so that will make the wording more
verbose.
... Can we wait for Glenn's advice before making edits?
nigel: yes, happy with that.
OPEN issue-307
s/
pal: another term that is used in SDP-US is "document profile",
which is fairly close to what IMSC uses today.
nigel: that makes sense too.
... have opened the issue.
issue-308?
<trackbot> issue-308 -- It is unclear how a document is
associated with a related video object -- raised
<trackbot>
[14]http://www.w3.org/AudioVideo/TT/tracker/issues/308
[14] http://www.w3.org/AudioVideo/TT/tracker/issues/308
pal: Related video object should be replaced with Related Media
Object everywhere.
... There's no constraint on related objects unless
ttp:frameRate is specified
... If you want the document to be independent of video frame
rate don't use times with frames.
nigel: This is an editorial issue on §4.4 3rd paragraph: I
think what is meant is that if time expressions with frames are
used then the frame rate in the related video object must be
the same as that set.
pal: In fact if frames are to be used then ttp:frameRate must
be set in IMSC so they are equivalent, but I can add a note to
make this clearer.
... I've added a note to the issue.
... I plan to wait for more comments, e.g. until the 3rd week
of May, and look at the comments received then before updating
the document.
Change Proposals
[15]https://www.w3.org/wiki/TTML/changeProposal002
[15] https://www.w3.org/wiki/TTML/changeProposal002
jdsmith: We need Glenn before closing this.
nigel: It would be helpful to have advance notice of any CPs
that we plan to work on.
jdsmith: I've reviewed internally and can discuss these on the
agenda next week - the CPs I own.
nigel: Thank you, I'll add them to the agenda.
AOB
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [16]scribe.perl version
1.138 ([17]CVS log)
$Date: 2014-05-08 14:44:07 $
__________________________________________________________
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[17] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 8 May 2014 15:56:10 UTC