Add rtp support for PCIe card(s)

[arrmo]

@DanAustinGH, the one I mentioned 😄

Adds rtp support for PCIe - like we had discussed in the (long) thread, needs to use the "pcie" IP address, not Ceton => rtp from 192.168.200.2 ... but made it a configurable variable, in case.

Yell if any concerns. Thanks!

[arrmo]

OK, 3 runs each, rtp and direct, averaged,

rtp: 2.7 sec
direct: 2.2 sec

Not a huge difference, but a bit quicker direct, as you though. BTW, I do see some interesting things in the two cases, that may lead to more optimization yet?

1. rtp

   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
   [mpegts @ 0x565292b5d140] Could not find codec parameters for stream 1 (Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp): unspecified sample rate
   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
   [mpegts @ 0x565292b5d140] Could not find codec parameters for stream 2 (Unknown: none ([5][0][0][0] / 0x0005)): unknown codec
   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
   [mpegts @ 0x565292b5d140] Could not find codec parameters for stream 3 (Unknown: none ([5][0][0][0] / 0x0005)): unknown codec
   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

2. direct, client side

   [mpegts @ 0x560886e82ec0] Stream #0: not enough frames to estimate rate; consider increasing probesize
   [mpegts @ 0x560886e82ec0] Could not find codec parameters for stream 0 (Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv)): unspecified size
   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
   [mpegts @ 0x560886e82ec0] Could not find codec parameters for stream 1 (Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp): unspecified sample rate
   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
   [mpegts @ 0x560886e82ec0] Could not find codec parameters for stream 2 (Unknown: none ([5][0][0][0] / 0x0005)): unknown codec
   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
   [mpegts @ 0x560886e82ec0] Could not find codec parameters for stream 3 (Unknown: none ([5][0][0][0] / 0x0005)): unknown codec
   Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

Very similar in both cases Thinking I closed my AP here 😜. Thanks!

[DanAustinGH]

I like it. Simple and re-producible without worrying about the media server adding its own delay. I'm not sure how much optimization with yield. I think increasing probesize might actually slow things down since it is just a stream copy.

And nice to see the actual numbers. I am considering trying to pick up a PCIe 6 tuner to replace the current 6 tuner and HDHR 3 tuner I keep as a spare. The .5 second is not a big difference, but I'd eliminate a good bit of traffic off the home network... Many thanks for the contributions!

[arrmo]

I am considering trying to pick up a PCIe 6 tuner to replace the current 6 tuner

Agreed! I do like the internal card => network traffic is just the PCIe bus 😄

HDHR 3 tuner I keep as a spare

@deathbybandaid may want to hear about this - he has been looking for SSDP output from real HW.

Many thanks for the contributions!

Happy to help if I can!

[arrmo]

Well ... a slight update 🤣. Improved timing a bit, without any real downside ... I realized that I had buffer_size set to 3. But there is no real upside to that, as for a real-time / streaming input ... you can't gain any ground on the source => and this is just buffering time up front, which really is only delay. So - changed it to 0, confirmed overnight no higher rate of dropped packets, but updating startup timing! Now ...

rtp: 1.8 sec
direct: 1.3 sec

I have been also fiddling with trying to specify the input format, to speed up startup in ffmpeg in case detection is limiting ... but even in the broken case (screwed up parameters, by me 😆), it's ~ 1.2-1.4 sec. So I'm not thinking I'll get much below the times above. Time to move on to the next item ... which, BTW - I'm going to open a new "issue". Will explain it there, and feel free to assign it to me.

[DanAustinGH]

Yeah, we talked about the lack of need for buffering for the Ceton. You may be able to shave another .25~.5 by reducing the bytes_per_read. The trade off there is the CPU load will go up. Since each buffer read represented about .7 seconds of delay there is not a huge about to save here.

Off to see if I forgot to reset the buffer values on my install...

[arrmo]

Yeah, we talked about the lack of need for buffering for the Ceton. You may be able to shave another .25~.5 by reducing the bytes_per_read. The trade off there is the CPU load will go up. Since each buffer read represented about .7 seconds of delay there is not a huge about to save here.

Agreed! Was thinking that too - perhaps a slight savings. Like you say, a tradeoff.

Off to see if I forgot to reset the buffer values on my install...

So you have 3 as well currently? Or some other value?

[DanAustinGH]

I had mine at 1. Moving to 0 did not make a difference on the 1st tune. Will monitor to see if it seems quicker, but since the likely improvement is just under a second, I may well not notice.

[arrmo]

Agreed! The delta is pretty small now ... I shaved 1 second going from 3 to 0 ... so your delta is likely ~ 0.33 sec, not really noticeable. I'm using time to measure it, but 0.33 sec won't show much when watching it 😜

[DanAustinGH]

I'm going to ponder how we might be able to have multiple Ceton devices. I have a bid in on a 6 tuner PCIe, and see a few USB-4 devices, which would be similar to the PCIe for hardware access, and I could see people interesting having a mix in use.

Something along the line of adding a config variable Ceton_device_count then loop over reading in cetonip{device#}, pcieip{device#} and tuners_{device#}. Need to update the properties as well which appears a bit trickier, but not impossible.

[arrmo]

Sounds great! And to our earlier discussion - auto-detect the number of tuners (on a device), not hard coded?

Thanks!

[DanAustinGH]

Will have to see what is possible once/if I can acquire a 2nd devcie...