[gstreamer-bugs] [Bug 627459] New: theoraenc should provide option for TH_ENCCTL_SET_DUP_COUNT

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=627459
  GStreamer | gst-plugins-base | 0.10.x

           Summary: theoraenc should provide option for
                    TH_ENCCTL_SET_DUP_COUNT
    Classification: Desktop
           Product: GStreamer
           Version: 0.10.x
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: bug-track at fisher-privat.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Hallo,

i hacking currently on Cheese, and met some really bad performance problem. It
was caused by combination of "videorate ! theoraenc". Webcams usually provide
match less framerate than they say. Even with good light my netbooks webcam
tell it send 30fps but give only 4fps. So, most of the CPU time used to encode
duplicate frames.

IMHO: it should be dynamic. Get less - do less.

I know there is a reason for "videorate" - "oggmux" do not support variable
frame rate. This is correct but there is other option too. libtheora can
replace "videorate" and provide only placeholder for duplicate frames. The
problem is. gstreamers theoraenc do not do this.

Here is an answer i got from ogg-dev:
On Do, 2010-08-19 at 08:29 -0700, Timothy B. Terriberry wrote:
> The Ogg mapping for Theora is fixed-framerate. You can hack something 
> into Ogg by using a higher framerate and inserting "duplicate frame" 
> packets (which cost approximately one byte each, including the
container 
> overhead), but AFAIK there is no gstreamer support for doing this 
> automatically.

and here is part from libtheora/include/theora/theoraenc.h describing this
option:

/**Sets the number of duplicates of the next frame to produce.
 * Although libtheora can encode duplicate frames very cheaply, it costs some
 *  amount of CPU to detect them, and a run of duplicates cannot span a
 *  keyframe boundary.
 * This control code tells the encoder to produce the specified number of extra
 *  duplicates of the next frame.
 * This allows the encoder to make smarter keyframe placement decisions and
 *  rate control decisions, and reduces CPU usage as well, when compared to
 *  just submitting the same frame for encoding multiple times.
 * This setting only applies to the next frame submitted for encoding.
 * You MUST call th_encode_packetout() repeatedly until it returns 0, or the
 *  extra duplicate frames will be lost.
 *
 * \param[in] _buf <tt>int</tt>: The number of duplicates to produce.
 *                 If this is negative or zero, no duplicates will be produced.
 * \retval TH_EFAULT \a _enc_ctx or \a _buf is <tt>NULL</tt>.
 * \retval TH_EINVAL \a _buf_sz is not <tt>sizeof(int)</tt>, or the
 *                    number of duplicates is greater than or equal to the
 *                    maximum keyframe interval.
 *                   In the latter case, NO duplicate frames will be produced.
 *                   You must ensure that the maximum keyframe interval is set
 *                    larger than the maximum number of duplicates you will
 *                    ever wish to insert prior to encoding.
 * \retval TH_EIMPL   Not supported by this implementation in the current
 *                    encoding mode.*/
#define TH_ENCCTL_SET_DUP_COUNT (18)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.