RPi 4 8GB - LE 10 can't play 4k "Lupa sync test" video in h264 format. Strange thing is the audio playback happens, not sure if video require an actual 4K display.
CodeCodec: H264 - MPEG-4 AVC(part 10) (avc1) Video resolution: 3840x2160 Frame rate: 25
Pi4 only supports hardware acceleration of UHD content if it's h.265/HEVC encoded. This file is h.264/AVC encoded and the Pi only supports that codec up to 1080p resolution, so won't play UHD/4K h.264/AVC content.
I am playing .mkv files. Some are DD+ others Dolby True Hd and as I've already said it doesn't work through HDMI either.
I have a gaming pc plugged directly into the TV which displays in 4k and gives 7.1 sound.
If i plug the pi into the receiver, I get 7.1 sound but no 4k. If I plug it into the TV, I get 4k but no 7.1.
Sorry - I thought in your earlier post you said you were using Optical from your TV to your AVR - not ARC?
However ARC can't carry True HD, PCM 7.1 etc. (it's limited to PCM 2.0, DD, DTS and in some implementations DD+) - only eARC (introduced much later than your AVR) can do HD Audio.
Can you clarify how you are getting True HD?
What 7.1 DD+ sources on your Pi are you playing?
You won't get PCM 7.1/FLAC 7.1/Dolby True HD 7.1/DTS HD MA 7.1 audio from the Pi to your AVR over an optical cable.
The only 7.1 codec that is just about potentially supported via that route is DD+ 7.1 (and possibly 6.1 DTS ES which is very rare) - which isn't that widespread. Kodi will transcode other codecs to 5.1 DD, but not 7.1 DD+.
Also - what other 7.1 HDMI sources have you successfully passed through via HDMI to your TV and then via optical to your AVR? Internal streaming apps on your TV don't count in the same way - as they aren't using the HDMI route.
Display MoreHi,
sorry for stepping into this thread without ever testing the images provided here.
But I am planning to step into UHD content and I am willing to test related patches.
My current TV is limited to HD (1080p) and I would like to ask whether Kodi is able,
maybe with some patches added, to display UHD (2160p) content on a new UHD-
capable TV set yet to be bought.
My setup is:
- Intel Rocketlake i9-11900tT
- ASRock Z590 Extreme with HDMI 2.0b output
- kernel 5.13.x
- mesa3d 21.2.1
- media-driver 21.3.2
Do I need to use a fiber-based HDMI 2.0 cable to cover the 12m distance between
the PC and the TV? Currently I am using a HDMI 1.3 copper-based cable.
Will fiber-based cables still route CEC signals?
Is the limitation "4K60 4:2:0 8-bit" of the USB CEC adapter a problem in real life?
The bigger issue for you won't be UHD - it will be Wide Colour Gamut HDR.
Most UHD - but by no means all UHD - is also Wide Colour Gamut (aka Rec 2020) and HDR (usually HDR10). The UHD downscale to HD isn't usually a problem, so UHD Rec 709 (i.e. 'normal' colour) SDR video will be no problem at all. However for HDR stuff (which is Rec 2020) the player will have to also 'tone map' which is converting the HDR and Wide Colour Gamut video into the narrower colour range and narrower dynamic range of regular HD SDR content. That's the trickier task. (*)
If you plan on going UHD at some point then the 8-bit limitation will be an issue - as HDR really needs 10-bit - though that limitation may not be an issue at 4K30 and below.
(*) There are now some HDR Wide Colour Gamut 1080p TVs on the market - if you have one those you may be in a better situation with HDR content.
This sounds like a power supply issue. In my experience you get ticking from 2.5" external drives when the power supply isn't quite up to it. I always had to use a powered USB hub to feed 4TB drives from my Pi 4B (I now used a Celeron box with my 4TB drive), as the stock Pi supply wasn't quite able to provide enough power.
I only play UHD 4K content and I'm pretty sure all content has the same video resolution. If I play the content on my PC in Kodi, it fills the screen (1080p).
Could it be my Sony Receiver that's causing this? Or is that unlikely? Anything else I can try?
What happens if you take your Sony Receiver out of circuit?
What content plays normally, what content plays 'shrunk'? Be useful if you logged it. For file-based stuff posting the Media Info of a file that plays OK and a file that plays shrunk could be useful too.
That said - Netflix full-screen content and Netflix 2:1 content are both likely to be carried in a 3840x2160p video standard - with the 2:1 stuff having black bars top and bottom. However if watching the exact same content on your PC fills the screen - then that suggests something is odd.
Can you playback the Netflix stuff that's shrunk using an alternative player solution to compare and check it's not your projector doing something odd?
Display MoreHi guys,
There is something that's troubling me for a while and I wonder if you guys can give me some explanation of this.
I have a Raspberry Pi 4 with LE 10 beta (latest) running through a Sony STR-DN1080 and then to my Optoma 4K UHD-35 projector.
I'm playing 4K HDR movies and Netflix and some movies are full frame (the dark gray area on the screen) and some movies are not. They are playing in a smaller frame (the light gray area on the screen). As far as I can see, both movies have the same resolution in the video stream. Does anybody know why some files display in a smaller frame?
I can't wrap my head around this and I find it quite annoying tbh.
Thanks in advance guys!
Cheers,Rob
Does the width definitely change - and are all the sources output at the same video resolution (i.e. 3840x2160p)
Do all the source files (apart from DRMed stuff you can't analyse) have the same native resolution ?
A lot of TV drama is now shot 2:1 (i.e. 16:8) so you get a bit of letterboxing (black bars top and bottom), but black bars left and right too is unusual.
SD stuff - particularly 50Hz stuff has the 702x576 vs 720x576 issue to contend with too - lots of platforms get this wrong. (702x576 = 4:3 or 16:9 - with 9 samples of padding left and right to create a 720x576 raster that is wider than 4:3 or 16:9)
I'm not a projector user - so can only compare with my Sony UHD HDR TV - but that shows everything I expect to fill the screen filling the screen (though Kodi - on at least some platforms - may have issues with some 720x576 stuff in PAR/DAR terms I think)
Display MoreHi there,
newbie here.
Is there an option to disable Hdr?
im not happy with some of my HDR Video Files and i like them better when i turn HDR off.
I cannot switch it off on my TV, so it seems Libreelec is forcing it.
Not the End of the world since i can use older builds for those files, but it would be a nice option
What do you mean by 'disable HDR'?
Do you mean convert HDR10 to SDR and output SDR (i.e. tone map)?
HDR10 (Rec 2020 with a PQ EOTF) video played back unconverted in SDR (Rec 709 with an SDR EOTF) will look unwatchable bad.
(HLG is a bit different as the HLG EOTF is compatible with an SDR EOTF - though Rec 2020 content played back unconverted and displayed as Rec 709 still looks awful)
Random hunch: Check the whitelist and remove 4096x2160p "4K" entries leaving only 3840x2160p entries. Better?
Was about to say the same. 4096x2160 modes can be a real pain. I always whitelist them out as none of my displays are 4096x2160.
I am glad that you saw that the SAT>IP server was not at fault. In my experience the SAT>IP servers work very well, I have a secondary CE server based on amlogic S912 that forwards the DVB-T channels, via SAT>IP, to a main server tvheadend LE based on intel x86_64 located 300 km away, and that in turn, It can forward all TV channels (tuners: USB, SAT>IP, and IPTV) to a CE client also based on amlogic S912 located 3000 km from the main server. Well, everything works great.
Yep - I had a set-up that used a Raspberry Pi with a DVB-T2 tuner to forward channels between countries - though I didn't use SAT>IP, I eventually used an SRT protected tunnel (initially I just used plain https transport stream)
Ah - I'm on HTS Tvheadend 4.3-1909~gc66e3bc7d which I think I compiled from GitHub myself (I usually create a .deb pkg when I build TV Headend under a Debian OS)
Afraid I'm not expert enough to give any more advice on the set-up of the SAT>IP tuner.
I don't use MC much - I usually just SSH in for command line access and copy stuff manually, or use an SFTP client like FileZilla for remote file transfer.
I would be surprised if Kathrein have much experience of their SAT>IP Tuners being used with TV Headend internally - but stranger things are known to happen!
Out of interest - if you go STATUS->Stream do you also see any Transport Errors as well as Continuity Errors?
Also - I've read that Continuity errors on SAT>IP set-ups can be the result of missed RDP UDP packets (I think RDP packets have an incrementing unique stamp number so a missed packet can be discovered ?).
Discussion that some recent Linux kernel stuff has caused issues with some hardware in that regard - though no idea if the Pi is impacted. One TVHeadend user was seeing continuity errors every minute or more in that situation.
One other thing - do you have any Transport Errors alongside your Continuity Errors?
I fired up my TV Headend Debian server running on a Celeron PC. Currently just doing AutoRecs of the main UK networks (BBC One HD, BBC Two HD, ITV HD, C4 HD, C5 HD plus a cheeky Talking Pictures SD as that unearths some hidden gems!) TV Headend Server and Kathrein are on the same switch.
Here are some screen shots in case they are useful.
(Still no continuity errors after 3 hours)
(After five hours there were a couple of continuity errors on three tuners - fewer than 10 errors though)
Hi, I just tried the last matrix build for my rpi4 4 gb and everything plays fine (even 130 GB mkvs!). Most of my files are in MKV format created with makemkv stored in a NAS, but two of the tvs at home are still 1080p. Files plays fine, but the colors are obviously washed out.
Is it planned to support tone mapping so colors can be "downscaled"?
Thanks.
Yep - tone mapping Rec 2020 HDR to Rec 709 SDR is a requirement for playback of Rec 2020 HDR content nicely on Rec 709 SDR TVs.
(Rec 709 vs Rec 2020 is the colour gamut, SDR vs HDR is the dynamic range - both need to be handled)
However it's important not to assume it's a UHD 2160p vs HD 1080p thing - there are UHD TVs that need tone mapping as they are Rec 709 SDR only (early 4K TVs weren't Wide Colour Gamut or HDR), and there are 1080p HD TVs that don't need tone mapping, just downscaling (as they are Rec 2020 HDR compatible)
Have you enabled Expert / Advanced mode in the menus on TV Headend? What SAT>IP settings in TV Headend do you have?
Could you post grabs of your DVB config settings in TV Headend?
Post Processing is not the route to fix this - those errors just shouldn't be there in the first place.
I'm in the UK and have a small 50cm dish for Astra 28.2 - cost £50... I take it you are not in the target area for the satellite you want to receive?
How long are you leaving TVH to capture EPG data before viewing - epggrab can sometimes swamp underpowered platforms.
Display MoreHello Noogin I'm very happy that you try to help me. And I really would love to get things running.
I am willing to do all kind of troubleshooting.
First of all I am using a Quad LNB (KATHREIN KEL 444 Euroline Universal Quad LNB).
My Antena is rather old, cheap and small.
My Sat>IP is Kathrein 418 which, from my research, got pretty reasonable test results altogether, although not being a cheap device.
But I am using this setup (antenna + LNB) since years and never had issues ever since (using both my HTPC with 2x Hauppauge Nova S2 cards and a Comag SL40HD receiver.)
[The SAT>IP is brand new (2 weeks?).]
For THV forums I have the issue to not receive an confirmation link e-mail. I tried like 5 times the last couple of days.
Therefore I am unable to open threads there sadly.
Poor signal quality would indeed be an issue to troubleshoot, since I can't really test it (withoput buying a new antena // LNB).
I was kind of hoping for a logging possibility in THV to hopefullly get hints.
Regarding settings:
no I didn't do anything in the THV tuner settings yet. To me its 100% confusing. There are like 30 different entries//lines in THV - although i only have 8 tuners.
I would have no clue at all, what to do - even for "trial and error"
Regarding "continuity errors would be caused by dropped network packets": I would kind of cancel this out. Since not only does DVBViewer run fine, but also Simple IPTV (using a m3u) runs on both the LG TV itself (LG OS6 -SIPTV app) and also on Kodi (SIPTV Client Addon). Without any flaws.
Wouldn't those two programs face the same issues with a root cause in my network?
The "platform" I am running THV on is a RasPi 4b 8GB.
And I tried both LibreElec 9.2.7 and Raspbian lite (using the latest 32bit version from "Raspberry Pi Imager"). Both with exactly the same poor results.
I'll see if I can post on your behalf at TV Headend forums - there are posts from other Kathrein users there I think - have you done a search on those and google to see how others have configured their Kathreins?
I don't know what you mean about '30 different entries/lines'?
You do understand how to set-up TV Headend and how to set-up your SAT>IP receiver within it don't you?
As you only have one orbital position - you've done the basic stuff and disabled the other 3 positions for each tuner (configuring each of the 8 tuners for just a single position (rather than the 4 Diseqc options - A, B, C, D etc. )? (That shouldn't be an issue but will get you down from 32 tuner options to 8 )
There are also SAT>IP specific settings that can differ between different SAT>IP tuners in TV Headend - as some tuners have more functionality than others (Some can send an entire transponder, others can just send a couple of services per transponder before running out of processing)
As for network issues- no you can't assume that because other software works fine over the network with your Kathrein and TV Headend doesn't that it isn't the network. If TV Headend is requesting a lot more data (as it could be if it's not been configured not to) you could be running at much higher network loads with TV Headend vs other tuners.
How much research have you done in to how TV Headend works with SAT>IP tuners?
Sadly I am quite blank on how things all work together (especially in regards of the "cont. errors").
(What's the output of the antenna/LNB, what is Kathein doing with it, how is the network/Fritzbox involved, what is TVH doing exactly, how is the TVH output "received", what does the "player" do with it?)
Assuming you have a Wideband/Quad/Quattro LNB connected to your Kathrein (Unicable and Unicable II is a little bit different)
1. Your LNB receives a focused RF beam which the dish has focused, from the orbital position it is pointed towards.
2. Your LNB contains Horizontal and Vertical polarisation functionality that lets it receive one or both horizontal and vertical polarised signals (polarisation allows the RF band to carry more signals without the H and V signals interfering with each other)
3. Your LNB will have a Local Oscillator (for Universal LNBs this will have two different frequencies, for a Wideband just one) which is mixed with the RF signal received and creates a much lower frequency IF band that can be sent down the cable.
3. Your Kathrein will select the right LNB input (and if a Quad LNB is used tell the LNB which of the 4 universal bands to feed down that LNB feed) and Local Oscillator setting (if required)
4. Your Kathrein will then, under IP control from TV Headend, over SAT>IP, select which transponder frequency band in the IF band it receives down the cable to tune to.
5. Your Kathrein will then, under IP control from TV Headend, demodulate that transponder using DVB-S or S2 demodulation, with the correct FEC etc.
6. Your Kathrein will then, optionally, under IP control from TV Headend, select which PIDS (or audio, video, text, data etc. streams) to send to TV Headend over IP, and then will start streaming them. (In some cases it is possible to select every PID on a transponder - but for many SAT>IP tuners this causes them to fail as the network throughput and processing required is too high)
7. Your TV Headend server will receive those IP streams and process them - either recording them to a local or network storage device, or streaming them back out over the network.
(For Unicable / Unicable II LNBs the set-up is a bit different for points 2-4)
It's points 1-7 that will influence continuity errors. These can be caused by poor signal, slightly incorrect IF oscillator setting, poor network handling (or in some cases the SAT>IP tuner being pushed too hard and sending more PIDs than is required). There are a number of SAT>IP settings in TV Headend for optimising different makes of SAT>IP tuner.
Have you checked the accurate SAT>IP setting for your device in TV Headend - and checked whether there is any advice for your tuner on the TV Headend forums?
The fact that you get good results with DVB Viewer and less-good result with TV Headend suggests this is a TV Headend config issue - or a problem with the platform you are running TV Headend on (continuity errors would be caused by dropped network packets - as SAT>IP uses UDP not TCP so no packets are checked and re-requested)
Display MoreYes that's exactly why I am hoping on an evolution for THV.
This "canceling/correcting (of) errors" seems to be not a major issue, if that many (all) other Apps and Tools are capable of.
Can I maybe switch the "MPEG 2 Transport Stream processors and h.264 video decoders" for TVH manually?
DVBViewer seems to use "LAV Filter", which is an extra installation coming with DVBViewer.
How can I configure those settings (transport stream, decoder, etc.) for TVH? (To tinker around with and trying e.g.).
Unless you are transcoding prior to streaming, TV Headend isn't doing any video decoding (so won't be using an h.264 or MPEG2 video decoder), that's purely a function of your client platform that is playing the video (usually Kodi - though there are also TV Headend apps)
TV Headend doesn't do any video or audio processing on the received streams unless you are transcoding (i.e. decoding and recoding the received video and audio bitstreams). By default TV Headend will just 'pass through' the h.264/h.265/MPEG2 and MP2/AAC/AC3/EAC3 audio it receives from the DVB-T/T2/S/S2/C or IP sources it has untouched.
TVH will be simply demuxing the MPEG2 transport stream to split out the service you wish to stream/record (as transponders and multiplexes are usually a single transport stream containing multiple video+audio or audio services on that tp/mux) - so if there are errors at the transport stream level, this could cause errors in TV Headends demuxing.
However the video and audio decoding (i.e. stream playback) isn't functionality that is part of regular use in TV Headend - so TV Headend doesn't need h.264 video decoders - that's all done on the client that connects to TV Headend that actually displays the video and audioo.
If you are watching in Kodi - then it's the h.264 decoder that Kodi is using that is either able to cope with concealing errors or not. If you are using hardware decoding then this may well be a function of the hardware decoding on that platform. If you are using software decoding in Kodi, then it's likely to be the decoder code that Kodi is using (which is based on ffmpeg I think). I know there has been quite a lot of effort to improve ffmpeg's ability to cope with glitchy streams (as it's used in broadcast distribution chains these days) - so software decode may improve things if your Kodi platform has the CPU power to cope with it.
AIUI some TVs will be using the same decode paths for TV Headend streams as for their own DVB-T/T2 tuners, which will be optimised to cope with error-filled streams (as they are TVs and expect errors), whereas media players are expecting clean, error-free streams, so don't have the same level of optimisation. Other TVs will use totally different paths for decode in Kodi compared to DVB streams (they may be decoded on totally different bits of silicon)
However - the core cause of this is that you have continuity errors that you shouldn't have within TV Headend and a decent satellite signal. Fix those and all the platforms will be OK. (I can go days without a single continuity error in my Kathrein SAT>IP / Astra 28.2 set-up )
