no.
the "1" really means "prefer the film-decoding backend #1" (instead of, e.g.
#0), it has nothing to do with frame-wise access.
the fact that it worked for you is mainly because on *your specific setup* the
backend #0 does not support frame-accurate seeking, whereas #1 does support it.
the film-decoding backends are plugins (look out for "gem_film*.dll" files), so
there is absolutely no way to guarantee that "1" will have a specific behaviour.
also, i want to discourage people from using enumeration values ("1") for
selecting the preferred backend (it was a bad idea in the first place), instead
one should use names ("QuickTime", "DirectShow",...)
---
** [bugs:#241] [pix_film] no longer responds to incoming frame numbers**
**Status:** closed
**OS:** w32
**Release:** unknown
**Created:** Mon May 25, 2015 10:39 AM UTC by Anonymous
**Last Updated:** Fri May 29, 2015 10:33 AM UTC
**Owner:** nobody
win7
64 bit
GEM 93.3/1/0
[pix_film] no longer responds to incoming frame numbers. tested with .avi,
.mov, .mp4.
[pix_film]: loaded file:
C:/Users/brandt/Desktop/raspberry/steve/Steve_Jobs_39_2005_Stanford_Commencement_Address.mov
with 1 frames (320x240) at -1.000000 fps
yours sincerely
[email protected]
---
Sent from sourceforge.net because [email protected] is subscribed to
https://sourceforge.net/p/pd-gem/bugs/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/pd-gem/admin/bugs/options. Or, if this is a mailing
list, you can unsubscribe from the mailing list._______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
