Hi IOhannes,
when opening a .mov file on pd-extended on linux, I get :
[...]
Segmentation fault (core dumped)
On the command line, gmerlin fails to open the file as well, with the same message, but lqtplay is able to play the movie.
by the "same message", do you mean that gmerlin also segfaults?
No, I mean "No video decoder found for fourcc avc1" that I quoted below.
i think it's a bug in gmerlin rather than Gem. so gmerlin first thinks it can decode the film and then fails
Yes, that's sound just like it. Because gmerlin returns the right video size and frame count[1]. That can be tricky to handle in a reliable and consistent way.
However, I would blame Gem for the segfault. Maybe Gem could check if the pointer to the video stream is valid before using it?
it would be great if you could provide a (short) clip that triggers the crash, so the underlying bug can be fixed.
Here's one and a test patch: http://charles.goyard.free.fr/temp/
actually there is an undocumented and little tested extra argument to "open" that allows you to give a given backend priority (that is: the given backend will be tried first, and then all the rest): [open foo.mov RGBA quicktime4linux( should use lqt4l before gmerlin.
This does the trick with Gem from git but not Gem in pd-extended. Thanks !
come to think of it, i think the API should be changed to be consistent with [pix_video]. e.g. [driver quicktime4linux, open foo.mov( to exclusively(!) select lqt for opening any file.
Sounds good to me.
Thanks, Charles
[1] btw the help files for pix_film and pix_movie mention fps instead of frame count.