Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

fix false 4K detection on some 1080i sources #3680

Merged
merged 1 commit into from
@Jalle19
Collaborator

No description provided.

@fritsch
Collaborator

That one is fine. Thanks much for looking into it.

@FernetMenta
Collaborator

hmm, this is not really correct. if 1088 is provided as height, the source of information is wrong (most likely tvh) and does not consider cropping.

@Jalle19
Collaborator

@FernetMenta I didn't dig that deep into the code to see where the 1088 value comes from, could you give me any pointers?

@fritsch
Collaborator

4K is somewhere far away. Though the content might not really match "dimension width" cause the Tool that has written it made mistakes, I still think that even: height: 1714 && width: 3656 (according to: http://en.wikipedia.org/wiki/4K_resolution ) is a good value in general to indicate 4K

@opdenkamp
Collaborator

1088 is indeed provided by tvheadend, which indeed doesn't consider cropping. it just passes whatever is provided by the mux descriptors.

@FernetMenta
Collaborator

the problem here is that some decoders could refuse to open when height is 1088 instead of 1080. tvh parser just need to parse a few bits more of sps and subtract cropping parameters from height/width.

@fritsch i agree that maybe 4k should be further specified but here we are in the 1080 block. means the 1088 would fall under a new category undetermined.

@opdenkamp
Collaborator
@adamsutton

@opdenkamp not really my area, you know me and codecs. I don't know what the full implications would be, I'll discuss with @andoma et al, and see what the say.

Thanks for the heads up though.

@opdenkamp
Collaborator

might need 2 new fields in htsp if @andoma relies on the 1088 width (which I doubt)

@adamsutton

@FernetMenta @opdenkamp just discussing with @andoma right now, he agrees subtracting cropping in TVH makes sense. He'll probably add a patch.

@Jalle19
Collaborator

So is tvheadend the only addon that doesn't account for the extra 8 pixels?

@opdenkamp
Collaborator

thanks @andoma, i'll have a look at it when i got time this evening.

@Jalle19 yes, only vdr and tvh provide their own demux

@adamsutton

@Jalle19 I'd assume that TVH and VDR are the only two affected at all

@Jalle19
Collaborator

The fix has made it into master: tvheadend/tvheadend@1b78435

I still think we should keep this change (regardless of the underlying cause) since 1920x1088 is not 4K under any circumstances.

@elupus
Collaborator

Ffmpeg demuxer reported without cropping for a long time too.

@Jalle19
Collaborator

Any news on this? We need some kind of fix for Gotham. Someone else has noticed it too: http://forum.xbmc.org/showthread.php?tid=182488

@FernetMenta
Collaborator

i would make it obvious (comment and commit message) that the root cause is tvh which sends incorrect height and this is only a work-around.

@adamsutton

@FernetMenta Though I acknowledge that TVH wasn't providing accurate information for what it was trying to say and that has been fixed. I would also think it sensible to make it clear in the comment that the original test is rather invalid given that 4K = approx 4K vertical pixels and 1088 is in no way anywhere near 4k pixels.

@FernetMenta
Collaborator

I would also think it sensible to make it clear in the comment that the original test is rather invalid given that 4K = approx 4K

absolutely agree. as fritsch pointed out 4k starts way beyond 1088. maybe we should put something between 1088 and 4k.

@Jalle19
Collaborator

Github lost my e-mail reply, here it is:

Seeing as 3840x1600 (4K at 2.40:1 aspect ratio) is 6,144 megapixels and 2880x2160 (4K at 4:3) is 6,219 megapixels, maybe we could classify anything with a pixel count over 6M as 4K?

@fritsch
Collaborator

Update your PR and we will see.

@da-anda
Collaborator

please take stereoscopics into account. We also don't want to show 4k labels for FullSBS 3840x1080 or FullOU 1920x2160. But we should be save on this if you use the 6M detection - nontheless we could/should at some point take 3D detection into acount (not sure if the item property holding the stereomode info is available at that point)

@Jalle19
Collaborator

@da-anda that shouldn't be a problem if we put the limit at 6M (your examples are both a bit over 4M). I'll update the PR later today.

Sam Stenvall change the way 4K resolution is determined.
Older versions of
tvheadend incorrectly report 1080i channels as having 1088 vertical
pixels so they got classified as 4K. The algorithm is now changed
to consider source as 4K only when the total pixel count exceeds
6 megapixels.
2489105
@Jalle19
Collaborator

Updated and rebased.

@da-anda
Collaborator

http://trac.xbmc.org/ticket/14835 is also affected by wrong 4k detection and should be resolved once this one is merged

@t-nelson
@jmarshallnz
Owner

I'm guessing they already handle it as files without size info won't show anything?

@da-anda
Collaborator

jenkins build this please and @t-nelson merge this please? :)

@MartijnKaijser

skin won't show anything if value is empty.
they use "ListItem.VideoResolution.png" so if value is empty it tries to display ".png" instead of "4k.png"

@ronie
Collaborator

either that, or they will display a predefined fallback image ;-)

@t-nelson
@da-anda da-anda merged commit 1ae61a6 into from
@Jalle19 Jalle19 deleted the branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 13, 2014
  1. @Jalle19

    change the way 4K resolution is determined.

    Sam Stenvall authored Jalle19 committed
    Older versions of
    tvheadend incorrectly report 1080i channels as having 1088 vertical
    pixels so they got classified as 4K. The algorithm is now changed
    to consider source as 4K only when the total pixel count exceeds
    6 megapixels.
This page is out of date. Refresh to see the latest.
Showing with 3 additions and 1 deletion.
  1. +3 −1 xbmc/utils/StreamDetails.cpp
View
4 xbmc/utils/StreamDetails.cpp
@@ -560,8 +560,10 @@ CStdString CStreamDetails::VideoDimsToResolutionDescription(int iWidth, int iHei
else if (iWidth <= 1920 && iHeight <= 1080)
return "1080";
// 4K
- else
+ else if (iWidth * iHeight >= 6000000)
return "4K";
+ else
+ return "";
}
CStdString CStreamDetails::VideoAspectToAspectDescription(float fAspect)
Something went wrong with that request. Please try again.