Bug 133365 - Captions during HLS playback flash/are difficult to read
Summary: Captions during HLS playback flash/are difficult to read
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brent Fulgham
URL:
Keywords: InRadar
Depends on: 132715
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-28 17:05 PDT by Brent Fulgham
Modified: 2014-05-28 20:22 PDT (History)
8 users (show)

See Also:


Attachments
Patch (13.40 KB, patch)
2014-05-28 17:16 PDT, Brent Fulgham
eric.carlson: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Fulgham 2014-05-28 17:05:29 PDT
Playing certain HLS media with captions results in "flashing" cues, which are difficult to read.

This is happening for two reasons:

1. HLS streams may send multiple copies of the same cue, with small differences in time values. For example, a closed caption encoding device on a live video feed might inject track cues at roughly 24 fps, with multiple cues containing the same text content, but having different start and end times. This results in cues with a 'duration' on the order of hundredths of a second, which are too quick to read.
2. A bug I introduced in <http://trac.webkit.org/changeset/166180> caused us to miss some non-WebVTT cues. This would happen when WebKit improperly decided a new cue matched an existing cue. These missing cues contributed to the "flashing" behavior.

This bug corrects both of these issues.
Comment 1 Brent Fulgham 2014-05-28 17:06:14 PDT
<rdar://problem/16584132>
Comment 2 Brent Fulgham 2014-05-28 17:16:33 PDT
Created attachment 232223 [details]
Patch
Comment 3 Eric Carlson 2014-05-28 18:47:30 PDT
Comment on attachment 232223 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=232223&action=review

Thanks!

> Source/WebCore/html/track/DataCue.cpp:-131
> -    if (cue.cueType() != TextTrackCue::Data)
> -        return false;
> -

Is it necessary to remove this? If so, how can it be safe given that we call toDataCue() below (which will ASSERT if passed a non-datacue)?

> Source/WebCore/html/track/TextTrackCue.cpp:242
> +bool TextTrackCue::isStartOfCue(const TextTrackCue& cue) const

I am not wild about this name because I didn't know what it was supposed to check until I found it and read the code. How about something like "isCueExtension", or "extendsCue"? Or something else...
Comment 4 Brent Fulgham 2014-05-28 20:07:15 PDT
Comment on attachment 232223 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=232223&action=review

>> Source/WebCore/html/track/DataCue.cpp:-131
>> -
> 
> Is it necessary to remove this? If so, how can it be safe given that we call toDataCue() below (which will ASSERT if passed a non-datacue)?

It's still part of the "isEqual" method (see below), but I'll add it back here so we can avoid ASSERTing.

>> Source/WebCore/html/track/TextTrackCue.cpp:242
>> +bool TextTrackCue::isStartOfCue(const TextTrackCue& cue) const
> 
> I am not wild about this name because I didn't know what it was supposed to check until I found it and read the code. How about something like "isCueExtension", or "extendsCue"? Or something else...

I'll use "doesExtendCue".
Comment 5 Brent Fulgham 2014-05-28 20:22:52 PDT
Committed r169440: <http://trac.webkit.org/changeset/169440>