hi. this time my question has nothing to do with debian packaging; phew :-)
i'm using gmerlin-avdecoder as a decoding backend in pd/Gem. everything works fine, but seeking is incredibly slow (first noticed by a user with a h.264 movie) the problem is, that Gem implements all playback via frame accurate seeking. so even if i'm just playing back a video at "normal" speed, this is done by seeking to the next frame. this allows users to very simply change the playback speed (e.g. double rate; vari-rate;playback of a 29.97fps movie at the correct speed in an environment that varies the display framerate;...) i'm aware that this is not really optimal. nevertheless the speed penalty seems to be outrageous. my test movie is h.264 with 1280x720 pixels (@25fps) (http://www.elecard.biz/clips/mp4/misc/River.mp4 = 54MB) when i play it back without seeking, it plays back in about realtime (haven't done any exact measurements though) when i play it back with seeking for the next frame, it degrades to about 3-8 fps, with 300ms spent in bgav_seek_scaled() i understand _some_ degredation, but not if the requested frame is virtually the next frame. this is the sequence of timestamps when playing back without seek: got: 2001 got: 3000 got: 4000 got: 5000 got: 6001 got: 7000 got: 8000 got: 9000 got: 10001 got: 11000 got: 12000 got: 13000 got: 14001 got: 15000 got: 16000 got: 17000 got: 18001 got: 19000 got: 20000 got: 21000 got: 22001 got: 23000 got: 24000 whereas this is the list of seeked and decoded frames seeking is done like: <snip> dur=gavl_video_format_t->frame_duration; // 1000 scale=gavl_video_format_t->timescale); // 25000 // ... req=frame*dur; bgav_seek_scaled(file, req, scale); </snip>: req: 1000 got: 2001 req: 2000 got: 2001 req: 3000 got: 2001 req: 4000 got: 4000 req: 5000 got: 5000 req: 6000 got: 7000 req: 7000 got: 7000 req: 8000 got: 8000 req: 9000 got: 9000 req: 10000 got: 13000 req: 11000 got: 13000 req: 12000 got: 13000 req: 13000 got: 13000 req: 14000 got: 17000 req: 15000 got: 17000 req: 16000 got: 17000 req: 17000 got: 17000 req: 18000 got: 21000 req: 19000 got: 21000 req: 20000 got: 21000 req: 21000 got: 21000 req: 22000 got: 25000 req: 23000 got: 25000 i notice 2 things: the timestamp of the decoded frames is sometimes "off by 1" (doesn't matter whether seeked or not). in the 2nd part of the last list, the timestamps of the received frames are in large steps, even though bgav_can_seek_sample() is TRUE; the latter i don't understand at all. am i doing something wrong? and is there a way to find out the timestamp of the to-be-decoded-next frame in advance? if so, i would just no issue a seek() if the next frame is "sufficiently close" to the requested frame anyhow. bhmsdt IOhannes
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Gmerlin-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gmerlin-general
