Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

definition of a title safe area for overscan #442

Open
guohuideng opened this issue May 1, 2018 · 7 comments
Open

definition of a title safe area for overscan #442

guohuideng opened this issue May 1, 2018 · 7 comments

Comments

@guohuideng
Copy link

  1. What is the problem
    a general description of overscan and title safe concept is here
    https://en.wikipedia.org/wiki/Overscan

In short, the video/graphic rendering area is not guaranteed on some display devices, So the very outer portion of intended video/graph image may be "cut off" by the boundary of the display device. This problem was more pronounced in older TV but they still exist even on modern devices.

Therefore the content provider usually need to prepare their video/graphics for potential overscan problem, by putting the most important content away from the boundary of the video/graphics, so even if the outer potion is cut off the video/graphics won't break.

Text is special because it cannot only be cut off, but also should not be distorted. So the suggested "safe area" is even smaller.

  1. Who is having the problem
    A renderer that uses TV as display device(like Chromecast) would risk from overscan problem if put the text too close to the boundary of the image, it is better to take a precautionary measure: make sure that the text is rendered within the title safe area.

There is no strict definition of "how big the title safe area should be". There are only commonly accepted practice, like 5% margin on each side.

  1. The problem for web
    Renderers that doesn't use TV( in full screen mode) is unlikely to suffer from overscan problem.

Meanwhile, some other thoughts of mine: 1.)I don't think forcing a very small margin would hurt any aesthetic result. (in fact I think it looks much better than having the text touching the boundary.) 2) Also, a vast majority of the content I know of already have a much bigger margin than that is required by the "title safe" concept. So enforcing such "minimal margin" would only affect on a small portion of the content.

@nigelmegitt
Copy link
Contributor

I think it looks much better than having the text touching the boundary.

If there are any authors out there who have a good reason to make the text touch the boundary they really won't thank you for making a spec change that prevents it just because your personal preference didn't incorporate their use case.

In short, the video/graphic rendering area is not guaranteed on some display devices, So the very outer portion of intended video/graph image may be "cut off" by the boundary of the display device.

It's a much worse problem than this - sometimes the video rendering area is a completely different aspect ratio to the video, and the player may either show black bars top and bottom or left and right, or scale the video anamorphically, or scale the video to fill the display, cropping it.

See also #375 where there's further discussion of this issue.

@guohuideng
Copy link
Author

Hi nigelmegitt

I am not suggesting any change of the spec. I wrote this up to explain the problem as asked in
#441

I plan to implement something that will only take affect in Chromecast. To us the text being cut off is not acceptable. We have issues that the text being cut off, (due to overscan or not) that we have to take care of. I said "it looks better when it touches the boundary" is not just my personal preference, but the very popular choice that most of carefully edited webvtt and many other subtitle display choose. I stated it as a reason that I believe this won't result a complain if I move the text away from the boundary.

I don't expect our partners would tell us that they want to the text to touch the boundary. If that really happens (I'd be surprised) we could communicate with them about concept of title safe area. Text being cut off almost guarantees a complain.

////////////////////////////////////
I understand different implementation/application has their own point of view and their unique concerns/problems. So I think it's best that we implement something that only affect on our own product.

On the other hand, if someone else has the similar issue the information here may be helpful.

@guohuideng
Copy link
Author

BTW we have complain about text touching the boundary even it's not cut-off.

@nigelmegitt
Copy link
Contributor

As a content provider, if I want the text block to touch the boundary, but I cannot author it so, then I will complain. If some content providers have a requirement to be able to author content so that it does not touch the boundary, then the spec needs to be clear about how to achieve that - I have no problem with that. But IMO it needs to be an authorial decision not one forced on all authors and users whether they like it or not. Maybe the spec is not so clear now about how to achieve precise positioning to achieve this though?

@dwsinger
Copy link

dwsinger commented May 2, 2018

I tend to agree with Nigel; also consider that if we decide that text should always leave a margin by the boundary (a) we'll have an endless discussion of 'how much' and (b) we'll have to decide if any margin the author specifies is additional or replaces. I suppose that suggests we could set a default that authors can override, but...complex...

@guohuideng
Copy link
Author

Hi guys,

No worries. This is not suggestion for any change in spec. The implementation I will make won't affect anyone else except for our product.

Also it turned out that it is difficult to enforce margin on the side. Therefore I will give up that one and ask content provider to fix it.

@gkatsev
Copy link
Collaborator

gkatsev commented Jul 11, 2018

It sounds to me like this can probably be resolved, if no spec changes are required?

Most people seem in agreement that having a section about a margin or edge boundary could be problematic and would either requiring reversing #379 or have a new feature that's similar if not go the route of IMSC as mentioned in #379 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants