BATC - Forum

A place for ATV enthusiasts to get together and discuss all things Television. NOTE - all postings remain the copyright of the author, please get their permission before copying and publishing elsewhere.

I am using OBS, not VMIX but the difference is I am not using the Portsdown. I am using a Nvidia Jetson Nano. The Portsdown will work and many are using them but the PI does not have the processing grunt of the Nano.

If you generate your transport stream locally on your PC, the Portsdown will transmit it. I do that to, with a PI and with a LimeNetMicro. PCs usually have much more powerful CPUs than in the PI and can encode the video more efficiently. This encoding is especially important at low symbol rates.

I get it about processing power etc which is why my main PC is an X99 6 / 12 cores running at 4.2GHz with 32G ram - so no shortage of CPU cycles etc.

However as per the instructions I'm running ffmpeg locally on the PC and looking at the batch file I was under the impression that ffmpeg was doing all the heavy lifting and thus all the rpi has to do is handle the transport stream.

If I'm understanding you correctly, this is not the case and there's some sort of bottle neck in the rpi when handling external trafffic via the IPTS encoder function - at a guess converting the TS to IQ signals and so onto the USB to drive the Lime might be issue ?

That's right. All the heavy lifting on the PC, Transport Stream sent to the PI to deal with the encoding and modulation. That's how I did it.

There is another way, which is to send the video and audio via UDP, or some other means, and have it encoded on the PI. With the Nano, I generate a UDP Transport stream on my PC (or with an LK373a) at high rate e.g. 8Ms/s in H264 and send it to the Nano which transcodes to whatever format I am sending. The Nano can do that, the PI less so.

If you are having problems with the batch file, what are they? You probably have a higher video bit rate or audio bit rate than fits into the TS. Alternatively something not right with the CODEC. This is compounded by constant bit rate encoders not really being constant. The H265 encoder is worse for this than the H264 one.That's covered by the twiddle factor in Charles' Express software and by a similar scaling in the script. E.g.:

doesn't seem to work within the batch file due to variables TSBITRATE and auiobitrate not having been defined, also the VIDRATE values for various FEC's have been calculated to take into account the TS bandwidth and included in the batch file.

The puzzle for me is why the RPI chokes - considering it works for others and I'm running on a rpi 3 B+ with a class 10 MMC.

Obviously I'm missing something here - just not sure what ......

EDIT just saw Dave's response - looks like I'm the 'corner case again' and expecting too much ! Strange that others have used IPTS and the Lime mini with no issues though. Several locals with identical set ups have no problems at all, but as usual I'm not blessed

Tim - you are assuming that line is from the wiki batch file - it is not, it is from the one I pasted earlier in this thread and the variables are set in the script. Somewhere you will have a scaling factor for the bitrate - e.g. 80 / 100 as it was above. Reduce that.

The Wiki is from 2017 and out of date. I did not write it but perhaps the files need to be removed to avoid confusion.

Thanks for the info dave, I have had Vmix working to a fashion work for a while then drops out. But not so successful with OBS just get loads of ffmpeg errors. I will have another go tomorrow based on the most reliable settings from your chart.

Cheers John G7JTT

P.s now looking at another way of using OBS, hdmi to composite video adapter and use the HDMI output on the laptop and feed it into the easycap on the Pi at least that should work

Partial success! – using the new batch file Vmix_PI.bat from Evariste available here: Vmix_PI.zip (many thanks Evariste and G0MJW for pointing it out) I can now transmit stable video and audio for up to about 4mins before losing lock.

I set up vMix in the normal way and clicked the External button to start the TS.

Choosing a Symbol rate of 333Ks and FEC 1/2 the transmitted picture and audio through the Portsdown 2019 was stable on the MiniTioune for around 4min’s or so before losing lock, and on the MiniTioune the four TS LED’s turned red, as did the error box.

Symbol rates of 250 and 333Ks and various FEC’s all worked similarly. Choosing more or less video definition made no difference. Choosing 1000Ks SR did not achieve a lock at all.

It seems that vMix will output from the PC to the Portsdown OK but the question remains – why is the transmitted video/audio only lasting for around 4min’s before losing lock on the receiver?