After adding the -fps option the result is the same: omxplayer -fps 30 myvideo.h264 Resulted in highly accelerated fps, a 10 second video was played in 1 or 2 seconds. I found that playing it with omxplayer like this: omxplayer myvideo.h264 I know that this file doesn't have the fps metadata associated with it. The video decoders on the Pi are designed to decode video and work best with video containers that strictly conform to specified standards or streaming profiles where you cannot seek.I made a video using the Raspberry Pi camera that came with a.
#Omxplayer file time loading how to
There are so many variables that cause really bad video experience- but its mostly because people encode video without actually understanding how to do it properly, using bad examples, or built in high compression profiles that are designed for continious streaming, like webcam feeds, TV feeds but are used for stored video instead ! Sometimes strange framesizes cause corruption during splitting of video in memory and these artefacts are produced. So it loaded the best P or B frame and started playing from there. If you see this is means the video file has its keyframes very widely spread apart and the player and hardware was not able to fully load the segment of video into memory to chop it up. The artefacts that you experience are caused by unusual framesizes, weird framerates or really big keyframe spaces. This in memory process can take some time to process the video file.
#Omxplayer file time loading software
When the software reads the video from start to end without interruption, its fine, but when you seek on video that has i-keyframes very far apart, this is what happens. Something like 2~15 seconds apart will reduce the file size up to 40% without loosing video quality, impressive!!? When you acquire a video file encoded by somebody that needs smaller files because they are in a remote place, they use a custom profiles, usually achieved by reduces i-keyframes in the video, to reduce file size but keep a fairly decent image quality.
This takes up a lot of space but gives you the best quality of video and the fastest seek response with no artefacts. We are talking about 15mbs video rate with i-keyframes every second. If it was encoded by a noob or used custom settings to try and get the best compression settings, this is the consequence, slow seek times and artefacts.īluray files follow industry standard profiles so that any decoding hardware that follow these standards can quickly deal with user requests. The core problem is the compression settings used with the encoder for your file.
The GPU is not a round robin solution that magically makes everything work. Yes it is true that using the GPU speeds up rendering of encoded video or rendering 3D graphics but they must follow a strict standard. This behaviour has very little to do with the hardware.
0 kommentar(er)
