OBS via IPTSin on the PortsDown

[G7JTT]

Hi Jonny,
1. I personally found no effect's of changing the a.sh file but I have upgraded my lime for development reasons.

2. The ffmpeg file are changed in the ffmpeg directory not OBS, I believe OBS uses its own cut down compiled/version of ffmpeg.

3. I found that in the quest to get things working I'd over complicated the commands, which introduced their own problems. So going back to the original settings that Evariste gave, with the addition of the &bitrate= on the URL just worked.

Still struggling with H265 but still playing will report back here if I ever get it working, but to be honest H264 is working great now. Around 4 seconds delay from sending to receiving via QO100, which isn't too bad for a QSO via the satellite.

All best John

[2i0jmt]

Thanks John, I'm glad it's working well for you!

I'm a little confused about which ini file you're using. Would you be able to attach it here for a corresponding fec/sr ? I think I've lost track as to which ini file your using now With the exception of the URL path to change the bitrate, does the ini file have to change at all between different FEC/SR?

Regarding a.sh, for me, things work drastically better using dvb2iq2. I have got things to work in specific circumstances using dvb2iq, but I find it's much more fussier on the UDP stream.

Something I don't think I've stated before: I'm actually going from OBS straight to Portsdown, so my setup is a little different from yours. I'm probably missing out on the pthread ffmpeg conversion as I'm not using a seperate instance of ffmpeg. I'm of course missing the metadata, but my callsign is in the video.

Thanks

Jonny

[G7JTT]

This is my basic.ini for 333Ks @ 3/4 FEC

[General]
Name=333KS@3/4FEC

[Video]
BaseCX=1280
BaseCY=720
OutputCX=768
OutputCY=432
FPSType=0
FPSInt=25
FPSCommon=25 PAL
ScaleType=lanczos

[Panels]
CookieId=81C35251CAF3DB4E

[Output]
Mode=Advanced

[AdvOut]
TrackIndex=1
RecType=FFmpeg
RecEncoder=obs_x264
RecTracks=1
FFOutputToFile=false
FFURL=udp://230.0.0.11:20000?pkt_size=1316&bitrate=495700
FFFormat=mpegts
FFFormatMimeType=video/MP2T
FFExtension=ts
FFVBitrate=294
FFIgnoreCompat=true
FFVEncoderId=28
FFVEncoder=libx264
FFAEncoderId=86018
FFAEncoder=aac
FFAudioMixes=1
FFMCustom=muxrate=495700 mpegts_original_network_id =1 mpegts_transport_stream_id=2 mpegts_service_id=1 mpegts_start_pid=300 mpegts_pmt_start_pid=4096 pcr_period=40
FFVCustom=preset=superfast x264-params=nal-hrd=cbr:force-cfr=1:vbv-bufsize=1000
FFVGOPSize=50
FFABitrate=32
FFRescale=true
FFRescaleRes=768x432
RescaleRes=620x465
RecRescaleRes=1920x1080
Rescale=false
[Stats]
geometry=AdnQywACAAAAAAIoAAABXQAABVcAAAKbAAACMAAAAXwAAAVPAAACkwAAAAAAAAAAB4A=

[Audio]
SampleRate=44100
ChannelSetup=Mono


Yes you need to change the the numbers in red for each SR/FEC combination, your output screen size (RecRescaleRes) is what ever you can get away with for the SR/FEC your using. And ok on going direct that will work but may still be an issue with pthreads I really don't know whether OBS uses its own version or the installed version on your PC ? If you still have issues try changing from w32threads to pthreads.

Hope you get going soon John

[2i0jmt]

Thanks John

I've moved onto another method similar to yours and I've been very successful this evening! I'm now using the pthreads version of ffmpeg as an intermediary and the difference is night and day. I've never seen 333 look so good Clearly, OBS's ffmpeg wasn't using a proper constant bitrate (or otherwise unstable).

I'm still working on some tweaks but I'll post back here later this week my settings. But basically, I'm actually keeping my OBS settings static, and using my seperate ffmpeg instance to do the bitrate downconversion appropriate for my SR/FEC.

Thanks

Jonny

[g0mjw]

Hi all


I thought it was well known as we discussed this a few months ago, but OBS doesn't impliment ffmpeg metadata parameters. There is a discussion on the OBS forum on this. You need to use ffmpeg externally and this is what the script evariste prepared does. I'm not sure if all the cbr switches etc work either. Best to do it all externally and use OBS to produce the images only. The LKV373 via HDMI does this rather well if fed into a jetson nano.

Mike

[2i0jmt]

Hey Mike

I wasn't too worried about the metadata missing, as the callsign can be placed inside the video with OBS.

I'm not sure about CBR inside OBS either. Using an external ffmpeg is night and day better. It could simply be that "yes", it does work, but w32 threads are unstable, causing it to not work very well. My external ffmpeg version is the pthreads version.

I just wish there was a more efficient way of sending content from obs to external ffmpeg in Windows, rather than using obs built in ffmpeg first via IP. If anyone has any suggestions on this I'm all ears.

Thanks

Jonny

[g0mjw]

Hey Mike

I wasn't too worried about the metadata missing, as the callsign can be placed inside the video with OBS.

I'm not sure about CBR inside OBS either. Using an external ffmpeg is night and day better. It could simply be that "yes", it does work, but w32 threads are unstable, causing it to not work very well. My external ffmpeg version is the pthreads version.

I just wish there was a more efficient way of sending content from obs to external ffmpeg in Windows, rather than using obs built in ffmpeg first via IP. If anyone has any suggestions on this I'm all ears.

Thanks

Jonny

Best to look at the OBS source code and figure out what it is doing. You might try virtualcam or project to a screen you then capture.

Mike

[2i0jmt]

So my current status is this (and I should probably start a separate thread on DVB compliance...)

Using a static OBS config with a bitrate of 2000 (and really almost any of the encoders, but I'm using x264), then sending to udp://230.0.0.11:20000?pkt_size=1316

and then use a separate ffmpeg instance (using the pthreads versions linked by John) with the following command to send to Portsdown:

ffmpeg -i udp://230.0.0.11:20000 -c:v libx264 -x264-params "nal-hrd=cbr:force-cfr=1:keyint=100" -preset superfast -pix_fmt yuv420p -r 25 -s 720x576 -qmin 2 -qmax 50 -g 50 -b:v 850k -minrate 850k -maxrate 850k -bufsize 85k -pcr_period 20 -muxrate 1488500 -c:a mp2 -b:a 64000 -ar 44100 -ac 1 -f mpegts -mpegts_original_network_id 1 -mpegts_transport_stream_id 1 -mpegts_service_id 1 -mpegts_pmt_start_pid 4096 -streamid 0:256 -metadata service_provider="DATV" -metadata service_name=2I0JMT -flush_packets 0 -f mpegts udp://<portsdown_ip>:10000?pkt_size=1316&bitrate=1488500

The above example is for 1000ks 3/4, and works excellent when receiving via MiniTioune. The items highlighted in red are the things I change depending on SR and FEC. I am using dvb2iq2 in a.sh, though.

My current issue, is that as it turns out according to googling around, ffmpeg is unable to create a perfectly compliant CBR TS stream that is DVB compliant for reception on cheaper STBs. I think the main issue is that the null packets in the TS aren't padded out properly. Right now, my video is quite choppy on my STB. Ironically, the video was nice and smooth when going from OBS direct to Portsdown. I feel this was a side-effect of the unstable TS bitrate that fills out the stream, causing better (i.e. smooth) decoding on my cheap STB. I may create a separate thread on this.

[2i0jmt]

Hm, well this is strange. Using the below command (which has its muxrate designed for 1000 3/4), work almost smooth on 1000 1/2 !!

ffmpeg -i udp://230.0.0.11:20000 -c:v libx264 -x264-params "nal-hrd=cbr:force-cfr=1:keyint=100" -preset superfast -pix_fmt yuv420p -r 25 -s 720x576 -qmin 2 -qmax 50 -g 50 -b:v 800k -minrate 800k -maxrate 800k -bufsize 80k -pcr_period 20 -muxrate 1488500 -c:a mp2 -b:a 64000 -ar 44100 -ac 1 -f mpegts -mpegts_original_network_id 1 -mpegts_transport_stream_id 1 -mpegts_service_id 1 -mpegts_pmt_start_pid 4096 -streamid 0:256 -metadata service_provider="DATV" -metadata service_name=2I0JMT -flush_packets 0 -f mpegts udp://<ip_of_portsdown>:10000?pkt_size=1316&bitrate=1488500

My current unproven theory, is that muxrate is doing nothing, and the bitrate of the video and the audio has to fill out the TS to a size that maxes out the SR/FEC combination. Just a theory, but it would explain why adjusting the video bitrate makes the video smoother.

[F1SSF]

Hi John (and alls)
Thank you for short contact and support on QO100.
As I told you, I set OBS by following the forum informations.
Generate profile SR250 + script SR250 + modif thread ffmpeg
when I transmit on QO100, all lights are green on Minitioun, and the datas enter in minitioun, but I do not decode the image.

Before, I would like to correct a stupidity, my video card on Laptop is not an Nvidia, but an Intel integrated. CPU is I5 with 8Go Ram.

I think my problem is my video stream is not conform, there are some informations on the script that I don't understood and a lot of null packets when I record my transmission

batch.PNG (56.63 KiB) Viewed 7652 times

ts analys.PNG (36 KiB) Viewed 7652 times

My webcam is C920, I use Porstdown + Lime .
I have calculated the MUX , and FFVBitrate, but I am not sure about Input and output video screen format for SR250 in OBS and script.

Do you have an idea?
Thank you very much.
73 Franck F1SSF

Sorry for my English, it is more easy for me to write that speaking et listening