Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problems with 2160p files on 4k screen

99 views
Skip to first unread message

SB

unread,
Sep 5, 2021, 10:44:57 AM9/5/21
to
Hi,

I have some problems playing files with 4k resolution with VLC (or also
Kaffeine) with a Raspberri pi4.

The audio works well, but the video is always all black.

At the beginning I had setting the screen resolution to 1920 x 1080.
Afterwards I have changed screen resolution to 3960 x 2160, the pi4 show well
the desktop and icons but not 2160p files.

When I try to play a HEVC x265 2160p file with any resolution, VLC show always a
black screen, while with a Full HD 1080p file it show well the footage.

The 2160p file is good because is showed well if I connect the disk to a USB
input of my TV, a SONY BRAVIA, but I prefer the functionalities
of VLC player rather that those of TV interface.

Here the captured screen of VLC 'Settings' and 'Statistic':

https://www.dropbox.com/s/7c3hcru9zwi70le/Codec.png?dl=0

https://www.dropbox.com/s/in0j7au6rmoa0p0/Statistics.png?dl=0

Note that the number in the red frame always increases.

Can anyone help me?

--
ciao
Stefano

NY

unread,
Sep 5, 2021, 1:23:33 PM9/5/21
to
"SB" <stNOOOb...@tin.it> wrote in message
news:oaj9jg5o6h9tpnbi3...@4ax.com...
Can VLC on the Pi actually play 4K video files? I've got VLC 3.0.11
(Veterinari) and when I try to play a UHD file 3840x2160 50 *frames* per
second, the VLC window disappears so I suspect it's core-dumping. The same
file plays fine on the same version of VLC on Windows 10. The file is a VLC
recording (via TVHeadend on the Pi) of multiplex 12441V on satellite Astra
28.2, as received in the UK - it's a UHD demo.
https://i.postimg.cc/N0thyQFK/UHD.png

But your file is lower resolution than the one I'm trying to play, because
yours is 3840x1600 x 24 (*) frames/sec. At least VLC is decoding the audio
and displaying that stats for your file, rather than throwing its toys out
of the pram/stroller.


(*) Shame that when analog TV in the USA was disbanded, a decision wasn't
taken to make the digital version exactly 30 fps (or 24 fps for 3:2 pulldown
film), and that the color NTSC "fix" of changing 30 to 29.97 persists ;-)
Sometimes there are advantages in being second in the race (European PAL):
we were able to design our 625/25 system on VHF (mainland Europe and
Ireland) and UHF (UK) so the sound-vision carrier spacing wouldn't collide
with the colour information once colour was introduced, probably learning
from the NTSC "experience".

SB

unread,
Sep 6, 2021, 4:26:31 AM9/6/21
to
Il giorno Sun, 05 Sep 2021 12:10:58 -0400, Dennis Lee Bieber
<wlf...@ix.netcom.com> ha scritto:

>On Sun, 05 Sep 2021 16:44:57 +0200, SB <stNOOOb...@tin.it> declaimed
>the following:
>
>
>>The 2160p file is good because is showed well if I connect the disk to a USB
>
> Actual spinning disk? Or are you using "disk" for a flash drive?

The disk is SSD M2 SATA3 external with USB3.1 interface.

>>input of my TV, a SONY BRAVIA, but I prefer the functionalities
>>of VLC player rather that those of TV interface.
>>
>
> Is there anything else using the USB ports of the R-Pi. Are you using
>USB2 or USB3 port? Is the device even rated for USB3 speeds? {At least the
>4B has a real Ethernet, not a hidden Ethernet<>USB chip}

The SSD is connected to USB3 (blue) input of my RPI4b with 4GB of RAM.


> What else is running on the R-Pi?

Only Anydesk is running in background, but without active connections.

I also noticed that with 3960 x 2160 screen during the remote connection with
Anydesk the mouse is slow and the percentage of CPU is over 60-70% with only the
desktop active.

Instead with HD screen is all normal.

Probably the UHD resolution is a big job for an rpi.


> That is NOT showing a "2160p" file... If anything, it is a 1600p30 (if
>not 1600i30; suspect p30 as it says "frame rate" not "field rate") -- the
>term "2160p" refers specifically to a video with a pixel height of 2160
>lines, regardless of width.


The footage comes from a smartphone with resolution 3840 x 1600, I can see it
with my TV without problems, I had also try to recode it with Avidemux, the file
size is increased but the rpi screen with VLC (or Kaffeine also) is always
black.



--
ciao
Stefano

A. Dumas

unread,
Sep 6, 2021, 6:04:18 AM9/6/21
to
SB wrote on 06-09-2021 at 10:26:
> I also noticed that with 3960 x 2160 screen during the remote connection with
> Anydesk the mouse is slow and the percentage of CPU is over 60-70% with only the
> desktop active.

Normal 4k resolution is 3840x2160 (not 3960!), that shouldn't be a
problem for a Pi 4. You can even enable 4k @ 60 fps mode, if your
monitor/tv supports it. Look at the configuration program in the menu or
in the Terminal: sudo raspi-config. Best leave it at 30 fps for
compatibility and a little more performance headroom, though. Also, only
one of the hdmi ports can do 60 fps.

The ssd should be able to handle this easily. There have been reports of
slow external ssd's, depending on the chipset of the interface
apparently. I don't know details, have a look at the forums on the rpi
website. My Samsung T5 works well.

VLC on the Pi doesn't have hardware acceleration, that's probably the
limiting factor. Try playing the file with omxplayer from the command
line (Terminal), that's the only player with hardware accel. as far as I
know.

Also, the HW accel. is only for h.265 encoded video, I think? Not h.264.
But the Pi 4 should be fast enough to do that in software. Maybe not in
4k, though? I don't know.

SB

unread,
Sep 6, 2021, 12:39:20 PM9/6/21
to
Il giorno Mon, 6 Sep 2021 12:04:16 +0200, "A. Dumas"
<alex...@dumas.fr.invalid> ha scritto:
It's not a SSD or USB issue.

After some search it seems that VLC don't use hardware acceleration with the GPU
and hardware for HEVC x265 decoding.

https://www.raspberrypi.org/forums/viewtopic.php?t=253359
https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=246837

It seems that the solution can be Libreelec with Kodi, but Libreelec is a media
player dedicated os, I'd rather stay on Raspbian os.

Someone said that VLC in a future version can work with HEVC and 4k file, I
hope so.


--
ciao
Stefano

A. Dumas

unread,
Sep 6, 2021, 1:12:02 PM9/6/21
to
SB <stNOOOb...@tin.it> wrote:
> After some search it seems that VLC don't use hardware acceleration with the GPU
> and hardware for HEVC x265 decoding.

Yes, that's what I said. Not for anything.

> https://www.raspberrypi.org/forums/viewtopic.php?t=253359
> https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=246837
>
> It seems that the solution can be Libreelec with Kodi, but Libreelec is a media
> player dedicated os, I'd rather stay on Raspbian os.

Yes, that's because behind the scenes it uses the only hardware accelerated
video player on the Pi, which I also mentioned: omxplayer. So you already
have the solution, you just need to use the terminal. Or write your own
GUI/web interface around it, if you don't like Libreelec.

SB

unread,
Sep 7, 2021, 3:17:58 AM9/7/21
to
Il giorno Mon, 6 Sep 2021 17:12:01 -0000 (UTC), A. Dumas
<alex...@dumas.fr.invalid> ha scritto:

>SB <stNOOOb...@tin.it> wrote:
>> After some search it seems that VLC don't use hardware acceleration with the GPU
>> and hardware for HEVC x265 decoding.
>
>Yes, that's what I said. Not for anything.

Ok, you was right, man.

>> https://www.raspberrypi.org/forums/viewtopic.php?t=253359
>> https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=246837
>>
>> It seems that the solution can be Libreelec with Kodi, but Libreelec is a media
>> player dedicated os, I'd rather stay on Raspbian os.
>
>Yes, that's because behind the scenes it uses the only hardware accelerated
>video player on the Pi, which I also mentioned: omxplayer.

With omxplayer I had only the message:

Vcodec id unknown: ad
have a nice day ;)`

And I didn't find the way to add codecs to omxplayer.

> So you already
>have the solution, you just need to use the terminal. Or write your own
>GUI/web interface around it, if you don't like Libreelec.

I could write a simple interface in Python, but there are a lot of interfaces
available on the web if the program runs well with codecs:

https://raspberrypi.stackexchange.com/questions/22200/is-there-any-gui-mode-for-omxplayer


--
ciao
Stefano

A. Dumas

unread,
Sep 7, 2021, 3:36:39 AM9/7/21
to
Well, it seems I was behind the times (I never play videos with my
Pi's). From https://github.com/popcornmix/omxplayer :

"Note: omxplayer is being deprecated and resources are directed at
improving vlc.

This is due to: omxplayer uses openvg for OSD and subtitles which isn't
supported on Pi4. omxplayer uses openmax which has been deprecated for a
long time and isn't supported with 64-bit kernels. omxplayer does not
support software decode omxplayer does not support advanced subtitles
omxplayer does not support playback from ISO files. omxplayer does not
integrate with the X desktop

Please try using vlc. If there are features of omxplayer that vlc does
not handle then try reporting here."

So, VLC is the official way forward. If it doesn't work, ask in the
official forums, I guess.

A. Dumas

unread,
Sep 7, 2021, 3:40:32 AM9/7/21
to
BUT! The developer(s?) seem to be stuck. No hardware helpeing at 4k,
yet. See https://github.com/RPi-Distro/vlc/issues/47

SB

unread,
Sep 7, 2021, 12:51:17 PM9/7/21
to
Il giorno Tue, 7 Sep 2021 09:40:31 +0200, "A. Dumas"
<alex...@dumas.fr.invalid> ha scritto:
Yep, VLC doesn't work for now .

I have downloaded Libreelec and I will try it on a dedicated SD, and at the end
I have always the TV.

Thank you for the tips,
bye

Scott Alfter

unread,
Sep 9, 2021, 2:44:18 PM9/9/21
to
In article <sh2uej$d5m$1...@dont-email.me>, NY <m...@privacy.invalid> wrote:
>(*) Shame that when analog TV in the USA was disbanded, a decision wasn't
>taken to make the digital version exactly 30 fps (or 24 fps for 3:2 pulldown
>film), and that the color NTSC "fix" of changing 30 to 29.97 persists ;-)

I suspect that would've made those cheap (free in some cases?) converter
boxes to bring analog-only TVs into the digital era not-so-cheap, as they
would've needed some way to convert 30-fps input to 30000/1001-fps output.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

NY

unread,
Sep 11, 2021, 12:48:01 PM9/11/21
to
"Scott Alfter" <sc...@alfter.diespammersdie.us> wrote in message
news:4Cs_I.46036$Dr.3...@fx40.iad...
> In article <sh2uej$d5m$1...@dont-email.me>, NY <m...@privacy.invalid> wrote:
>>(*) Shame that when analog TV in the USA was disbanded, a decision wasn't
>>taken to make the digital version exactly 30 fps (or 24 fps for 3:2
>>pulldown
>>film), and that the color NTSC "fix" of changing 30 to 29.97 persists ;-)
>
> I suspect that would've made those cheap (free in some cases?) converter
> boxes to bring analog-only TVs into the digital era not-so-cheap, as they
> would've needed some way to convert 30-fps input to 30000/1001-fps output.

I was always surprised that the FM sound circuitry in TVs couldn't tolerate
the sound carrier being tweaked slightly to move it out of the way of the
colour sideband.

You'd have thought that when the NTSC colour system was being designed,
they'd have picked up the potential "collision" of sound and colour on
broadcast TV, and decided to choose a different multiple of the line
frequency for the colour sub carrier, rather than fudging things by tweaking
the frame rate slightly. Or was the multiple that they used "special" in
that it had lots of small factors whereas other nearby ones had a large
factor (it's more difficult to design an analogue division circuit that
divides by a large number).


Was 625/25 lucky, or was the ratio of CSC to line frequency chosen carefully
to avoid a collision with sound, given NTSC's problems?

gareth evans

unread,
Sep 11, 2021, 2:22:36 PM9/11/21
to
On 11/09/2021 17:48, NY wrote:
> Was 625/25 lucky, or was the ratio of CSC to line frequency chosen
> carefully to avoid a collision with sound, given NTSC's problems?

The urban legend has it that coming as it did about the time that
digital electronics and computing were coming into TV that it was
chosen because 405 in decimal becomes 625 when converted to octal.


Folderol

unread,
Sep 11, 2021, 4:29:23 PM9/11/21
to
Ummm. Nope.

625 line TV started in the early 1960s. As a TV repairman, I was watching the
BBC2 trade tests in the mid 1960s. I didn't come across any digitisation till
the 1970s, by which time the TV rental business was collapsing.

The PAL system did learn a lot from the NTSC mistakes. The real killer was
swapping the phase of the colour sub carrier on alternate lines. The result was
that any phase shift giving a drift towards red on one line, would be towards
green on the next line, and your brain averages these out so you don't notice
anything wrong :)

--
W J G

gareth evans

unread,
Sep 11, 2021, 6:40:58 PM9/11/21
to
On 11/09/2021 21:29, Folderol wrote:
> On Sat, 11 Sep 2021 19:22:34 +0100
> gareth evans <headst...@yahoo.com> wrote:
>
>> On 11/09/2021 17:48, NY wrote:
>>> Was 625/25 lucky, or was the ratio of CSC to line frequency chosen
>>> carefully to avoid a collision with sound, given NTSC's problems?
>>
>> The urban legend has it that coming as it did about the time that
>> digital electronics and computing were coming into TV that it was
>> chosen because 405 in decimal becomes 625 when converted to octal.
>
> Ummm. Nope.


Ummm. Yep.

Definitely an urban legend.


NY

unread,
Sep 12, 2021, 12:05:47 PM9/12/21
to
"Folderol" <gen...@musically.me.uk> wrote in message
news:20210911212921.57eab400@devuan...
> 625 line TV started in the early 1960s. As a TV repairman, I was watching
> the
> BBC2 trade tests in the mid 1960s. I didn't come across any digitisation
> till
> the 1970s, by which time the TV rental business was collapsing.

In November 2020, Talking Pictures TV showed a recording of a Saturday Night
at the Palladium programme which had been made using colour cameras in 1966
but probably only broadcast in B&W and never repeated in colour until TPTV
did so. Jimmy Tarbuck was the compere and The Seekers were one of the groups
performing.

Results were a bit variable: there was a lot of variation in contrast, hue
and saturation between one camera and another, and one early camera shot
resulted in horrendous mis-registration of colours, and that camera angle
was not used any more in the broadcast.

> The PAL system did learn a lot from the NTSC mistakes. The real killer was
> swapping the phase of the colour sub carrier on alternate lines. The
> result was
> that any phase shift giving a drift towards red on one line, would be
> towards
> green on the next line, and your brain averages these out so you don't
> notice
> anything wrong :)

Yes, doing the maths (which I can't be arsed to do now, but I remember
working it out when I was doing Elec Eng at university), if there is a phase
error phi, it cancels itself out on adjacent lines (which are two lines
apart because of interlacing) and multiplies the chroma component by
cos(phi) so you get a slight reduction in saturation but no hue shift.

I believe that some TVs displayed the lines as they were received (one with
a positive hue error and the next with a negative hue error of the same
value) and relied on the brain to average it. Other more elaborate ones used
a one-line delay and electronically averaged the two lines so the same
colour info (with no hue error) was output on both lines.

I remember a friend's parents had a Hitachi TV which had a hue control, even
though it was designed for UK PAL broadcasts. This was because Hitachi avoid
paying a licence fee for using the delay mechanism which was patented, and
instead converted PAL to NTSC and decoded it using a non-standard 4.43 MHz
NTSC decoder - so a hue control was required to correct any hue errors that
may occur and which would have been corrected automatically in a "real" PAL
TV.

Folderol

unread,
Sep 12, 2021, 4:00:54 PM9/12/21
to
>
>I believe that some TVs displayed the lines as they were received (one with
>a positive hue error and the next with a negative hue error of the same
>value) and relied on the brain to average it. Other more elaborate ones used
>a one-line delay and electronically averaged the two lines so the same
>colour info (with no hue error) was output on both lines.

Ah yes! I'd forgotten about those delay lines. The early glass ones were the
size of a tobacco tin, but when they got on to using ceramics that shrunk down
to a credit size area about 5mm thick. Eventually they got it down to an 8 pin
DIL chip!

--
W J G

SB

unread,
Sep 16, 2021, 7:24:11 AM9/16/21
to
Il giorno Tue, 07 Sep 2021 18:51:16 +0200, SB <stNOOOb...@tin.it> ha
scritto:


>I have downloaded Libreelec and I will try it on a dedicated SD,


After a week of usage, I can say that 4K footages are played perfectly on Kodi
on LibreElec os.

Moreover my SONY TV remote control is easily integrated with Librelec, probably
using the I2C interface present in HDMI cable.

There are a world of plugins, and is pretty usable, afterall a good acquisition.


--
ciao
Stefano

A. Dumas

unread,
Sep 17, 2021, 3:04:35 AM9/17/21
to
On 16-09-2021 13:24, SB wrote:
> Il giorno Tue, 07 Sep 2021 18:51:16 +0200, SB ha scritto:
>> I have downloaded Libreelec and I will try it on a dedicated SD,
>
> After a week of usage, I can say that 4K footages are played perfectly on Kodi
> on LibreElec os.
>
> Moreover my SONY TV remote control is easily integrated with Librelec, probably
> using the I2C interface present in HDMI cable.
>
> There are a world of plugins, and is pretty usable, afterall a good acquisition.

Very nice. Thanks for the update.
0 new messages