Portsdown4

Discussion about this major DATV Project. See https://wiki.batc.org.uk/The_Portsdown_Transmitter
F1SSF
Posts: 87
Joined: Sat Nov 25, 2017 5:14 pm

Portsdown4

Post by F1SSF » Sat Jul 24, 2021 9:49 am

Good morning alls
After a long break I decide me to test PSD4, very great it is a revolution .... 8-)
also is it possible to adjust the bits rates ? I have 20 to 25% null packets with natifs parameters.
The Langstone integration is a very good idea.
Have you in your roadmap planned to integrate the H265 ?
Congratulation at the team for the job.
73 franck f1ssf. and keep safe ;)

G8GKQ
Site Admin
Posts: 2798
Joined: Sun Mar 22, 2009 1:21 pm

Re: Portsdown4

Post by G8GKQ » Sat Jul 24, 2021 12:42 pm

Hi Franck

Thanks for the comments.

The bitrates are set to be on the safe side so that they work in all circumstances. If you want to adjust them for a specific case, you would need to edit the file rpidatv/scripts/a.sh. Any changes would be over-written by the next update.

Although the Portsdown receiver will decode H265, it is not possible to encode H265 for transmit as neither the Raspberry Pi processor nor the graphics system are capable of encoding fast enough. You can use a Jetson Nano or a decent PC to encode externally and then transmit using the Portsdown IPTS input facility (but not with Pluto - only LimeSDR).

73

Dave

F1SSF
Posts: 87
Joined: Sat Nov 25, 2017 5:14 pm

Re: Portsdown4

Post by F1SSF » Sat Jul 24, 2021 1:33 pm

Thank's Dave,
Ok RPI cannot encode H265, but is there a possibility why external H265 encoder via HDMI port ??
H265.jpg
H265.jpg (6.54 KiB) Viewed 3247 times
All the best
73 Franck

g0mjw
Posts: 2329
Joined: Sat Sep 20, 2014 9:15 am

Re: Portsdown4

Post by g0mjw » Sat Jul 24, 2021 1:44 pm

You don't need Portsdown to send H265 with that encoder, that is already possible with Evariste's firmware for the Pluto. You don't need to do anything other than enable it via a web interface. It could not be simpler.

Mike

F1SSF
Posts: 87
Joined: Sat Nov 25, 2017 5:14 pm

Re: Portsdown4

Post by F1SSF » Sat Jul 24, 2021 9:09 pm

Hi Mike,
Yes I know,I have tested Evariste firmware, but ideally to have only one integrate system it is better, and I started dreaming, I saw H265 button in ports down... :D
73 Franck

F1SSF
Posts: 87
Joined: Sat Nov 25, 2017 5:14 pm

Re: Portsdown4

Post by F1SSF » Wed Nov 17, 2021 8:57 pm

G8GKQ wrote:
Sat Jul 24, 2021 12:42 pm

The bitrates are set to be on the safe side so that they work in all circumstances. If you want to adjust them for a specific case, you would need to edit the file rpidatv/scripts/a.sh. Any changes would be over-written by the next update.
Hi Dave, I hope you are well. Please, can you tell me witch variables must be updated to optimized the null packets, this script is complexe.

Thank you very much.
73 franck

g0mjw
Posts: 2329
Joined: Sat Sep 20, 2014 9:15 am

Re: Portsdown4

Post by g0mjw » Wed Nov 17, 2021 9:23 pm

Hi Frank

If you have to ask it might be better not to try messing with this. You are likely to end up with overflows or worse an non working script and frustration. It requires a knowledge of ffmpeg and the filter settings. Variables interact with each other, so it isn't simple to optimise.

Mike

F1SSF
Posts: 87
Joined: Sat Nov 25, 2017 5:14 pm

Re: Portsdown4

Post by F1SSF » Thu Nov 18, 2021 5:58 am

Hello Dave,
Yes ffmpeg syntaxe is not very easy, but it is only for my personal experimentation.
I can do a script copy to remplace it it, if I crash.
There are many documentations for ffmpeg on web, and I know that variables interact with others, the finality being to have a correct rate without overflows.
My difficulty is more in your structure file, I think some variables are automatically calculated .
I try to understand, ...it is an excellent exercice to learning....
All the best
73 Franck

g0mjw
Posts: 2329
Joined: Sat Sep 20, 2014 9:15 am

Re: Portsdown4

Post by g0mjw » Thu Nov 18, 2021 9:50 am

I see. Well there is a fiddle factor that relates to the video target bit rate which is reduced from the maximum theoretical video bit rate for the transport stream rate. It may be set to 0.6 or 0.7 rather than 1.0. If you set it higher you have a higher probability of overflow. But there is more than this, particularly the frame rate and the resolution. With H264 trying too high a resolution results in a very blocky picture with movement. The resolution is therefore set to a conservative value which is calculated as a function of the available bit rate. Similarly frames per second, I am not sure if Dave adjusts that or not but 15 FPS is a good compromise for 333ks. The result of all this is that on static pictures you will have many nulls but the video will be OK with moving images. If you go more aggressive you will have a better picture as long as nothing much is moving. With movement the usual result is an overflow causing loss of sound and loss of frames.

Mike

G8GKQ
Site Admin
Posts: 2798
Joined: Sun Mar 22, 2009 1:21 pm

Re: Portsdown4

Post by G8GKQ » Thu Nov 18, 2021 9:54 am

Hi Franck

In most Portsdown configurations I take the result of Evariste's dvb2iq to calculate the total TS bitrate https://github.com/BritishAmateurTelevi ... /a.sh#L344

In the lines after that in a.sh, I then set the parameters for video and audio bitrates. Note that there are separate calculations for MPEG-2 and H264. It is also worth checking for your specific input mode and output device in the code below that.

For testing, it can be easiest to set numeric values just above the ffmpeg or avc2ts call.

Please let me know if you manage to make improvements - I've played with it for hours.

Dave, G8GKQ

Post Reply

Return to “The Portsdown Digital ATV System”