• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 2882 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Gstreamer pipeline for encoding video not repeatable

Doug Linhardt
Prodigy 140 points

I am working with a dm368 with the 4.02.00.06 DVSDK.  I aw working with gstreamer.  Based on the Software Developers Guide and various suggestions from the web, I have cobbled together the following pipeline:

gst-launch -v v4l2src always-copy=FALSE input-src=Composite num-buffers=800 ! video/x-raw-yuv, format=\(fourcc\)NV12, width=720, height=480, framerate=30000/1001 ! TIPrepEncBuf contiguousInputFrame=true ! TIVidenc1 codecName=mpeg4enc engineName=codecServer ! filesink location=/opt/video/sample.m4v

This pipeline works beautifully--ONCE.  Next I run a pipeline to display the video I recorded with the following pipeline:

 gst-launch filesrc location=/opt/video/sample.m4v  ! typefind ! TIViddec2 ! queue ! tidisplaysink2 video-standard=auto display-output=component

When I run the encoding (first) pipeline a second (or sometimes third) time, it fails.  The failure reason changes everytime I run it.  Sometimes there is a SIGSEGV.  Sometimes it is a problem with free().  Sometimes it is an invalid pointer.  It's not the same problem every time.

Note: Actually, the problem can occur without running the display pipeline. The display pipeline seems to work well when not in conjunction with the encoding pipeline, so I strongly doubt it's the problem.

My suspicion is that one of the TI plugins (TIPrepEncBuf or TIVidenc1) doesn't clean memory correctly (or as I expect it to).  Or maybe I'm using them incorrectly.

Could somebody help me correct my pipeline so I don't keep having these memory problems?

Thanks

 

(Edit: fix spelling, clarify which pipeline fails)

  • 0
    Prodigy 140 points

    I just tried a "pass through" pipeline which just captures the video and then displays it:

    gst-launch -v v4l2src always-copy=FALSE input-src=Composite ! video/x-raw-yuv, format=\(fourcc\)NV12, width=720, height=480 ! queue ! tidisplaysink2 video-standard=auto display-output=component

    A similar error happens.  The first time it works perfectly.  The second or third time it works, but when I try to shut it down, I get an error in free() and a stack backtrace.

    Now I'm wondering if there is a problem with how I'm using v4l2src.

  • 0 in reply to Doug Linhardt
    TI__Intellectual 910 points

    Doug,

    Keeping along the lines of trying to narrow down if an issue in the capture, do you see any issues in your second "loopback" case if you put back in your "num-buffers=800" option?  If you don't do that, you're probably shutting down via Ctrl-C and any issues related to free() might be a separate issue with an ungraceful release of driver-allocated buffers, and not the original problem you were seeing.

    If you can run the "loopback" multiple times without issue, its probably not an issue in the capture/display.

    Another thing to try, going back to your original pipeline, is to basically throw away all capture data instead of sending it to the encoder + display.  If you can reproduce the issue with as few things in the pipeline as possible, it will help to narrow down the problem.  Try something like:

    gst-launch -v v4l2src always-copy=FALSE input-src=Composite num-buffers=800 ! video/x-raw-yuv, format=\(fourcc\)NV12, width=720, height=480, framerate=30000/1001 ! fakesink

     

    If that runs ok multiple times, then v4l2src  is ok.  Then add in the next pieces of the pipeline:

    gst-launch -v v4l2src always-copy=FALSE input-src=Composite num-buffers=800 ! video/x-raw-yuv, format=\(fourcc\)NV12, width=720, height=480, framerate=30000/1001 ! TIPrepEncBuf contiguousInputFrame=true ! fakesink

    etc.

     

    On a side note, since you're capturing NV12, the "TIPrepEncBuf" element might not actually be needed -- you might want to try your pipeline without it and see if it works, because you would get better performance.  You would need to add "contiguousInputFrame=true" to TIVidenc1 if you remove it though.

    Best regards,
    Don


  • 0 in reply to Don Darling
    Prodigy 140 points

    Don,

    Thanks for your suggestions.  A few days away from the task let me clear my mind and try to sort through what was working and what was not.

    First of all, when I found the "num-buffers" field in a pipeline somewhere on the web, I never looked it up to see what it actually did. I just went ahead and blindly used it. Adding that field to the v4l2src element did fix the pass-thru pipeline.  That means, then, that I apparently cannot run a pipeline (using gst-launch) with an arbitrarily long duration and cancel out with ^C without possible downstream problems.  That's unfortunate, but worthy of its own thread if I decide to investigate it some more.  (At least it appears that running "loadmodule-rc  restart" between pipeline runs cleans this problem up.)

    I went back and checked smaller segments of the pipeline.  I started with the very basic:

    gst-launch -v v4l2src always-copy=FALSE input-src=Composite num-buffers=400 ! video/x-raw-yuv, format=\(fourcc\)NV12, width=720, height=480, framerate=30000/1001 ! fakesink silent=true

    This pipeline seems to work repeatedly without problem.  I decided to add in the video encoder before the sink.

    gst-launch -v v4l2src always-copy=FALSE input-src=Composite num-buffers=400 ! video/x-raw-yuv, format=\(fourcc\)NV12, width=720, height=480, framerate=30000/1001 ! TIVidenc1 codecName=mpeg4enc engineName=codecServer contiguousInputFrame=true ! fakesink silent=true

    I ran this pipeline without rebooting.  The first time I ran it, I got the following as it was shutting down:

    Got EOS from element "pipeline0".
    Execution ended after 13396809839 ns.
    Setting pipeline to PAUSED ...
    Setting pipeline to READY ...
    /GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstTIVidenc1:tividenc10.GstPad:src: caps = NULL
    /GstPipeline:pipeline0/GstTIVidenc1:tividenc10.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = NULL
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = NULL
    Setting pipeline to NULL ...
    Freeing pipeline ...
    Caught SIGSEGV accessing address 0x2c
    Spinning.  Please run 'gdb gst-launch 1633' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

    After rebooting, I ran this same pipeline again repeatedly.  On the 2nd - 4th runs I got "Illegal instruction" as it was shutting down:

    Got EOS from element "pipeline0".
    Execution ended after 13404515047 ns.
    Setting pipeline to PAUSED ...
    Setting pipeline to READY ...
    /GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstTIVidenc1:tividenc10.GstPad:src: caps = NULL
    /GstPipeline:pipeline0/GstTIVidenc1:tividenc10.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = NULL
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = NULL
    Setting pipeline to NULL ...
    Freeing pipeline ...
    Illegal instruction

    The 5th run took about 4 times as long (time) to execute as the previous runs, and I also got the "Illegal instruction" message as above.

    On the 6th time, the pipeline never ran, and I got the following:

    gst-launch-0.10: page allocation failure. order:8, mode:0xd0
    Backtrace:
    [<c00305f4>] (dump_backtrace+0x0/0x114) from [<c031b154>] (dump_stack+0x18/0x1c)
     r7:00000008 r6:000000d0 r5:00000000 r4:00000000
    [<c031b13c>] (dump_stack+0x0/0x1c) from [<c007afa4>] (__alloc_pages_nodemask+0x4a0/0x500)
    [<c007ab04>] (__alloc_pages_nodemask+0x0/0x500) from [<c00320d8>] (__dma_alloc+0x160/0x3fc)
    [<c0031f78>] (__dma_alloc+0x0/0x3fc) from [<c0032400>] (dma_alloc_coherent+0x58/0x64)
    [<c00323a8>] (dma_alloc_coherent+0x0/0x64) from [<c02313fc>] (__videobuf_mmap_mapper+0x118/0x224)
     r7:c1194d00 r6:c10dce14 r5:c22ab864 r4:c27b9948
    [<c02312e4>] (__videobuf_mmap_mapper+0x0/0x224) from [<c022f450>] (videobuf_mmap_mapper+0x64/0x94)
     r8:00000000 r7:c1194d00 r6:40aa2000 r5:c27b9948 r4:c10dce14
    [<c022f3ec>] (videobuf_mmap_mapper+0x0/0x94) from [<c0235c60>] (vpfe_mmap+0x48/0x54)
     r5:c27b9948 r4:c10dcc00
    [<c0235c18>] (vpfe_mmap+0x0/0x54) from [<c02254b4>] (v4l2_mmap+0x40/0x4c)
     r5:c27b9948 r4:c1194d00
    [<c0225474>] (v4l2_mmap+0x0/0x4c) from [<c008fb0c>] (mmap_region+0x220/0x42c)
     r5:c27b9948 r4:000000ff
    [<c008f8ec>] (mmap_region+0x0/0x42c) from [<c008ffdc>] (do_mmap_pgoff+0x2c4/0x324)
    [<c008fd18>] (do_mmap_pgoff+0x0/0x324) from [<c0085a58>] (sys_mmap_pgoff+0xa0/0xd0)
    [<c00859b8>] (sys_mmap_pgoff+0x0/0xd0) from [<c002cf40>] (ret_fast_syscall+0x0/0x28)
    Mem-info:
    DMA per-cpu:
    CPU    0: hi:    6, btch:   1 usd:   0
    active_anon:394 inactive_anon:415 isolated_anon:0
     active_file:102 inactive_file:1303 isolated_file:0
     unevictable:0 dirty:0 writeback:0 unstable:0
     free:4096 slab_reclaimable:256 slab_unreclaimable:989
     mapped:574 shmem:34 pagetables:49 bounce:0
    DMA free:16968kB min:880kB low:1100kB high:1320kB active_anon:1580kB inactive_anon:1656kB active_file:348kB inactive_file:4676kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:0kB writeback:0kB mapped:1996kB shmem:136kB slab_reclaimable:1024kB slab_unreclaimable:3956kB kernel_stack:304kB pagetables:196kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
    lowmem_reserve[]: 0 0 0
    DMA: 97*4kB 107*8kB 44*16kB 83*32kB 39*64kB 25*128kB 10*256kB 8*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 16956kB
    1302 total pagecache pages
    12288 pages of RAM
    4316 free pages
    4365 reserved pages
    821 slab pages
    693 pages shared
    0 pages swap cached
    vpfe-capture vpfe-capture: dma_alloc_coherent size 532480 failed

    After rebooting, I decided to see if running with a queue before the video encoder would make a difference.  I started by adding just the queue:

    gst-launch -v v4l2src always-copy=FALSE input-src=Composite num-buffers=400 ! video/x-raw-yuv, format=\(fourcc\)NV12, width=720, height=480, framerate=30000/1001 ! queue ! fakesink silent=true

    On the second run I got the following:

    Got EOS from element "pipeline0".
    Execution ended after 13330272796 ns.
    Setting pipeline to PAUSED ...
    Setting pipeline to READY ...
    /GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = NULL
    /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = NULL
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = NULL
    /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = NULL
    Setting pipeline to NULL ...
    Freeing pipeline ...
    Caught SIGSEGV accessing address 0x401f6d88
    Spinning.  Please run 'gdb gst-launch 1606' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

    I even tried running "loadmodule-rc restart" before the second execution of the pipeline with no effect.

    So, I am satisfied that v4l2src is fine, but I don't know how to proceed with TIVidenc1. I'm even concerned about "queue".

    I worked with pipelines on a dm365 and never had any of these problems. My understanding is that the dm368 shares a lot in common with the dm365, so I am baffled why I'm having so many problems on this board that I didn't have on the other.

    Any more ideas on how to proceed?

    Thanks,

    Doug Linhardt

  • 0 in reply to Doug Linhardt
    Prodigy 140 points

    Everything is working now.  It turns out to be a problem with my bootargs.

    based on this wiki page:

    http://processors.wiki.ti.com/index.php/UG:_DaVinci_PSP_Installation_on_DM36x_EVM

    I tried to add:

    vpfe_capture.bufsize=691200

    to my bootargs. The DVSDK setup script, on the other hand, provides the following:

    vpfe_capture.cont_bufsize=12582912

    By trying to set the .bufsize field, I apparently hosed my environment, and caused the problems that I saw.

    Thanks for the help, Don.

     

    Doug