Hi! Reducing the probesize removed basically all the delay, did not now that the probesize had that impact. Big thank you for the tip!
With the default probesize you could see a freeze frame of the first decoded frame for a couple of secs, if I lower teh size it will start decoding instantly. I compared to OBS SRT input and I'm now able to go lower then the default input. Setting the probesize to low causes the SRT input to trigger error/warning unable to store incoming packets so got to try to find the best option for the probesizde for my needs without triggering any errors. Latency is well within in my needs now. The output is bursting a warning from the SRT library in my compile, so its a bit hard to get anything from the output, maybe a bit uniniteresting now that I was presented with a working solution. To sum things up, reducing the probesize removes the long delay I was experiencing from the input stream on the decklink output. Thanks again! Regards Martin Den lör 9 maj 2020 kl 21:33 skrev Carl Zwanzig <[email protected]>: > On 5/9/2020 12:21 PM, Marton Balint wrote: > > 1) The most significant is probably input probing. > > I suspect the decklink part is a red herring, playback from a file to the > decklink shoudl have almost no latency, certainly not 3+ seconds (doing a > gdi screen capture to decklink is under 1 second latency). > > How long does it take for the stream to start playing with any other tool? > Is the delay comparable? > > It would be helpful if you posted the complete command output. (Linux or > windows?) > > z! > _______________________________________________ > ffmpeg-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
