immersive-web / proposals

Initial proposals for future Immersive Web work (see README)
95 stars 11 forks source link

Use case descriptions for subtitles in 360° #39

Open pthopesch opened 5 years ago

pthopesch commented 5 years ago

Introduction

The following use cases for subtitles in 360° videos were collected, implemented and tested in the ImAc-project (for detailed information see here: www.imac-project.eu). The use cases refer to issue #40, that summarizes requirements derived from these use cases and list existing standards in that area.

Use case descriptions

Short description of environment (for all use cases)

A 360°, non-stereoscopic video is played on a Tablet, PC or via a Head Mounted Display (HMD). The user can look around while the video is playing, either by turning his or her head (in case of playback via HMD) or by moving the tablet, or by click and draw with the mouse over the video.

Use case 1 – always-visible with arrow

Subtitles are displayed centered at the bottom of the current viewport. As such, they are always visible to the viewer. When the speaker (or another sound source represented by the subtitle) is NOT visible within the current viewport, a small arrow is displayed left or right of the subtitle, pointing into the direction where the speaker is located in the scene (as shown in Figure 1). As soon as the viewer looks in that direction and the speaker becomes visible, the arrow disappears. The arrow indicates the position only horizontally.

grafik Figure 1

Use case 2 – always-visible with radar

Subtitles are displayed centered at the bottom of the current viewport/field of view. As such, they are always visible to the viewer. At the bottom right of the viewport, a “radar” is displayed. It indicates the current viewing direction by a light green color and the horizontal position of any active subtitle by a small circle as shown in Figure 2. The circle has the same color as the subtitle.

grafik Figure 2

Use case 3 – fixed-positioned Subtitles are displayed at a fixed position related to the video as shown in Figure 3. Thus, they are just visible to the viewer, when he or she looks into the direction of the subtitle. The subtitles are placed at the position of the corresponding speaker.

grafik Figure 3

TrevorFSmith commented 5 years ago

It seems like forward motion on this Issue has stalled so I'm going to close it. If you have a plan for how to make progress then ping me and we can re-open it.

andreastai commented 5 years ago

@TrevorFSmith Please reopen, see comment in #40 for the reasoning. Thank you : )

TrevorFSmith commented 5 years ago

I have re-opened #40 and am planning to discuss this in a CG call on April 23rd. (see note on #40)

astearns commented 5 years ago

For cases 1 and 2, are there any concerns about multiple speakers that we should take into account?

For case 1, I am assuming the spatial orientation and display of the arrow are more important than any particular placement. Placing the arrow on the second or shortest line would likely be difficult using current CSS, but placing the arrow on the left or right edge of the caption block (or start/end of the text) would be easy.

andreastai commented 5 years ago

@astearns Yes, I think that this question came up. In 2D captions it not uncommon that in one caption block you have two speakers where each of the speaker text is on different lines.

Placing the arrow on the second or shortest line would likely be difficult using current CSS

Most often the line breaks in captions are forced by the subtitler. In this case this would not be a problem, right?

andreastai commented 5 years ago

@TrevorFSmith Can you also re-open this use case issue? Thanks : )

astearns commented 5 years ago

Most often the line breaks in captions are forced by the subtitler. In this case this would not be a problem, right?

If those forced breaks have markup, then no problem. If the forced breaks are just content, then there might be a problem IF there are specific needs for arrow placement (right side of shortest line, left side of last line) that do not have solutions in current CSS selectors