After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 567800 - Mp4 created by Avidemux don't play.
Mp4 created by Avidemux don't play.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.10
Other Linux
: Normal normal
: 0.10.14
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 562827 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-14 20:36 UTC by Hammered
Modified: 2009-02-26 17:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Hammered 2009-01-14 20:36:46 UTC
I am using Ubuntu 8.10 amd64. The problem is this:
Create a video with Avidemux(2.4.3)(not the gstreamer element) and choose as container "MP4". The resulting file doesn't playback in gstreamer. Totem and gst-launch(using decodebin) only show the first frame. I can also seek to a new location in the stream but it doesn't play the stream.
The same file is playable by mplayer, VLC and in Windows using MPC+ffdshow.
I think the problem is in qtdemux.
Comment 1 Wim Taymans 2009-01-15 12:10:10 UTC
do you have an example movie for download somewhere?
Comment 2 Hammered 2009-01-15 12:18:30 UTC
Just create/transcode a video with Avidemux and choose MP4 as the container. The resulting file won't play. 
If you can't reproduce the problem that way, I can provide a link to an anime torrent.(is that ok to do?)
Comment 3 Wim Taymans 2009-01-15 12:53:14 UTC
It seems avidemux creates a wrong mp4 file with a very low playback rate. with qtdump:

 ...
    edit atom (edts)
     edit list (elst)
      version 0
      flags 0
      total_entries 1
      edit list table
       duration 151861
       time 0
>>     rate 0.000015
  ....

Most other players ignore the rate because they can't support it but GStreamer actually plays that track 66666x slower.
Comment 4 Hammered 2009-01-15 13:00:54 UTC
Wow. Should I report this as a bug to Avidemux's tracker?
Comment 5 Wim Taymans 2009-01-15 14:56:28 UTC
Yes, please report, they should encode the media rate in the elst atom as a 32-bit fixed-point number, like 0x10000 instead of just 0x1.

I did a workaround for now because rates of 1 and lower are not very useful and probably indicate a problem.

        * gst/qtdemux/qtdemux.c: (qtdemux_parse_segments):
        Catch invalid and commonly wrong playback rates in the elst atoms.
        Fixes #567800.
Comment 6 Edward Hervey 2009-02-26 17:14:15 UTC
*** Bug 562827 has been marked as a duplicate of this bug. ***