stuttering

[dusandobias]

I am using omxplayer-sync with 3x raspberries model 4 (with 4 GB RAM). I am playing mp4 video in full HD resolution (cca 25 minutes long, approximately 2 GB large). Sometimes, one of the slaves stutter a little.

I am preparing this for an art exhibition so it is important that it will be really smooth. So far, I have it connected through wifi. What are your suggestions who to eliminate any stuttering? I am planning to try to connect it through ethernet, I hope it will help. But maybe there is someone more experienced with better solution.

Thanks a lot for advices!

[turingmachine]

Does it stutter as well if you play the video directly with omxplayer? Try to you encode your video with a lower bandwidth and/or use a faster SD card.

[magdesign]

reduce bitrate to 10 mbit/s use a good h264 codec (Handbrake)

[dusandobias]

I will try with a lower bitrate. Now, I got 20 mbit/s.

It does not stutter if it's played solo.

My SD cards are 32 GB Sandisk SDHC 1 class 10. That should be fast enough, right?

[magdesign]

class 10 is good. keep in mind that for sync over wifi you need to adjust the script, make a larger tolerance. I never liked wifi sync, its not stable enough.

[dusandobias]

I will also try sync over ethernet.

But just for curiosity - what (where) should I adjust in the script for wifi sync?

[magdesign]

SYNC_TOLERANCE = .2

https://github.com/magdesign/PocketVJ-CP-v3/blob/master/sync/omxplayer-sync-wifi

[dusandobias]

Great. I am now testing it with 10mbit bitrate and through ethernet and the results are much better. Thanks for the recommendations!

[dusandobias]

So I got approximately 1 stuttering in an hour. It's not bad but I am thinking how to make it perfectly smooth. Median deviation goes slowly from 0.00 to 0.05 and then it pauses to resync. Would it help to have for example better ethernet cables (CAT6)? Would it help to give Raspberry more memory for graphics? Is there something else I can do to make it 100% smooth?

[exidyboy]

On 16/06/2020, at 6:26 AM, dusandobias wrote:

So I got approximately 1 stuttering in an hour. It's not bad but I am thinking how to make it perfectly smooth. Median deviation goes slowly from 0.00 to 0.05 and then it pauses to resync. Would it help to have for example better ethernet cables (CAT6)? Would it help to give Raspberry more memory for graphics? Is there something else I can do to make it 100% smooth?

Hi there,

How are you connecting the three Pi's together - a hub or a switch? Could you try a different model? The dumber the better. A switch that has an OS (or worse a router) might be doing something every now and then that increases the latency - although I don't know why it would only effect one slave/port. It is still only happening on one slave and not the other slave? Assuming the content is different on the two slaves what happens if you swap the content but keep everything else the same (ie don't just swap the physical card). The datarate should not have a bearing on what is happening - you should be able to comfortably do 20Mbit/sec and higher and still use less than 10 percent CPU on a Pi2 For sync applications I would encode CBR but I have no evidence that it is necessary - it is just being extremely cautious to do everything possible to keep things simple and ensure the Pi is just cruising along.

I've done four art shows now using 2 or 3 Pi's and have not seen stuttering after the first loop or two. I use old Pi2's and very old Raspian Jessie Lite and old versions of omxplayer that I know and trust. I use 'official' Raspberry Pi 8GB SD cards

I hope some of the above is helpful. It is tiring and time consuming to test and debug long video art pieces ;-)

P.S. Obviously each piece of should be exactly the same length to the frame

[dusandobias]

On 16/06/2020, at 6:26 AM, dusandobias wrote: So I got approximately 1 stuttering in an hour. It's not bad but I am thinking how to make it perfectly smooth. Median deviation goes slowly from 0.00 to 0.05 and then it pauses to resync. Would it help to have for example better ethernet cables (CAT6)? Would it help to give Raspberry more memory for graphics? Is there something else I can do to make it 100% smooth? Hi there, How are you connecting the three Pi's together - a hub or a switch? Could you try a different model? The dumber the better. A switch that has an OS (or worse a router) might be doing something every now and then that increases the latency - although I don't know why it would only effect one slave/port. It is still only happening on one slave and not the other slave? Assuming the content is different on the two slaves what happens if you swap the content but keep everything else the same (ie don't just swap the physical card). The datarate should not have a bearing on what is happening - you should be able to comfortably do 20Mbit/sec and higher and still use less than 10 percent CPU on a Pi2 For sync applications I would encode CBR but I have no evidence that it is necessary - it is just being extremely cautious to do everything possible to keep things simple and ensure the Pi is just cruising along. I've done four art shows now using 2 or 3 Pi's and have not seen stuttering after the first loop or two. I use old Pi2's and very old Raspian Jessie Lite and old versions of omxplayer that I know and trust. I use 'official' Raspberry Pi 8GB SD cards I hope some of the above is helpful. It is tiring and time consuming to test and debug long video art pieces ;-) P.S. Obviously each piece of should be exactly the same length to the frame

Thanks for such an extensive answer.

I am using TP-Link N300 router TL-WR841N. Maybe that might be a source of a problem. So hub or switch might be better to use? I think I will try that.

The stuttering happens sometimes on first slave, sometimes on the other one. It varies. And never at the same time on both.

It is very positive to hear from you that you are using old raspberries. I thought having the newest model 4 would make it 100% troublefree but it's great that also older versions are able to manage this (because in our organization, we have also older raspberries we use for exhibitions). Right now, I am on 10 mbit bitrate. I think I will try higher bitrate to see if something changed.

But I guess next thing I will try is to replace router for something else as you suggest. Because first I thought that raspberries need some help with networking but according to you, they will manage with just a switch which is great.

I will inform you about the progress :)

[magdesign]

Maybe also try to with one master and one slave directly connected via RJ45 and check if it still stutters. I also figured out that when you connect an usb soundcard you get some latency. Make sure all videos are in CBR and have the same audio compression. Audio really matters on the RPi's.

[dusandobias]

That's a good one as well. I will try that! Thanks, magdesign!

[dusandobias]

Maybe also try to with one master and one slave directly connected via RJ45 and check if it still stutters. I also figured out that when you connect an usb soundcard you get some latency. Make sure all videos are in CBR and have the same audio compression. Audio really matters on the RPi's.

I found out my videos are in VBR, so I asked the artist to render it again in CBR. Another question - can it matter that one video is with audio and two other have no audio?

[dusandobias]

I don't know what I am doing wrong. I have CBR video now but both slaves now stutter almost at every start of a new loop. And that's happening with the same video file on all three Pi's.

I've got 20 minutes long video file .mp4 with 10 mbit bitrate, Pi's connected throught ethernet router with static IP addresses (DHCP disabled).

I am trying to make it better but I have impression it just stutter more and more. I am now going to try some completely different video. And today I will borrow a switch which I will try instead of the router.

But if you have any hints for me - why it stutters at every loop start... would greatly help. Thanks for your patience.

[magdesign]

try it with this video: https://cloud.magdesign.ch/index.php/s/dmTQLAkw48t3syo

try it with directly connecting 2 rpi's. as mentioned above, audio does matter, even the bitrate of the audio does matter!

[exidyboy]

If you would like to put your clips up somewhere I could test.

On 30/06/2020, at 4:22 PM, dusandobias wrote:

I don't know what I am doing wrong. I have CBR video now but both slaves now stutter almost at every start of a new loop. And that's happening with the same video file on all three Pi's.

I've got 20 minutes long video file .mp4 with 10 mbit bitrate, Pi's connected throught ethernet router with static IP addresses (DHCP disabled).

I am trying to make it better but I have impression it just stutter more and more. I am now going to try some completely different video. And today I will borrow a switch which I will try instead of the router.

But if you have any hints for me - why it stutters at every loop start... would greatly help. Thanks for your patience.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[dusandobias]

try it with this video: https://cloud.magdesign.ch/index.php/s/dmTQLAkw48t3syo

try it with directly connecting 2 rpi's. as mentioned above, audio does matter, even the bitrate of the audio does matter!

There has to be something wrong with my stuff.

Even that testing video wifisync.mp4 stutters, approximately 15 times in 2-3 hours. Mainly in the beginning of a new loop. I am going to try to connect master and slave directly - but in that case how can I save logs in some external file?

Because now, I am controlling my Pi's through SSH from my macbook's terminal, so I can see real-time (verbose) log. Can omxplayer save verbose logs into some file which I can check later? I didn't figure out how to do that. Thanks.

I am not sure if my log can be useful to check and see the weird behaviour - I am attaching it here: stuttering_pies.xlsx

[magdesign]

Did you try without verbose mode, just run it directly on the pi's...

[dusandobias]

Did you try without verbose mode, just run it directly on the pi's...

No. But I gave it a try and it looks like it's not stuttering anymore. Is that possible? Bizzare.

[turingmachine]

If a program writes more data to a file descriptor than the program on the other end or the buffer in between is able to consume, the program is halted until the other end can process data again. In your case the program is briefly halted every few moments becaue omxplayer-sync logs more data than kernel, shell and terminal can handle. The behavior can be somehow tweaked by using different buffering strategies: https://eklitzke.org/stdout-buffering

[dusandobias]

Thank you all very much. I stopped using verbose mode and it now stutters only sometimes in the beginning of a new loop which we "eliminated" by adding 10 seconds of black screen in the beginning of the video. So nobody sees any stutter.

Thanks!