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':
formatting link
formatting link
Note that the number in the red frame always increases.
On Sun, 05 Sep 2021 16:44:57 +0200, SB declaimed the following:
Actual spinning disk? Or are you using "disk" for a flash drive?
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 EthernetUSB chip}
What else is running on the R-Pi?
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.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
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.
formatting link
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".
Il giorno Sun, 05 Sep 2021 12:10:58 -0400, Dennis Lee Bieber ha scritto:
The disk is SSD M2 SATA3 external with USB3.1 interface.
The SSD is connected to USB3 (blue) input of my RPI4b with 4GB of RAM.
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.
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.
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
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.
Well, it seems I was behind the times (I never play videos with my Pi's). From
formatting link
:
"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.
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(
formatting link
Top-posting! \_^_/ >What's the most annoying thing on Usenet?
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?
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.
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 :)
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.
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.
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!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.