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. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list