I’ve set up streaming for a local Raspberry Pi security camera running Motion. The stream display starts OK but after approx five seconds a ‘Buffering’ banner appears. The display carries on normally for around 80 seconds and then freezes. After about four minutes, the video starts again in fast motion until it catches up with the current stream output. This cycle then repeats ad infinitum.
The video stream is MJPEG 1640 x 1232 @ 1fps I’m assuming the problem is due to the low video frame rate but unfortunately I can’t increase the frame rate because that’s all the RPi can throw out.
I know Kodi isn’t an ideal platform for this sort of thing but it would be very convenient to have the ability to display this video via the Vero.
Is there anything I can do settings-wise on the Vero 4K+ to reduce if not eliminate the buffering or am I wasting my time? I looked at changing the video buffer settings (like switching the buffer off or reducing the chunk size) but couldn’t find where they are in the OSMC skin (the Kodi docs suggest they should be in Settings/Services/Caching). Using advancedsettings.xml appears to have been deprecated.
I’m running OSMC May 2024.05-1
Any thoughts/suggestions gratefully received!
Can you post a log?
Sam
Sure thing - they’re here.
The logs cover starting the stream, getting the buffering message (after about 5s), playback freezing (after about 80s) and finally fast playing for around 4 mins.
I looked at using Mediainfo but couldn’t figure out how to use it on a networked stream.
Cheers Mike
Thanks for your patience.
We are using ffmpeg (software decoding for this stream). While AMLogic SoCs claim to support MJPEG, I don’t think we’ve ever seen a proper implementation. As it’s a relatively cheap codec in terms of compute, we push it to software.
We get a lot of:
2024-06-14 09:12:06.556 T:3008 debug <general>: CVideoPlayerVideo - Stillframe detected, switching to forced 25.000000 fps
2024-06-14 09:12:07.001 T:3008 debug <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback
So it looks like a latency issue on Pi indeed.
To rule out any other issue, can you see if a recording is affected?
Thanks Sam. I made a recording using ffmpeg viz:
ffmpeg -framerate 1 -f mjpeg -i http://192.168.1.105:8081/videostream.cgi?resolution=1640x1232 -an -vcodec flv filefr1.flv
Interestingly, the playback is fine - no buffering or hesitations. Does that tell you anything?
Suggests it’s not a playback issue on the Vero but a throughput issue on the Pi.
Thanks Sam - if it’s a Pi throughput issue, wouldn’t the stream recording I made have suffered dropped frames during the recording process? I was thinking that maybe the encapsulation makes a difference to throughput on playback.
I don’t think it would if it’s collated at the end.
If a recording was affected, this would be easier to investigate.
Is there any way we can reproduce or get access to a problematic stream?
As we’re doing ffmpeg (software) decoding it should be reproducible on other platforms. Can you reproduce it using VLC?
Thanks Sam
The stream is displayed fine using VLC:
and also when using Chrome.
I’d be OK opening a port but obviously I’d want to keep it private and of limited duration. Happy to discuss details if that’s feasible for you.
You could try with a Kodi v21 test build first to see if there are some improvements there
Sam
I’ve done that but unfortunately the behaviour is the same. The logs are here
This may be irrelevant: on selecting the stream, the information displayed in the bottom LH of the screen states the stream is 00:04 long which is about the time it takes for the ‘buffering’ flag to appear.
Sam,
I’ve got a representative stream ready to go on an isolated network segment if it’ll help. Just let me know if you’d like me to get it going. I’ll need to msg you to supply address details.