Hi,
when opening a .mov file on pd-extended on linux, I get :
verbose(5): gmerlin support verbose(5): quicktime4linux support [pix_film]: opening /home/charles/w/enversdudehors/endo/fev2013-2.mov with format 1908 [pix_film:track] No video decoder found for fourcc avc1 (0x61766331) track 0 does not contain a video-stream: skipping Pixelformat not specified for video frame verbose(5): gmerlin: succeeded [pix_film]: loaded file: /home/charles/w/enversdudehors/endo/fev2013-2.mov with 211432 frames (576x576) at 60.000000 fps 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.
However, it seems these messages are contradictory : [pix_film:track] No video decoder found for fourcc avc1 (0x61766331) verbose(5): gmerlin: succeeded
I'm not sure it's a bug. Maybe there's a way to force pix_film to use a specific backend ?
According to ffmpeg, the stream is : Video: h264 (Main) (avc1 / 0x31637661), yuv420p
Thanks,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-02-18 22:42, Charles Goyard wrote:
Hi,
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?
However, it seems these messages are contradictory : [pix_film:track] No video decoder found for fourcc avc1 (0x61766331) verbose(5): gmerlin: succeeded
i think it's a bug in gmerlin rather than Gem. so gmerlin first thinks it can decode the film and then fails (something that happens to humans as well).
it would be great if you could provide a (short) clip that triggers the crash, so the underlying bug can be fixed.
I'm not sure it's a bug. Maybe there's a way to force pix_film to use a specific backend ?
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.
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.
fgamsdr IOhannes
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-02-19 11:36, Charles Goyard wrote:
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/
hmm, both Gem (i tried 0.93.git:ee897d5 and 0.93.3 from Debian) and gmerlin (1.2.0~dfsg-3 from Debian) can play the file just fine here.
if i just call it with gmerlin_play i get:
$ gmerlin_play crashme.mov
[avdecoder.audio_ffmpeg] Warning: Codec not found: FFmpeg Sonic decoder
[avdecoder.superindex] Info: Detected B-pyramid, fixing possibly
broken timestamps
Segmentation fault
$
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 !
you could also just deinstall the GMERLIN-backend (if you don't need it for other stuff). since PdX gives you an all or nothing, you'd had to remove (or rename) the "gem_filmGMERLIN.so" file.
[1] btw the help files for pix_film and pix_movie mention fps instead of frame count.
ah yes, and the fps is reported as well, though that's not mentioned at all.
fgam,sdr IOhannes
Hi,
thanks for trying.
IOhannes m zmoelnig wrote:
hmm, both Gem (i tried 0.93.git:ee897d5 and 0.93.3 from Debian) and gmerlin (1.2.0~dfsg-3 from Debian) can play the file just fine here.
Now that's strange. A big difference is that I run on Archlinux. I have: gmerlin 1.2.0 gavl 1.4.0 libquicktime 1.2.4
gmerlin seems to be built with libquicktime as a dependency. I even tried applying your fix_zeroplugins.patch from the debian package, it didn't fixed it :).
you could also just deinstall the GMERLIN-backend (if you don't need it for other stuff). since PdX gives you an all or nothing, you'd had to remove (or rename) the "gem_filmGMERLIN.so" file.
I'm more ok with converting the video to mpeg :).
However, I really love the possibility to force the selection of the backend.
With gdb I could see that the crash occurs inside filmGMERLIN::getFrame(void), on this line :
bgav_read_video(m_file, m_gframe, m_stream);
m_stream is a null pointer there. I changed :
bgav_set_video_stream(m_file, m_stream, BGAV_STREAM_DECODE); if(!bgav_start(m_file)) { close(); return false; }
to:
bgav_set_video_stream(m_file, m_stream, BGAV_STREAM_DECODE); if(!bgav_start(m_file) || !m_stream) { close(); return false; }
and now at least it does not segfaults. Maybe there's something nicer to do (printing an error message on the console ?), but it looks like a good start.
Cheers, Charles
Charles Goyard wrote:
With gdb I could see that the crash occurs inside filmGMERLIN::getFrame(void), on this line :
bgav_read_video(m_file, m_gframe, m_stream);
m_stream is a null pointer there. I changed :
bgav_set_video_stream(m_file, m_stream, BGAV_STREAM_DECODE); if(!bgav_start(m_file)) { close(); return false; }
to:
bgav_set_video_stream(m_file, m_stream, BGAV_STREAM_DECODE); if(!bgav_start(m_file) || !m_stream) { close(); return false; }
and now at least it does not segfaults. Maybe there's something nicer to do (printing an error message on the console ?), but it looks like a good start.
To be more complete: Gem seems to fall back to quicktime4linux after failing in gmerlin and the film plays OK.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-02-19 11:36, Charles Goyard wrote:
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.
implemented in git.
fgmasdr IOhannes
-
Charles Goyard -
IOhannes m zmoelnig