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 627971 - vp8enc regenerate timestamps
vp8enc regenerate timestamps
Status: RESOLVED DUPLICATE of bug 625558
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 564957
 
 
Reported: 2010-08-25 18:06 UTC by Oleksij Rempel
Modified: 2010-10-10 13:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Oleksij Rempel 2010-08-25 18:06:22 UTC
Hallo all,
as option we try to do vp8 encoding on cheese. It come out that vp8enc filed to work with variable frame rate. Web cam announce itself with 30fps. 

With verbose fakesink on timestamps i see that before vp8enc i get ~15fps, after vp8 i get exact 30fps. The problem is, the count of frames is the same. So it looks like vp8enc some where regenerate timestamps for same frames.
Comment 1 Sebastian Dröge (slomo) 2010-08-25 18:21:12 UTC
Yes, vp8enc and vp8dec have some problems with variable framerate streams and streams without a framerate unfortunately.
Comment 2 Filippo Argiolas 2010-08-26 14:16:01 UTC
Sebastian could you please elaborate more on this thing?
Is it an issue with the encoder itself? with gstreamer implementation? is it fixable?
Comment 3 Sebastian Dröge (slomo) 2010-08-26 14:42:32 UTC
It's a problem in the video encoder base class
Comment 4 Sebastian Dröge (slomo) 2010-08-26 17:35:18 UTC
A workaround for the problem would be, to use videorate before the encoder. You need this anyway if you plan to store it in an Ogg container (but not for Matroska/WebM and maybe others).
Comment 5 Oleksij Rempel 2010-08-26 18:43:51 UTC
This is not workaround. this is actual bug.
Comment 6 Oleksij Rempel 2010-08-26 19:07:56 UTC
@Sebastian, you said "video encoder base class", you mean libvpx or gstreamer? Are there some peaple who ready to work on it?
Comment 7 Sebastian Dröge (slomo) 2010-08-26 19:09:07 UTC
Sure, it's a real bug that should be fixed... but until then you can use videorate to have something working now.

It's a bug in the video base classes in gst-plugins-bad/gst-libs/gst/video
Comment 8 Oleksij Rempel 2010-08-26 19:19:42 UTC
Thank you a lot for your attention :D
Comment 9 Filippo Argiolas 2010-08-28 16:24:23 UTC
(In reply to comment #5)
> This is not workaround. this is actual bug.

For the record, and for who doesn't want to go and read all the comments in the dependent Cheese bug, the actual bug Alexey is talking about here is that most webcams advertise a quite big framerate (say 30 fps) but actually output a lower number of frames per second (usually around 10/15 fps with average/good light conditions).
The bug here is that videorate duplicates missing frames to reach the advertised framerate unnecessarily increasing (doubling when you're lucky but even triplicating and quadruplicating) the load for the encoder.

This is especially an issue with container/encoders that don't support variable framerate (theora+ogg) but vp8+webm seems a good solution so it would be great to be able to use it from gstreamer.
Comment 10 Tim-Philipp Müller 2010-09-06 11:00:30 UTC
Just on a side note: videorate in git now marks duplicated frames with the GAP buffer flag, which should make it possible to reduce the overhead in this (theoraenc/ogg) case.
Comment 11 Zaheer Abbas Merali 2010-10-10 13:59:45 UTC
this is a dup of #625558

*** This bug has been marked as a duplicate of bug 625558 ***