search

jvcleave / ofxOMXPlayer

OpenMax accelerated video player for openFrameworks on the Raspberry Pi 0-3. Does not work with RPI4
GNU General Public License v2.0
180 stars 61 forks source link

Threaded init routine for start playing new video file #29

Closed adrchlik closed 9 years ago

adrchlik commented 10 years ago

I usually play several small video loops at one time. When I start new video loop it freeze for a short time all currently playing videos, because the initialization of a new video takes a time. Do you plan to do threaded version of initialization routine for start playing new video file ?

jvcleave commented 10 years ago

I don't know if I can as the texture generation needs to be done on the main thread. I was thinking of making it possible to pass in your own pre-allocated fbo/texture as this is probably the main bottleneck.

adrchlik commented 10 years ago

Yes. This is what I mean. It could work this way. The start routine will be split into two part. In one user pass video file and gets required dimensions for texture and egl image. Then create the texture and egl image ownself in main thread and then at second call pass required texture and egl image to omxplayer.

jvcleave commented 9 years ago

Looking at this again I am not sure threading it will save any time as the video can't open anyway until it gets the hints/info from libav

The texture isn't being regenerated unless the new video width/height are different and in that case it will again slow down

There may be possible speed ups in reusing the engine components but I think most of the efficiency around allocating textures is already in there

jvcleave commented 9 years ago

found a big bottleneck in the file probing (took 3 seconds off in example playlist when switching movies)

Didn't see any side effects in my testing but I put an #define in cause someone needs it

a0397ce7eb33719b64e582204929e43a35c24b28

timonsku commented 9 years ago

So the gap between files is also due to the time libav/ffmpeg needs to get the file info? Ah ok, tested the commit now. Works great, those 20-40ms are definitely not the major factor for the gaps but maybe some fine tuning could be done by doing the file probing manually ahead of time.