PI4 and instant record.ts file problems

  • It is mpeg-2 4:2:2. It will not be hardware decoded. I'm not sure pi4 is fast enough to software decode this.

  • On the computer I can see well, would be nice if PI4 could also...

    Raspberry Pi4 2GB LibreELEC

  • Download "handbrake" and transcode it to H264/H265 on the desktop machine. Time to transcode will be shorter than time looking for a Pi based solution that doesn't exist.

  • The idea was not need to go to the computer to see those files that are captured by satellite receiver, but don't play them.

    So I will have to continue watching through the pc.


    Raspberry Pi4 2GB LibreELEC

    Edited once, last by maxi ().

  • That's a broadcaster uplink feed (31Mbs 4:2:2 h.264 video with 384k MP2 stereo audio) not aimed at consumers.

    Consumer video (DVB/ATSC/ISDB, DVD, Blu-ray and UHD Blu-ray) is 4:2:0 - and that's what consumer devices have hardware acceleration for. As a result consumer devices - set top boxes, PC GPUs (**), ARM SoCs designed for consumer media playback etc. don't support it in hardware.

    4:2:2 is only used in the broadcast/professional environment - and you need a broadcast/professional device to decode it with hardware acceleration (*).

    For h.264 4:2:2 decode on a consumer device you need something with the CPU power to support software decoding (and probably software deinterlacing if the source material is 1080i25) This puts you in the Intel/AMD camp for realtime playback - not consumer ARM SoCs.

    If you want to watch this stuff on a Pi - you will need to transcode to 4:2:0. If you want to retain chroma resolution then 4:2:2 1080i25 -> 4:2:0 1080p50 may be your best route. (ffmpeg with a -vf "w3fdif=complex:all" deinterlace is my go to for that when converting broadcast 4:2:2 sources - h.264/ProRes/DNX/AVCi100 etc. to h.264 or h.265 4:2:0 consumer video)

    Personally I usually do this from the command line rather than in handbrake as I found handbrake would often deinterlace 1080i25 to 1080p25 not 1080p50 (and thus threw away 50% of the temporal - i.e. motion - resolution)

    (*) When MPEG2 4:2:2 was used for satellite uplink, a couple of oddball consumer devices did have unadvertised 4:2:2 MPEG2 decoding (one version of the WDTV Live did it I discovered). However I've yet to find any consumer devices with unadvertised 4:2:2 h.264 decode.

    (**) Some Non linear editors like FCPX, Prem Pro etc. will support GPU accelerated decode within their workflow - but this is bespoke within those packages.

  • Yes this is sat feed, some I can watch directly on the satellite receiver, others not like this.

    I have to use the pc for this through streaming.

    I have to keep seeing the same way.


    Raspberry Pi4 2GB LibreELEC

  • Info:

    Raspberry Pi4 2GB LibreELEC

  • Sorry - yes - people are absolutely right - it is MPEG2 not h.264 4:2:2. I can't think why I jumped to that conclusion as I opened it in MediaInfo. It's probably because I assumed it was recent - and I don't know of anyone in broadcast in the UK still using MPEG2 rather than h.264 for broadcast uplinks (as it's basically a waste of bandwidth to use MPEG2 these days)

  • Ok,

    but you're right anyway, most receivers do not support 4:2:2 transmissions, be they in mpeg2 or 4.

    Raspberry Pi4 2GB LibreELEC