attract
attract copied to clipboard
mickelson
Problem with animated GIF
Recently i've opened an issue (already closed) that i thought it was an compilation problem or a video problem: error decoding video (receiving frame): End of file, in attract mode 2.6.2, in a RPi 4, compiled with Xinerama.
But now i managed to discover that in reality this issue happens with all animated gifs. I have tried with a bunch of different animated gifs and all causes the "error decoding video (receiving frame): End of file"
If anyone knows anything about it i will be grateful.
I was getting the same warning with video files while looking at #720 So I tried re-encoding various video files & encoding sequences of images. To cut a long story short, I found that using "ffmpeg -crf 0" caused the warning.
Error decoding video (receiving frame): End of file
Even when re-encoding known good video files.
H264 wiki mentions -crf 0 is lossless https://trac.ffmpeg.org/wiki/Encode/H.264
A re-encode with -crf 1 works fine....
ffmpeg -r:v 30 -i "./Countdown 5 Seconds HD.mp4" -codec:a aac -codec:v libx264 -preset medium -pix_fmt yuv420p -crf 1 "output_crf1.mp4"
Animated PNG files seem to be handled the same (With same warning) https://github.com/mickelson/attract/blob/c209088df7ca5afda17f928e17056092b9874ccd/src/media.cpp#L1376 animated_0-9
AM requires the animated png to have a *.apng extension
A quick look at media.cpp seems to indicate that do_flush has something to do with End of file. Skipping the do_flush sequence seems to avoid the error/warning.
However do_flush purpose is to be realized before this is satisfactory.
Update on media.cpp Looks like the do_flush was recently added. https://github.com/mickelson/attract/commit/1b933c39dbd9201b09140e922babe21939d64dad
Commit notes:
- added code to flush the video codec properly at the end of the video stream
However I suspect that we only need to send a null packet to the decoder, And don't need to receive a frame....
The "r" status shows a value of -541478725 with animated Gif/Png & some mp4 files.
On second thoughts this patch is a better approach to the EOF warning for animated gif, png & lossless h264. Rather than looking at the status value it just checks to see if do_flush is executing.
Pull request (If Andrew deems it acceptable) https://github.com/mickelson/attract/pull/726
Local Commit https://github.com/OzFalcon/attract/commit/ed2e966a6edf8eae5b739ec395c51efa9a17eaa0