BATC Forum

Hi all.

I am in the early stages of work to upgrade GB3GV to DVBS2 and my current plan is to use the "Advanced receiver" board (as the repeater will have 4 digital inputs on different bands) together with an analogue input and the existing analogue receiver on 1249.

As I am a (reasonably proficient) C++ programmer, My "current" plan is to write a repeater controller based heavily on the Winterhill software which will transcode any detected input video for sending to an Adalm Pluto running F3OEO/F5UII's excellent PlutoDVB firmware.

I also have a Picapture SD1 from Lintest systems which I plan to use for the analogue input video. It is a pretty expensive option compared to Easycap but initial tests result in a much higher quality capture as it uses the CSI2 interface.

I am also planning to use a RPi Compute Module 4 together with the Waveshare CM4-IO-BASE rather than a standard Pi4 as it has a few useful features not available on the standard Pi4. Mainly internal eMMC rather than Micro SD for storage, a PWM controlled FAN output and (on the B model) battery backed RTC. I also like the use of a full-size HDMI connector and the addition of an M.2 interface if I need more than the 32GB provided by the eMMC.

I don't know whether a single Pi4 will have enough power to handle everything (especially transcoding) so if not, I may need to offload this to a separate Pi4?

I would be interested to hear any thoughts on this. My preference is definitely to keep everything as much as possible in software (as that is my strength).

73
Phil M0VSE

Hi Phil

Sounds like a great project. Happy to offer as much advice as I have time for, but it would be great if you could share your code and hardware design for use in other repeaters.

My recollection of testing with the Advanced DATV Receiver board is that much of the processor load was taken by VLC in trying to decode and display 4 images. Brian G4EWJ may have more information on this. If you are not displaying, but only transcoding, I think that will be the major processor load.

I think that you are unlikely to need more than 32 GB of storage (unless you are recording or using play-out videos). The current WinterHill fits comfortably on a 16 GB card.

Please keep us informed, and don't hesitate to ask for advice!

Dave, G8GKQ

Thanks Dave.

Yes that was my thought, as without the need for XWindows and multiple instances of Vnc, I suspect the load will be significantly lower.

I will absolutely share any software and will start a Github repo once I have something.

73 Phil M0VSE

Hi Phil,

As a guide, WinterHill takes about 8% of total RPi4 cpu resources when receiving the QO-100 beacon on all 4 channels and not displaying locally.
Receiving a QO-100 beacon and an SR4000 FEC 7/8 signal on each NIM takes about 25% of total cpu resources, when not displaying locally.

A few questions:

Are you transcoding everything, or sending received packets to the Pluto with some modification for padding and timing?
Do multiple received signals need to be transcoded simultaneously for a mosaic output?
Will you be receiving DVB-S / MPEG-2 at rates such as SR4000?

When displaying locally:

A single beacon takes about 40% of total resources. VLC has to use the software codec because the hardware codec doesn't like the beacon.
A single SR4000 FEC 7/8 MPEG-2 signal takes about 35% of total resources. I don't think that the hardware codec is available for MPEG-2.

I don't know much about transcoding. Does it take the input signal back to bare video and then re-encode it? If so, the decoding part of the transcoding cpu usage may be similar to the local display usage.

WH has to run in desktop mode at the moment, as it puts up the 2 info windows locally even when not displaying video locally, but that could easily be changed. I don't know how much cpu usgae it would save.

Brian

Thanks Brian, that's very interesting.

I was planning to transcode everything as that would allow me to send a consistent transport stream to the output regardless of what is being received. This will obviously depend on what resources are required. Currently the (DTX1) repeater output is first come first served with the other inputs being locked-out as soon as a valid signal is detected on a particular input. I plan to implement something similar so only one signal will ever be transcoded at a time.

Looking at libav (which is the basis of ffmpeg), it appears to effectively decode the stream into individual frames (into an AVFframe struct) which can then be processed before being re-encoded for transmission. This will hopefully allow it to support DVB-S/SVB-S2 H.262/264/265 inputs at various rates? As you say though H.262 (MPEG-2) will need to use a software decoder.

It is still (very) early days as I haven't even built the receiver yet

73 Phil M0VSE

Hi all.

One thing that I was thinking of doing is adding an input for 71MHz as well (as there is a spare on the Winterhill) but if I put any frequency lower than 144000 into winterhill.ini it appears to be rejected and the receiver doesn't appear, is this to be expected as I thought that it supported 70MHz+

73 Phil M0VSE

A Knucker goes down to 50MHz, but a Minitiouner stops at 144MHz..
Gareth

Indeed - which is why we have a receiver upconverter for 6m and 4m. RTFM I guess.

https://wiki.batc.org.uk/MiniTioune

Mike

I am not sure there is a lot of value in trans-coding unless trying to reduce the bit rate. Would it not be less resource hungry to use FFMPEG to extract the audio and video from the multiplex and then re-multiplex it, adding nulls as necessary? I realise that would prevent overlays etc. but are those really needed given they can be placed in the metadata?

Mike

I have since realised why the up-converter exists

Mike, from my initial testing, I suspect that you may be correct that it would be too resource hungry to transcode, especially as my attempts to encode a stream using the hardware codec have so far been unsuccessful. This resulted in around 200% CPU usage for a single H.264->H.264 transcode @ 1920x1080.

One option that I am considering at the moment is to use a Chinese H.264/265 encoder to create the actual stream, I could then use VLC (or whatever) to display the incoming signal fullscreen on the Pi. This would also allow a slideshow or other video to be played quite easily when the repeater is not being accessed and would also allow some sort of overlay to be added.

73 Phil