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 722687 - Weird behaviour when using webm file for input - videorate issue?
Weird behaviour when using webm file for input - videorate issue?
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-01-21 12:38 UTC by Christian Fredrik Kalager Schaller
Modified: 2014-03-06 10:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Fredrik Kalager Schaller 2014-01-21 12:38:53 UTC
Trying to transcode (in transmageddon) this file:
http://downloads.xiph.org/video/A_Digital_Media_Primer_For_Geeks-360p.webm

Re-encoding both audio and video. It 'works', although the resulting file is gigantic and it plays back in extreme slow motion. 

Trying other webm file works well, but this one is giving me issues. The file plays back fine in Totem.

Trying to recreate the Transmageddon pipeline on the commandline gives me:
gst-launch-1.0 filesrc location="/home/cschalle/Videos/A_Digital_Media_Primer_For_Geeks-360p.webm" ! decodebin name=decode ! videoconvert ! videoscale ! videoconvert ! videorate ! theoraenc ! oggmux name=mux ! filesink location=/tmp/test.ogg


This pipeline hangs, which is not the same behaviour as with Transmageddon, but also not right. The pipeline works if you remove the videorate element.
Comment 1 Christian Fredrik Kalager Schaller 2014-03-05 16:08:27 UTC
ok, tested again today and the gst-launch pipeline seems to work exactly like transmageddon now. Meaning it is dog slow.
Comment 2 Nicolas Dufresne (ndufresne) 2014-03-05 16:49:59 UTC
I've mention that the framerate our of that webm file is wrong, it's a big number, which mean videorate will create a lot of frames. It works in playback because duration and timestamp are correct. I suspect a conversion is missing in the decoder.
Comment 3 Wim Taymans 2014-03-06 09:48:22 UTC
I confirm, the framerate is wrong (90001/1). It seems wrong in the matroska file, vlc reports 909090 fps because of rounding errors. mplayer finds 47 fps because it does some (wrong) probing.

There is no framerate in the vp8 video stream so we can't use that. There does not seem to be a good way to detect and correct this error except for reading the beginning of the file or maybe the index.
Comment 4 Christian Fredrik Kalager Schaller 2014-03-06 10:12:24 UTC
ok, closing this a not a bug, will notify Monty that his webm file is broken.