PI4 and instant record.ts file problems

  • 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.

    Thanks...

    Edited once, last by maxi (October 31, 2019 at 8:20 AM).

  • Hi,

    I tried to see a recording file where I can only get sound…

    PI4 2GB RAM

    sample record.ts file

    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.

    Thanks...

  • Info:


  • 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)

  • After all this time and the evolution of Rpi4, what was impossible to see is now seen, the only thing missing is the fluidity of the image, I have already tried all possible settings, but the best solution is with DMR PRIME off and Deinterlace method off.

    All this being read in real time, internal stream from a DVB-S2 box to Rpi4 through the Enigma2 Client addon.

    On the other hand, to see channels in the standard norm, I have DMR PRIME and einterlace method on.

  • Hello,

    Is it possible to improve the performance in order to be able to reproduce the type of video that I will put the link, I already talked about it in the post above.

    Thanks

    Video file

    If you are talking about decoding and deinterlacing high bitrate 4:2:2 1080i25 MPEG2 (or h.264) on a Pi 4B - then no - I don't think it is currently possible.

    The only ARM platform I know that can currently handle software decode and deinterlace of 4:2:2 1080i stuff is the Apple TV 4K. I've not seen any other ARM SoC handle it. (As an added benefit the ATV 4K has hardware accelerated decode of 4:2:2 and 4:4:4 HEVC/h.265 - as a side-effect of that codec being used for Mac Airplay desktop mirroring, though 4:2:2 MPEG2 and AVC/h.264 is done in software.)

    It may be possible for the MPEG2 decode and deinterlace to be further optimised for the Pi to allow for it using techniques like GPU-assisted decode (rather than VPU hardware acceleration) - but for such a niche codec I'm not sure that the developers will have the inclination to do so.

  • If you are talking about decoding and deinterlacing high bitrate 4:2:2 1080i25 MPEG2 (or h.264) on a Pi 4B - then no - I don't think it is currently possible.

    The only ARM platform I know that can currently handle software decode and deinterlace of 4:2:2 1080i stuff is the Apple TV 4K. I've not seen any other ARM SoC handle it. (As an added benefit the ATV 4K has hardware accelerated decode of 4:2:2 and 4:4:4 HEVC/h.265 - as a side-effect of that codec being used for Mac Airplay desktop mirroring, though 4:2:2 MPEG2 and AVC/h.264 is done in software.)

    It may be possible for the MPEG2 decode and deinterlace to be further optimised for the Pi to allow for it using techniques like GPU-assisted decode (rather than VPU hardware acceleration) - but for such a niche codec I'm not sure that the developers will have the inclination to do so.

    Hello,

    I noticed that you already have the new RPi5, is it possible for your friend to test the file to see how it behaves. At the moment the RPi4 can play this type of file, but it lacks fluidity, I think is a lack of processing power and there is no shortage of that in the new RPi5.

    Thanks.