Closed Boaztheostrich closed 6 months ago
fduncanh
commented
6 months ago I don't see this lag with -fs -s 480x800 -f H (on a R Pi 5 4G, with a better screen) the -s 480x800 makes text less sharp, as expected
Note -f H is mirror view (so any text is mirror image, R to L)!
fduncanh
commented
6 months ago lag should not occur unless you are also using option "-vsync no", which switches off the timestamp mode, and the system is underpowered.
Just checking: there are no options like that in your .uxplayrc (if you use one)?
Boaztheostrich
commented
6 months ago Ah, I am using a pi 4 8g, that could be the issue. Looking at htop the cpu didn't seem slammed but that could be it. I'm not familiar with a .uxplayrc I have just been using the command line arguments thus far.
On Mon, Mar 11, 2024 at 10:07 AM fduncanh @.***> wrote:
lag should not occur unless you are also using option "-vsync no", which switches off the timestamp mode, and the system is underpowered.
Just checking: there are no options like that in your .uxplayrc (if you use one)?
— Reply to this email directly, view it on GitHub https://github.com/FDH2/UxPlay/issues/276#issuecomment-1988663873, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATKHZWBC4OIQACEEXD2J5I3YXXJDVAVCNFSM6AAAAABEPOFSZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBYGY3DGOBXGM . You are receiving this because you authored the thread.Message ID: @.***>
fduncanh
commented
6 months ago Your original post said Pi 5, so I tested on that. I now tested on a pi 4B 8G. I can see your problem.
It seems to come from the -s 480x800 setting, probably messing up the hardware GPU video decoding (used by R Pi 4B but not R Pi 5) which is designed for h264 1080p which is 1920x1080.
If you need to lower the resolution to -s 480x800 because of your 5" monitor, then also use -avdec (on RPi4B) to use CPU rather than GPU decoding. This fixes the problem, although GPU decoding is preferred (some frames may be dropped from time to time if CPU decoding isn't fast enough)
Otherwise, don't use -s 480x800, which also fixes the problem. (Did you try without this setting? maybe gstreamer will adjust the video to your monitor after it is decoded by the GPU)
Boaztheostrich
commented
6 months ago Ah, my apologies I switched hardware due to power requirements and must have forgot to update the issue. Sorry about that!
Thanks for the explanation, -avdec looks like a great solution if I end up needing to use it!
Thanks again!
On Mon, Mar 11, 2024 at 1:49 PM fduncanh @.***> wrote:
Your original post said Pi 5, so I tested on that. I now tested on a pi 4B 8G. I can see your problem.
It seems to come from the -s 480x800 setting, probably messing up the hardware GPU video decoding (used by R Pi 4B but not R Pi 5) which is designed for h264 1080p which is 1920x1080.
If you need to lower the resolution to -s 480x800 because of your monitor, then also use -avdec (on RPi4B) to use CPU rather than GPU decoding. This fixes the problem.
Otherwise, don't use -s 480x800, which also fixes the problem.
— Reply to this email directly, view it on GitHub https://github.com/FDH2/UxPlay/issues/276#issuecomment-1989199863, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATKHZWFXBCAFQGFUSF5MDTLYXYDGNAVCNFSM6AAAAABEPOFSZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBZGE4TSOBWGM . You are receiving this because you authored the thread.Message ID: @.***>
fduncanh
commented
6 months ago -avdec is used by default on R Pi 5 which is powerful enough to use CPU decoding for h264 video. (It has a GPU for h265)
Using the instruction in #275 I was able to get the horizontal flip working again.
However I noticed that there was significant lag present when flipped that was not present when not flipped.
I recorded up to 30 seconds over time. It starts around 4 seconds of lag and then progresses upwards, I'm not sure what the upper limit is on it.
Causes the issue to occur, while
Does not
I don't believe that this will cause any issues for my use of the library but I thought that it might be worth mentioning.
I am using a 480x800 screen and thought that might be the best resolution for it.