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 673017 - Screencast recorder doesn't save length / incorrectly finalizes files
Screencast recorder doesn't save length / incorrectly finalizes files
Status: RESOLVED DUPLICATE of bug 675128
Product: gnome-shell
Classification: Core
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 680528 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-03-28 18:52 UTC by alex
Modified: 2012-07-24 14:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example for incorrect encoding of recorder (657.88 KB, video/webm)
2012-03-28 18:52 UTC, alex
Details

Description alex 2012-03-28 18:52:27 UTC
Created attachment 210801 [details]
example for incorrect encoding of recorder

if you record something with the gnome-shell recorder the output is saved with the length of 0 seconds.
This causes totem and most probably other video players too to parse incorrectly.
I add an example.
Comment 1 Jean-François Fortin Tam 2012-05-31 17:02:31 UTC
I was about to report the same bug. Resulting webm files are not seekable by totem and pitivi, which makes the screencast files impossible to edit.

Excerpts from a chat in #gstreamer:


<__tim> it looks like the file hasn't been finalised properly, the application needs to take care of that by doing a gst_element_send_event (pipeline, gst_event_new_eos ()); and then waiting for the EOS message on the bus before  shutting it down (rather than just doing set_state (GST_STATE_NULL) to stop it)
<__tim> or perhaps it was created in streamable=TRUE mode?

<__tim> hrm, [the gnome shell recorder code] looks OK at first glance (-src returns FLOW_UNEXPECTED, which sends an EOS event, which leads to EOS message, which is where they clean up)
<__tim> oh, I think it has to do with them not using filesink directly, but fdsink
<__tim> matroskademux could probably still do some extra legwork to enable seeking in such files :)
<__tim> but even then fdsink *should* work fine - it depends a bit on how it's hooked up exactly

<__tim> nekohayo, I get both a segment size and a duration (in 3.2, with core/base 0.10.36 and good 0.10.31)
<nekohayo> unlike the webm file I linked to initially?
<__tim> yup
<nekohayo> guess it's a regression in 3.4 then
Comment 3 Jasper St. Pierre (not reading bugmail) 2012-05-31 17:16:06 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 675128 ***
Comment 4 Tim-Philipp Müller 2012-07-24 14:20:45 UTC
*** Bug 680528 has been marked as a duplicate of this bug. ***