<div dir="ltr">You want the copy threshold to ALWAYS be bigger then the number of buffers queued so that the copy ALWAYS happens... :-)  To do this, make "copy_threshold" bigger than "max_buffers"...<br>
<br><br> if (pool->num_queued < pool->copy_threshold) {<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 9:26 AM, Robert Krakora <span dir="ltr"><<a href="mailto:rob.krakora@messagenetsystems.com" target="_blank">rob.krakora@messagenetsystems.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Basically, you want to set up v4l2src so that it ALWAYS copies it's buffer pool buffers to freshly allocated buffers...this was it's default behaviour in 0.10.<br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Fri, Jul 26, 2013 at 9:24 AM, Robert Krakora <span dir="ltr"><<a href="mailto:rob.krakora@messagenetsystems.com" target="_blank">rob.krakora@messagenetsystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">If the only thing that I do is set the copy threshold to 100 I can run until the memory leak that I mentioned before invokes the OS to kill gst-launch...I don't see the error reported...<br></div><div>

<div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 9:03 AM, Peter Rennert <span dir="ltr"><<a href="mailto:p.rennert@cs.ucl.ac.uk" target="_blank">p.rennert@cs.ucl.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hmm that is not the solution. It still
      fails after some minutes, reporting the same error as before. I am
      trying to find the right way to manipulate the buffer numbers now.<div><div><br>
      <br>
      <br>
      On 07/26/2013 01:13 PM, Peter Rennert wrote:<br>
    </div></div></div><div><div>
    <blockquote type="cite">
      
      <div>Rob,<br>
        <br>
        Well spotted!<br>
        <br>
        It works for me. I am monitoring the memory only with htop at
        the moment, but it seems to be stable. I think the memory leak
        stems from the fact that max_buffers is set to 0, so it will
        always make the buffer bigger and bigger. I think that is
        generally a bad idea. This might affect also plain v4l2src
        applications.<br>
        <br>
        Try this patch to get rid of the memory leak:<br>
        <br>
        diff --git a/sys/v4l2/gstv4l2bufferpool.c
        b/sys/v4l2/gstv4l2bufferpool.c                                                                    

        <br>
        index 1e74fc7..282ac2b
        100644                                                                                                               

        <br>
        --- a/sys/v4l2/gstv4l2bufferpool.c<br>
        +++ b/sys/v4l2/gstv4l2bufferpool.c<br>
        @@ -411,7 +411,7 @@ gst_v4l2_buffer_pool_set_config
        (GstBufferPool * bpool, GstStructure * config)<br>
               if (max_buffers == 0 || num_buffers < max_buffers) {<br>
                 /* if we are asked to provide more buffers than we have
        allocated, start<br>
                  * copying buffers when we only have 2 buffers left in
        the pool */<br>
        -        copy_threshold = 2;<br>
        +        copy_threshold = 15;// 2;<br>
               } else {<br>
                 /* we are certain that we have enough buffers so we
        don't need to<br>
                  * copy */<br>
        diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c<br>
        index 107ea21..0c5d91a 100644<br>
        --- a/sys/v4l2/gstv4l2src.c<br>
        +++ b/sys/v4l2/gstv4l2src.c<br>
        @@ -529,7 +529,8 @@ gst_v4l2src_decide_allocation (GstBaseSrc *
        bsrc, GstQuery * query)<br>
             update = TRUE;<br>
           } else {<br>
             pool = NULL;<br>
        -    min = max = 0;<br>
        +    min = 0;<br>
        +    max = 100;<br>
             size = 0;<br>
             update = FALSE;<br>
           }<br>
        <br>
        <br>
        On 07/25/2013 09:52 PM, Robert Krakora wrote:<br>
      </div>
      <blockquote type="cite">
        <div dir="ltr">
          <div>Hi Peter,<br>
            <br>
            I also wanted to note that when you apply the aforementioned
            "hack" to emulate the default operation of v4l2src in
            version 0.10 ("always-copy=true") with the pipeline below,
            your system will run out of memory due to a memory leak.  It
            will then kill off the gst-launch process instantiated to
            run your pipeline.  However, your pipeline will run for
            quite a bit (a lot longer than the previous 36 seconds noted
            by Yusuf a couple of months ago).<br>
            <br>
            gst-launch-1.0 uvch264src device=/dev/video0 name=src
            auto-start=true src.vfsrc ! queue ! fakesink src.vidsrc !
            queue ! video/x-h264 ! fakesink<br>
            <br>
          </div>
          Best Regards,<br>
          <br>
          Rob Krakora<br>
          <br>
        </div>
        <div class="gmail_extra"> <br>
          <br>
          <div class="gmail_quote">On Thu, Jul 25, 2013 at 4:27 PM,
            Robert Krakora <span dir="ltr"><<a href="mailto:rob.krakora@messagenetsystems.com" target="_blank">rob.krakora@messagenetsystems.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">
                <div>Hi Peter,<br>
                  <br>
                </div>
                I forgot to mention that the file that needs
                modification is named gstv4l2bufferpool.c and is under
                sys/v4l2 under plugins-good.
                <div> <br>
                  <br>
                        if (max_buffers == 0 || num_buffers <
                  max_buffers) {<br>
                          /* if we are asked to provide more buffers
                  than we have allocated, start<br>
                           * copying buffers when we only have 2 buffers
                  left in the pool */<br>
                          copy_threshold = 100; //2;<br>
                        } else {<br>
                          /* we are certain that we have enough buffers
                  so we don't need to<br>
                           * copy */<br>
                          copy_threshold = 0;<br>
                        }<br>
                </div>
              </div>
              <div>
                <div>
                  <div class="gmail_extra"><br>
                    <br>
                    <div class="gmail_quote">On Thu, Jul 25, 2013 at
                      4:21 PM, Robert Krakora <span dir="ltr"><<a href="mailto:rob.krakora@messagenetsystems.com" target="_blank">rob.krakora@messagenetsystems.com</a>></span>
                      wrote:<br>
                      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                        <div dir="ltr">
                          <div>
                            <div>Hi Peter,<br>
                              <br>
                            </div>
                            In version 0.10 v4l2src used to have a
                            property to force buffers from it's pool to
                            always be copied prior to being pushed out. 
                            This property was called "always-copy" and
                            defaulted to "true".  It seems that this was
                            removed in version 1.x.  If you go to
                            version 1.x good plugins and change
                            "copy_threadhold" from 2 to 100 you
                            effectively get the same behaviour with 1.x
                            in this regard (same as "always-copy=true"
                            default in 0.10 v4l2src) and there is no
                            error after 30 some odd seconds that causes
                            the stream to abort.<br>
                            <br>
                                  if (max_buffers == 0 || num_buffers
                            < max_buffers) {<br>
                                    /* if we are asked to provide more
                            buffers than we have allocated, start<br>
                                     * copying buffers when we only have
                            2 buffers left in the pool */<br>
                                    copy_threshold = 100; //2;<br>
                                  } else {<br>
                                    /* we are certain that we have
                            enough buffers so we don't need to<br>
                                     * copy */<br>
                                    copy_threshold = 0;<br>
                                  }<br>
                            <br>
                          </div>
                          Best Regards,<br>
                          <br>
                          Rob Krakora<br>
                          <br>
                        </div>
                        <div>
                          <div>
                            <div class="gmail_extra"><br>
                              <br>
                              <div class="gmail_quote">On Thu, Jul 25,
                                2013 at 1:06 PM, Robert Krakora <span dir="ltr"><<a href="mailto:rob.krakora@messagenetsystems.com" target="_blank">rob.krakora@messagenetsystems.com</a>></span>
                                wrote:<br>
                                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                                  <div dir="ltr">
                                    <div>
                                      <div>
                                        <div>Hi Peter,<br>
                                          <br>
                                        </div>
                                        I did some work yesterday on
                                        this and enabled logging on
                                        uvcvideo.ko and was able to
                                        correlate the buffer sizes
                                        reported by it and by the
                                        uvch264src plugin.  <span style="background-color:rgb(255,255,0)">Below</span>
                                        is the frame that failed...the
                                        size in the kernel module was
                                        the same as the size of the
                                        buffer once it got back up to
                                        the application to v4l2src and
                                        uvch264src.<br>
                                        <br>
                                        uvcvideo: Frame complete (EOF
                                        found).<br>
                                        uvcvideo: EOF in empty payload.<br>
                                        uvcvideo: uvc_v4l2_poll<br>
                                        uvcvideo:
                                        uvc_v4l2_ioctl(VIDIOC_DQBUF)<br>
                                        uvcvideo: HD Pro Webcam C920:
                                        PTS 1029592232 y 2948.098587 SOF
                                        2948.098587 (x1 2149480048 x2
                                        <a href="tel:2179588048" value="+12179588048" target="_blank">2179588048</a> y1 193593344 y2
                                        199426048 SOF offset 39)<br>
                                        uvcvideo: HD Pro Webcam C920:
                                        SOF 2948.098587 y 927116325 ts
                                        589.071670 buf ts 589.232519 (x1
                                        197984256/205/906 x2
                                        204537856/49/995 y1 1000000000
                                        y2 1099975668)<br>
                                        <span style="background-color:rgb(255,255,0)"><span>uvcvideo:

                                            uvc_dequeue_buffer -
                                            buf->bytesused = 220410</span></span><br>
                                        uvcvideo:
                                        uvc_v4l2_ioctl(VIDIOC_QBUF)<br>
                                        <br>
                                      </div>
                                      Best Regards,<br>
                                      <br>
                                    </div>
                                    Rob<br>
                                  </div>
                                  <div class="gmail_extra">
                                    <div>
                                      <div><br>
                                        <br>
                                        <div class="gmail_quote">On Thu,
                                          Jul 25, 2013 at 12:22 PM,
                                          Peter Rennert <span dir="ltr"><<a href="mailto:p.rennert@cs.ucl.ac.uk" target="_blank">p.rennert@cs.ucl.ac.uk</a>></span>
                                          wrote:<br>
                                          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A
                                            bit of an update today.<br>
                                            <br>
                                            To figure out what is going
                                            on normally and what is
                                            different in the diseased
                                            frame I printed out the
                                            debug line [line 508] that
                                            was already in the code,
                                            augmented with the total
                                            size of the buffer. The
                                            original line was:<br>
                                            <br>
                                            GST_DEBUG_OBJECT (self,<br>
                                                      "Found APP4 marker
                                            (%d). JPG: %d-%d - APP4: %d
                                            - %d", segment_size,<br>
                                                      last_offset, i, i,
                                            i + 2 + segment_size);<br>
                                            <br>
                                            I print for each time in the
                                            loop (before the sanity test
                                            that will fail finally):<br>
                                            <br>
                                            printf("Found APP4 marker
                                            (%d). JPG: %d-%d - APP4: %d
                                            - %d - size: %d\n",
                                            segment_size,<br>
                                                      last_offset, i, i,
                                            i + 2 + segment_size,
                                            (int)size);<br>
                                            <br>
                                            What I get for a normal
                                            frame is about this. The
                                            total buffer size changes
                                            and also the size of the
                                            first APP4 chunk, however, I
                                            always seem to get 4 blocks
                                            for each frame. The segment
                                            size of the first marker
                                            differs between the
                                            individual frames, while the
                                            2nd, 3rd and 4th markers are
                                            the same size all the time
                                            as far as I can tell:<br>
                                            <br>
                                            Found APP4 marker (13010).
                                            JPG: 0-8 - APP4: 8 - 13020 -
                                            size: 166660<br>
                                            <br>
                                            Found APP4 marker (65533).
                                            JPG: 13020-13020 - APP4:
                                            13020 - 78555 - size: 166660<br>
                                            <br>
                                            Found APP4 marker (65533).
                                            JPG: <a href="tel:78555-78555" value="+17855578555" target="_blank">78555-78555</a>
                                            - APP4: 78555 - 144090 -
                                            size: 166660<br>
                                            <br>
                                            Found APP4 marker (22566).
                                            JPG: 144090-144090 - APP4:
                                            144090 - 166658 - size:
                                            166660<br>
                                            <br>
                                            <br>
                                            The frame that causes the
                                            failure of the system has
                                            the following output:<br>
                                            <br>
                                            Found APP4 marker (12084).
                                            JPG: 0-8 - APP4: 8 - 12094 -
                                            size: 165485<br>
                                            <br>
                                            Found APP4 marker (65533).
                                            JPG: 12094-12094 - APP4:
                                            12094 - 77629 - size: 165485<br>
                                            <br>
                                            Found APP4 marker (65533).
                                            JPG: 77629-77629 - APP4:
                                            77629 - 143164 - size:
                                            165485<br>
                                            <br>
                                            Found APP4 marker (22566).
                                            JPG: 143164-143164 - APP4:
                                            143164 - 165732 - size:
                                            165485<br>
                                            <br>
                                            <br>
                                            As you can see it seems as
                                            the last segment reaches out
                                            of the total size of the
                                            buffer. As the last segment
                                            seems to be always of a
                                            length 22566, I think for
                                            some reason (that does not
                                            happen in gstreamer 0.10) a
                                            piece of the h264 stream is
                                            missing in this particular
                                            buffer.<br>
                                            <br>
                                            The number of bytes getting
                                            lost is not the same for
                                            different trials, neither is
                                            the cut-off. For my second
                                            trial I got:<br>
                                            <br>
                                            Found APP4 marker (22566).
                                            JPG: 144796-144796 - APP4:
                                            144796 - 167364 - size:
                                            165815<br>
                                            <br>
                                            So where are these bytes?
                                            And why are they missing so
                                            regularly?
                                            <div>
                                              <div><br>
_______________________________________________<br>
                                                gstreamer-devel mailing
                                                list<br>
                                                <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
                                                <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
                                              </div>
                                            </div>
                                          </blockquote>
                                        </div>
                                        <br>
                                        <br clear="all">
                                        <br>
                                      </div>
                                    </div>
                                    <div>-- <br>
                                      <font color="#888888"><font color="blue">Rob Krakora<br>
                                          MessageNet Systems <br>
                                          101 East Carmel Dr. Suite 105
                                          <br>
                                          Carmel, IN 46032 <br>
                                          <a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
                                          <a value="+13176630808">(317)663-0808</a>
                                          Fax </font></font> </div>
                                  </div>
                                </blockquote>
                              </div>
                              <br>
                              <br clear="all">
                              <br>
                              -- <br>
                              <font color="#888888"><font color="blue">Rob

                                  Krakora<br>
                                  MessageNet Systems <br>
                                  101 East Carmel Dr. Suite 105 <br>
                                  Carmel, IN 46032 <br>
                                  <a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext
                                  212<br>
                                  <a value="+13176630808">(317)663-0808</a>
                                  Fax </font></font> </div>
                          </div>
                        </div>
                      </blockquote>
                    </div>
                    <br>
                    <br clear="all">
                    <br>
                    -- <br>
                    <font color="#888888"><font color="blue">Rob Krakora<br>
                        MessageNet Systems <br>
                        101 East Carmel Dr. Suite 105 <br>
                        Carmel, IN 46032 <br>
                        <a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
                        <a value="+13176630808">(317)663-0808</a>
                        Fax </font></font> </div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <br>
          -- <br>
          <font color="#888888"><font color="blue">Rob Krakora<br>
              MessageNet Systems <br>
              101 East Carmel Dr. Suite 105 <br>
              Carmel, IN 46032 <br>
              <a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
              <a value="+13176630808">(317)663-0808</a>
              Fax </font></font> </div>
        <br>
        <fieldset></fieldset>
        <br>
        <pre>_______________________________________________
gstreamer-devel mailing list
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
gstreamer-devel mailing list
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><font color="#888888"><font color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a value="+13176630808">(317)663-0808</a> Fax
</font></font>
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><font color="#888888"><font color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a value="+13176630808">(317)663-0808</a> Fax
</font></font>
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><font color="#888888"><font color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a value="+13176630808">(317)663-0808</a> Fax
</font></font>
</div>