Bug: Video Problems

[qwksilver]

i've tried a few videos for this formats: .mp4 .webm

and also an animated gif .gif

none of these files open, i tried a dedicated video folder vidset with just these in it, and it locks up

version from about 2-3 hours ago from this command. sudo wget https://github.com/Geektoolkit/Dynaframe3/releases/download/2.03/install.sh && bash install.sh; rm -f install.sh, i did one install from the original video command which didn't work, then an install from githubs command above which did function for photos only. so far.

also recommend that you put a version/release number on the web server for diagnotics specific info and a section for how to update to the latest in the front page documentation.

[Geektoolkit]

Version number- Great idea, definitely need that sooner than later

.mp4 - Please try with omxplayer and see if it works...wondering if there's something about the file going on. .gif/.webm - These aren't supported by omxplayer, so I'll have to think on these. Currently not supported.

[qwksilver]

so it seems that files without continuous names don't play. this is a file.mp4 won't play while this-is-a-file.mp4 will 1 i found this in the command line too omxplayer this is a file.mp4 --returns error file this not found. omplayer "this is a file.mp4" <<<with the quotes does play.

2 i've also noticed that the files don't cross fade 3 i've noticed that the files don't truncate at "slide duration" 4 i've noticed that shorter than "slide duration" play out and then sit on the last photo without looping. 5 i've noticed that videos are squashed into full frame, ignoring aspect ratio entirely

my webm problem is solved with https://www.onlineconverter.com/webm-to-mp4

i think videos with this need be curated to match the slide length, but if you can implement a loop video indefinitely, and a kill omxplayer command at "slide duration" automatic function then maybe you can solve 3 & 4.

[Geektoolkit]

Great findings! The spaces issue should be one I should be able to solve.

Right now the behavior is 'play the video file till it ends and the move on' which is how V1 worked. I think the idea of treating videos the same is valid. I'll look into modifying that. I get why you're seeing the 'last slide' thing, I need to rethink that timing as well.

The videos being squashed...right now VIdeos are using OMXPlayer and then being passed --aspect-mode stretch to fill the frame (This was to fix a bug where a 1080x1080 video wouldn't fill the frame, however seemed to play fine in things like VLC which stretch them out to the player size).

When you say squashed, is it full screen and stretched? Does omxplayer --aspect-mode stretch reproduce the way it plays? If so can you please look into a setting for --aspect-mode that plays it the proper way.

I'm heads down on the playlist engine working on multiple folder/NAS/USB drive support, which is a total rewrite of that section. Once it's done though I'll be able to hopefully better tackle some of these. These are all great, thanks for filing them!

[qwksilver]

omxplayer --orientation 270 --loop --aspect-mode fill richard-flotaverse-tatoo-lady.mp4

plays the file in the correct orientation for me, and loops it until an escape is received by omxplayer. This cause the video to match it's shortest edge to the aspect of the edge, so at 90/270 orientation we have 1080x1920. now a video that is 400x500 would be zoomed to width, centered and the top/bottom cut off.. while a 500x400 would be zoomed to height with/left right cut off. no squish, just loosing size pixels.

..stretch plays it out of aspect ratio on the screen ..letterbox plays it centered in ration, with black bars on short sides,

my test video is 1200x1200 so it's being expanded in one mode and shrunk in the other, a smaller than screen video was pulled up to fit by the fill option.

a landscape(normal) video run will be centered and loose the outsides if run in portrait

sudo pkill omxplayer
this can then kill the player, if you script in a delay or just run the command with slide change.

[Geektoolkit]

Ah, thanks for that explanation. I'll switch the default to Fill and then offer options to use the others for some flexability

[Geektoolkit]

Note to be clear there's actually two issues here: 1) Video cropping needs settings 2) Image cropping needs settings I have requests for both. Next build (2.06) will have image cropping, and video should be in the one after that.

[Geektoolkit]

Update on this (as of 2.07) 1 - Spaces in filenames have been fixed. This was a great bug, when I figured out what I did wrong there it was super satisfying to fix it 2 i've also noticed that the files don't cross fade - This is likely to be this way for a LONG time. Getting OMXPlayer to crossfade will take quite a bit of code to get it write. Likely not something I'd fix...if someone really cares about this I recommend editing the video files to fade in/out to back.

3 i've noticed that the files don't truncate at "slide duration" 4 i've noticed that shorter than "slide duration" play out and then sit on the last photo without looping. The video behavior has been changed which negates issue 3 and 4. It probably creates new issues if someone doesn't like it, but again some curation is going to be needed vs. trying to make every video work (I strongly believe videos should be made to look good vs. trying to have this play random videos)

The new behavior is: If a video is longer than the duration, it'll get cut short at the duration time and the next thing will play. If it's an image, the last image will crossfade to the new image. I may change this to be a 'black background' however things get wierd when there are multiple videos in a row..it's actually nice to have something behind the video to show vs. just 'black'.

If the video is shorter, when the video palyer exists (OMXPlayer does this naturally when a video is complete) then it'll go back to the last photo, and then continue the slide show.

Note: The way a video is played is the entire application is set to opacity 0, which makes it essentially transparent. The result is the video, which is started in the background, shows through. Then the Opacity gets set to 1, and since the last image that was in the slideshow is still there, you see that. The problem with trying to just move forward in the slideshow is the next item in the playlist COULD be yet another video, which would result in 'dropped images'. The safest thing to do is to show the existing image again, which means there is no 'data loss' (looking at it as a programmer protecting the user..it's always better to err on 'undesired behavior vs. data loss'. The data loss here is just that some files would get skipped. There is algorthithms that may get added to try to be smarter about this, but the cost may be too high vs. trying to get other more interesting features in.

5 i've noticed that videos are squashed into full frame, ignoring aspect ratio entirely - This needs to be fixed still, hoping for 2.08.

6 - Gif / webM - Future work. If I recall to play gifs I have to have a different player. WebM I'll have to look into VLC.

[qwksilver]

it seems that most issues here have been addressed/droped to super low priority moving to compilation issue for 2.07, this can be closed i think.

[Geektoolkit]

closing this out, tracking it in 2.09 issue sheet