Portsdown4

[F1SSF]

Good morning alls
After a long break I decide me to test PSD4, very great it is a revolution ....
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]

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]

Thank's Dave,
Ok RPI cannot encode H265, but is there a possibility why external H265 encoder via HDMI port ??

H265.jpg (6.54 KiB) Viewed 4820 times

All the best
73 Franck

[g0mjw]

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]

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...
73 Franck

[F1SSF]

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]

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]

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]

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]

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