PI4 and instant record.ts file problems
- maxi
- Thread is Unresolved
-
-
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...
-
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...
-
Display More
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...
-
h.264 video
That sample is mpeg2
-
Info:
QuoteGeneral
ID : 1 (0x1)
Complete name : 20191029 2149 - instant record.ts
Format : MPEG-TS
File size : 78.4 MiB
Duration : 20 s 280 ms
Overall bit rate mode : Variable
Overall bit rate : 31.1 Mb/s
Video
ID : 512 (0x200)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format profile : 4:2:[email protected]
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : Variable
Format settings, picture struc : Frame
Codec ID : 2
Duration : 19 s 720 ms
Bit rate mode : Variable
Bit rate : 28.8 Mb/s
Maximum bit rate : 30.3 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.555
Stream size : 67.6 MiB (86%)
Audio #1
ID : 4112 (0x1010)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Mode : Dual mono
Codec ID : 3
Duration : 20 s 208 ms
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : -292 ms
Stream size : 947 KiB (1%)
Language : English
Audio #2
ID : 4128 (0x1020)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Mode : Dual mono
Codec ID : 3
Duration : 20 s 280 ms
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : -372 ms
Stream size : 951 KiB (1%)
Language : English
Menu
ID : 32 (0x20)
Menu ID : 1 (0x1)
Duration : 20 s 280 ms
List : 512 (0x200) (MPEG Video) / 4112 (0x1010) (MPEG Audio, English) / 4128 (0x1020) (MPEG Audio, English)
Language : / English / English
Maximum bit rate : 200000000
-
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.
-
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
-
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
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.