56 replies to this topic

[littlesat]

hannels which are shown as 1080p25 SDR in H9 have these options in mediainfo:
(BBC1, Vox-RTL @19E, DR1, CT24 @23.5E, RAI1, TRT @42E, TVR1-2 @16E, )
Scan type: MBAFF
Scan type, store method: Interleaved fields

as Trial wrote, the real interlaced channels, shown as 1080i25 SDR in H9:
Scan type: Interlaced
Scan type, store method: Separated fields

I’m afraid this is most likely caused by misinformation from the broadcaster and/or drivers from the box.

[Trial]

Hi littlesat,

I am not sure about that. More than 20 years ago on DVD you already could find interlaced and progressive DVDs. Both types of DVD were 50 frames but there was a progressive flag which told the player how to reconstruct the picture.

 

Ralf

[Huevos]

Hi littlesat,

I am not sure about that. More than 20 years ago on DVD you already could find interlaced and progressive DVDs. Both types of DVD were 50 frames but there was a progressive flag which told the player how to reconstruct the picture.

 

Ralf

Ralf, are you sure it wasn't 50 cycles, not 50 frames? i.e. screen refreshed 50 times, but a full interlaced frame is 2 cycles.

[Trial]

Hi,

the content was the same. The decoder got 50 frames, 1 with odd and 1 with even lines. With the progressive flag these frames were joined to 1 image and this was either send once to get 25 progressive frames per second or this image was displayed twice to stay with 50FPS in case the TV was unable to display less than 50Hz.

 

I am 101% sure as this was the reason for me buying a quite expensive no name DVD player to be able to view a video in 25 (or 23.976) Hz progressive on my 1st projector > 20 years ago:-)

 

btw. full interlaced frame with 2 cycles is not correct because if it is really interlaced 2 consecutively frames are taken with a time difference of 20ms. This is the reason you need a deinterlacer and this uses different techniques (for instance bob and weave) which work better or worse. Easy to see in VLC because there you can select different deinterlacer.

 

Ralf

[korsan]

"ServiceInfo">Is4K
About ServiceInfo converter and the resolution/icon shown at the infobar.
When playing mediafiles with a ultrawide resolution such as 3840x1606p24 or 3840x2076p24, then the ServiceInfo sees this as 'IsHD', it must be 'Is4K' of course. 

You can see this by the wrong icon shown at the infobar in MoviePlayer.

 

"PliExtraInfo">VideoCodec
In Openpli 8.0 with H9 Hisi box and ffmpeg.
For PliExtraInfo converter, is it possible that the option "VideoCodec" can also work for mediafiles?
Because this only works for .ts files and live channels. It shows AVC/HEVC etc, with this you can see the videocodec easily at the infobar.

 

[Huevos]

Is4K is based on the height.

return self.videoHeight >= 2100

 

[littlesat]

Mmmm letterbox format with 4K... maybe we need to consider to change this to the VideoWidth > 1920 ? The same might happen with hd when it is eg 720p and letterbox. So also change is HD to the width >= 1280?
Or just change the check from 2100 to >1080.....?

Edited by littlesat, 25 April 2021 - 08:04.

[Trial]

Hi,

with is more reliable because the height depends on the aspect/ration whereas the with is normally fixed. I already had this discussion with Andy concerning AR a few years ago.

 

Ralf

[littlesat]

The height was choosen from the beginning in e2. When 4K came I did not want to change too much. So I gambled the 2100 criteria... not thinking about letterbox. But still I think we should change to width here.

Edited by littlesat, 25 April 2021 - 08:34.

[Huevos]

The height was choosen from the beginning in e2. When 4K came I did not want to change too much. So I gambled the 2100 criteria... not thinking about letterbox. But still I think we should change to width here.

Why was height chosen not width? I think width could be better for all of them.

[littlesat]

Why I don’t know as years years ago dmm engineer made that call

[Huevos]

I guess we have to remember these formats didn't exist at the time.

[littlesat]

That’s true...

Edited by littlesat, 25 April 2021 - 16:10.

[littlesat]

Merged

[Ev0]

Merged

And completely broken the resolution detection.

 

You need to switch the values to width too.

[IanSav]

Hi Littlesat,

 

Why I don’t know as years years ago dmm engineer made that call

 

Height is normally (always) used for resolution detection as broadcasters often play with the width to economise on broadcast bandwidth.  In Australia for quite a long time FHD was broadcast as 1440 x 1080.  I believe this trick is still often used.

 

The reason the trick is used is because the human eye can often perceive height changes in an image but it is quite poor at noting width resolution changes.  That is, as long as the image stretches to fill the screen the eye will not readily notice the lower horizontal resolution.  It is the same reasoning as to why users note the size of TV images by height rather than width.

 

https://www.scienced...ntal-resolution

https://www.tvtechno...pixels-or-lines

 

Changing from height to width detection for any of the broadcast resolutions (at least) is a big mistake.  There are lots of explanations on this topic try Googling for more information.

 

Regards,

Ian.

Edited by IanSav, 26 April 2021 - 03:29.

[Abu Baniaz]

OpenViX file is here if you want to compare.

https://raw.githubus.../ServiceInfo.py

[littlesat]

I do not understand why change it from height to width is wrong.... it solves all issues on broadcasting.... the issue/goal/scope here are streams with letterbox in hd or 4K resolution which are not used in broadcasting.
Openvix version has the issue....
The play with with ranges are covered in the criteria I did chose.
But we can go back to height of course and just adjust the 2160 for 4K to >1080 or so....

Edited by littlesat, 26 April 2021 - 07:39.

[nautilus7]

Hi Littlesat,

 

Why I don’t know as years years ago dmm engineer made that call

 

Height is normally (always) used for resolution detection as broadcasters often play with the width to economise on broadcast bandwidth.  In Australia for quite a long time FHD was broadcast as 1440 x 1080.  I believe this trick is still often used.

 

The reason the trick is used is because the human eye can often perceive height changes in an image but it is quite poor at noting width resolution changes.  That is, as long as the image stretches to fill the screen the eye will not readily notice the lower horizontal resolution.  It is the same reasoning as to why users note the size of TV images by height rather than width.

 

https://www.scienced...ntal-resolution

https://www.tvtechno...pixels-or-lines

 

Changing from height to width detection for any of the broadcast resolutions (at least) is a big mistake.  There are lots of explanations on this topic try Googling for more information.

 

Regards,

Ian.

In Greece as well, ERT Sports HD broadcasted at 1440x1080i, for a long time... 

[Ev0]

I do not understand why change it from height to width is wrong.... it solves all issues on broadcasting.... the issue/goal/scope here are streams with letterbox in hd or 4K resolution which are not used in broadcasting.
Openvix version has the issue....
The play with with ranges are covered in the criteria I did chose.
But we can go back to height of course and just adjust the 2160 for 4K to >1080 or so....

The issue is you have left the values used for height.

This is what we use in OpenBH which works for 99% of all streaming and iptv aswell as broadcasts to detect the correct resolutions.

			elif self.type == self.IS_SD:
                                return video_height < 578
			elif self.type == self.IS_HD:
				return video_height >= 720 and video_height < 1440
			elif self.type == self.IS_SD_AND_WIDESCREEN:
				return video_height < 578 and video_aspect in WIDESCREEN
			elif self.type == self.IS_SD_AND_NOT_WIDESCREEN:
				return video_height < 578 and video_aspect not in WIDESCREEN
			elif self.type == self.IS_1080:
				return video_height > 768 and video_height <= 1440
			elif self.type == self.IS_720:
				return video_height > 481 and video_height <= 768
			elif self.type == self.IS_576:
				return video_height > 1 and video_height <= 578
 			elif self.type == self.IS_480:
				return video_height > 1 and video_height <= 480
 			elif self.type == self.IS_4K:
                                return video_height >= 1460
				

Edited by Ev0, 26 April 2021 - 10:45.