Posts by noggin

  • Intel true 10bits/HEVC/HDR support... ?

    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.

  • Some 4K content not playing Full Frame [Raspberry Pi 4] LibreElec 10

    Quote from lobbie1978

    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?

  • Some 4K content not playing Full Frame [Raspberry Pi 4] LibreElec 10

    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)

  • RPi4 testbuild with HDR support

    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)

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    Quote from elonesna

    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)

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    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?

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    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.

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    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)

  • RPi4 testbuild with HDR support

    Quote from Feahnorl

    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)

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    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.

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    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?

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    LOLinger78

    Quote

    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)

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    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 )

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    I've had no major problems with Gemini Lake Celerons for TV Headend server duties. I never run the Media Playback on the same platform as the server though (I try to keep media playing and TV Headend separate). My last TV Headend SAT>IP server was based around a <£200 Chuwi Herobox and a USB 3.0 external hard drive.

    No need for anything like an i3/5/7 for TV Headend duties unless you are also going to do transcoding or run other stuff on it (not recommended).

    As for why you see artefacts on some platforms or others - it's likely to be that some MPEG 2 Transport Stream processors and h.264 video decoders (assuming you're watching h.264 content) are better at concealing/correcting errors than others. You see very different artefacts when watching the same errors on different playback devices.

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    Quote from tavoc

    For me it helped to deactivate Timeshift in tvheadend. This results on a slow system/server the performance and cause artifacts.

    I am running tvheadend and kodi in 3 households with sat to ip with digibits.

    On a digibit it helped to install a custom firmware with TCP stream instead UDP. Don't know if there is one for your kathrein

    Yes - with timeshift enabled you are constantly recording (and replaying?) as well as streaming. If you are using a Pi 3B+ or earlier and timeshifting on external storage then the disk access and SAT>IP streaming will all be going over the same, single, USB 2.0 connection.

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    Quote from LOLinger78

    noggin

    No, I am NOT using it standalone. Instead I also use it as the source/media center for my TV.

    And yes, I did only try LibreElec so far. I thought this was especially geared towards the "bare minimum" as you say.

    Yes - it's bare minimum for media playback duties. Once you start throwing PVR backends at it - it's not really bare minimum. It's also not optimised for that.

    I'd see how you go running just Raspberry Pi OS Lite and TV Headend on a Pi 4B and see if you still get thousands of continuity errors. It's only a MicroSDc card flash away.

    I wouldn't be running on a Pi 3B+ or earlier because of the USB LAN implementation that CvH mentioned. (The Pi 4B doesn't use its USB bus for LAN connectivity)