logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.

gstreamer framework 3.4 problem

Sunday, September 16 2012, 06:32 PM
ttump
ttump
Offline
0
I have made and loaded the beta release of framework 3.4 but when I run load-modules.sh dmesg gives the following


[ 90.890869] CMEM Range Overlaps Kernel Physical - allowing overlap
[ 90.897338] CMEM phys_start (0x84000000) overlaps kernel (0x80000000 -> 0x98900000)
[ 90.906311] allocated heap buffer 0xe5000000 of size 0xb12000
[ 90.912628] cmemk initialized
[ 90.958221] DSPLINK Module (1.65.01.06) created on Date: Sep 13 2012 Time: 09:43:25
[ 91.042144] SDMAK module: built on Sep 13 2012 at 09:44:48
[ 91.047882] Reference Linux version 2.6.37
[ 91.052337] File /home/jdoe/igep-dsp-gst-framework-3_40_00/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/sdma/src/module/sdmak.c

And if I try to run a gstreamer pipeline it appears to start running but doesn't work and I get the following dmesg


[ 261.711364] Unable to handle kernel paging request at virtual address e086300c
[ 261.718902] pgd = dc344000
[ 261.721710] [e086300c] *pgd=9c9b9011, *pte=00000000, *ppte=00000000
[ 261.728240] Internal error: Oops: 807 [#1]
[ 261.732482] last sysfs file: /sys/devices/platform/omapdss/overlay1/enabled
[ 261.739746] Modules linked in: sdmak lpm_omap3530 dsplinkk cmemk ip_tables rfcomm hidp l2cap bluetooth libertas_sdio mcp251x libertas option twl4030_wdt can_dev spidev ads7846 omap_wdt usb_wwan usbserial
[ 261.758605] CPU: 0 Not tainted (2.6.37 #1)
[ 261.763244] PC is at remove_wait_queue+0x10/0x38
[ 261.768157] LR is at SYNC_WaitSEM+0x1b8/0x1f4 [dsplinkk]
[ 261.773681] pc : [] lr : [] psr: 20000093
[ 261.773712] sp : dca21e60 ip : dca98044 fp : 00000000
[ 261.785644] r10: 80008051 r9 : 80040800 r8 : bf10c318
[ 261.791076] r7 : 00000001 r6 : e0863008 r5 : fffffe00 r4 : e0863000
[ 261.797851] r3 : 20000013 r2 : e0863008 r1 : dca21e64 r0 : e0863008
[ 261.804656] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 261.812164] Control: 10c5387d Table: 9c344019 DAC: 00000015
[ 261.818145] Process videotestsrc0:s (pid: 1530, stack limit = 0xdca202f0)
[ 261.825195] Stack: (0xdca21e60 to 0xdca22000)
[ 261.829742] 1e60: e1e7d500 00000001 dc998880 c0065ee0 e0863008 e0863008 ffffffff 00008000
[ 261.838226] 1e80: dca21efc e085d000 bf10c318 bf0fc2c0 00000029 4131a8ec c018e03a c018e03a
[ 261.846740] 1ea0: 00000007 00000000 dca20000 00000000 4131a8d4 bf108414 dd25d800 00000001
[ 261.855255] 1ec0: c065b88c dc86e540 dd25d800 c065b368 00000008 c0386444 dc86e540 5007e9a8
[ 261.863769] 1ee0: 01cc89fd 00008000 454823a8 00010001 ffffffff 00000000 40318b48 00000000
[ 261.872283] 1f00: ffffffff 4131a8ec db4a4d40 c018e03a 00000007 00000000 00000000 c00d2654
[ 261.880798] 1f20: c05e7018 dca20000 dca21fac c04578b4 ffffecfa c0386d74 c0386d18 00000001
[ 261.889312] 1f40: 0000000c dca20000 c0641704 00000100 0000000a c06416c0 00000100 c006ecec
[ 261.897827] 1f60: db4a4d40 db4a4d40 4131a8ec c018e03a 00000007 00000000 dca20000 00000000
[ 261.906311] 1f80: 4131a8d4 c00d2710 00000007 00000001 40318b48 ffffffff 4131a98c 00000036
[ 261.914825] 1fa0: c0042c04 c0042a80 40318b48 ffffffff 00000007 c018e03a 4131a8ec 00000007
[ 261.923339] 1fc0: 40318b48 ffffffff 4131a98c 00000036 00010001 00002690 4031a0cc 4131a8d4
[ 261.931854] 1fe0: 4031b1d8 4131a7c8 402cc96c 453ee58c 80000010 00000007 00000000 00000000
[ 261.940429] [] (remove_wait_queue+0x10/0x38) from [] (SYNC_WaitSEM+0x1b8/0x1f4 [dsplinkk])
[ 261.950927] [] (SYNC_WaitSEM+0x1b8/0x1f4 [dsplinkk]) from [] (LDRV_MSGQ_get+0x84/0xc0 [dsplinkk])
[ 261.962066] [] (LDRV_MSGQ_get+0x84/0xc0 [dsplinkk]) from [] (DRV_Ioctl+0x1c0/0x76c [dsplinkk])
[ 261.972869] [] (DRV_Ioctl+0x1c0/0x76c [dsplinkk]) from [] (do_vfs_ioctl+0x4a4/0x514)
[ 261.982757] [] (do_vfs_ioctl+0x4a4/0x514) from [] (sys_ioctl+0x4c/0x6c)
[ 261.991455] [] (sys_ioctl+0x4c/0x6c) from [] (ret_fast_syscall+0x0/0x30)
[ 262.000244] Code: e10f3000 f10c0080 e5912010 e591000c (e5802004) 
[ 262.007812] ---[ end trace ac39f48a34c00062 ]---


The boot igep.ini is the standard file as included in the framework.

Any help appreciated.

Thanks Tony

Accepted Answer

ttump
ttump
Offline
Wednesday, September 26 2012, 03:28 PM - #permalink
0
Hi Manel,

I used ffmpegcolorspace because my video source is a webcam outputting YUY2 format which the TI encoder doesn't support. I only used this to test the pipeline. ffmpegcolorspace uses lots of CPU and is not practical for use in a real application so I have hacked the source code of TIVidenc1 to shift the buffer by one byte so that the stream looks like UYVY which is supported by the encoder. However I am using the standard TIVidenc1 while I try to get the 3.4 framework working.

I have used queue in the pipeline but removed it to eliminate possible causes of the problem. I have also tested with TIPrepEncBuf.

I realise that the stream is H264. My video player looks at the file content to determine its type. I used the mp4 file extension so that my linux gui displays it with a sensible icon. I have tried the pipeline with sample.h264 just to be sure.

As I mentioned earlier the pipeline work OK with the previous gstreamer framework.

Mika,

Thanks for your information, I started looking at the TI links but I'm still trying to work out what needs to be changed. Hopefully it will solve my problem.

Regards,

Tony
The reply is currently minimized Show
Responses (15)
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Monday, September 17 2012, 03:03 PM - #permalink
    0
    Hi Tony Could you provide your gstreamer pipeline ? Manel
    The reply is currently minimized Show
  • Accepted Answer

    ttump
    ttump
    Offline
    Monday, September 17 2012, 03:52 PM - #permalink
    0
    Manel,

    One of the pipelines is.

    gst-launch -v v4l2src device=/dev/video0 ! video/x-raw-yuv, width=320, height=240, framerate=\(fraction\)30/1 ! ffmpegcolorspace ! video/x-raw-yuv, format=\(fourcc\)UYVY ! TIVidenc1 codecName=h264enc engineName=codecServer ! filesink location=sample.mp4


    But I've also tried just putting the videotestsrc straight through to the TI encoder

    The pipelines work OK in the previous framework.

    Thanks,

    Tony
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Monday, September 17 2012, 06:01 PM - #permalink
    0
    Did you use Control+C to stop it? Manel
    The reply is currently minimized Show
  • Accepted Answer

    ttump
    ttump
    Offline
    Monday, September 17 2012, 07:00 PM - #permalink
    0
    Yes Tony
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, September 18 2012, 10:55 AM - #permalink
    0
    Hi Tony, This kernel crash is related to the Control+C ... we replaced the old dsplink for the dsplink without any modification ... So execute the pipeline again and export the variable CE_DEBUG=3 before execute it and post the output ... Manel
    The reply is currently minimized Show
  • Accepted Answer

    ttump
    ttump
    Offline
    Tuesday, September 18 2012, 08:35 PM - #permalink
    0
    Manel Log file attached. Pipeline is running but the file produced is not a valid format that I can play. I haven't had a chance to inspect it further. Thanks, Tony
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, September 18 2012, 08:52 PM - #permalink
    0
    Hi Tony, Yes I saw the error from your log file:
    @3,411,041us: [+7 T:0x414b2470 S:0x414b178c] OM - Memory_getVirtualAddress> Error: buffer (physAddr=0x85ca0a75, size=0x1a9a0) not found in translationcache Ensure that you have registered this buffer with Memory_registerContigBuf()
    let me take a look tomorrow morning at office ... or if you can please execute: gst-inspect TIVidenc1 I don't remember if it has any parameter about contiguous buffers ... and how is the default value ... DSP input buffers always must be contiguous and aligned ... Cheers Manel
    The reply is currently minimized Show
  • Accepted Answer

    ttump
    ttump
    Offline
    Thursday, September 20 2012, 03:33 PM - #permalink
    0
    Hi Manel I looked at gst-inspect TIVidenc1 but I couldn't see anything in the listing that helped. Have you had a chance to look at the problem? Thanks, Tony
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Thursday, September 20 2012, 04:37 PM - #permalink
    0
    Hi Tony, yes, I check it ... try add this parameter: contiguousInputFrame=TRUE TIVidenc1 codecName=h264enc engineName=codecServer contiguousInputFrame=TRUE Manel
    The reply is currently minimized Show
  • Accepted Answer

    ttump
    ttump
    Offline
    Thursday, September 20 2012, 07:58 PM - #permalink
    0
    Hi Manel I've run the pipeline with contiguousInputFrame=TRUE but I get the same errors. New log file attached Tony
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Thursday, September 20 2012, 08:12 PM - #permalink
    0
    Hi Tony, Please try to use TIPrepEncBuf element before TIVidenc1 to properly prepare your input buffer for encoding ... Manel
    The reply is currently minimized Show
  • Accepted Answer

    ttump
    ttump
    Offline
    Friday, September 21 2012, 10:47 AM - #permalink
    0
    Hi Manel, I have tried using TIPrepEncBuf with ContiguousInputFrame set as False and True but it doesn't seem to have made a difference. Latest Log attached (above flag True) Thanks, Tony
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Friday, September 21 2012, 11:00 AM - #permalink
    0
    Hi Tony, Ok, let me check ... Manel
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Monday, September 24 2012, 04:45 PM - #permalink
    0
    Hi Tony, This is the pipeline that I used:
    gst-launch videotestsrc ! queue ! tee name=t ! tidisplaysink2 device=/dev/video2 display-output=LCD video-standard=720P overlay-top=300 t. ! TIPrepEncBuf numOutputBufs=3 ! queue ! TIVidenc1 engineName=codecServer codecName=h264enc resolution=320x240 contiguousInputFrame=true ! avimux ! filesink location=test.avi
    And it works for my, I play the videotestsrc in the monitor and generate the test.avi file with it ... So, I've some questions/comments about your pipeline:
    gst-launch -v v4l2src device=/dev/video0 ! video/x-raw-yuv, width=320, height=240, framerate=\(fraction\)30/1 ! ffmpegcolorspace ! video/x-raw-yuv, format=\(fourcc\)UYVY ! TIVidenc1 codecName=h264enc engineName=codecServer ! filesink location=sample.mp4
    The first thing relate to it is about the use of ffmpegcolorspace, why you use it? maybe the UVVY it's not right ? due TIVidenc1 uses yuv ... The second thing it's about the queue element, it should be used before the encoder ... and TIPrepEncBuf help to get the memory in a contiguous frames ... The third thing it's related to mp4 file format, the TIVidenc1 not generate this format directly, I mean it generate only the h264 stream and you should package inside a video container such avi, mp4 .... using avimux or qtmux ... The latest thing it's related to this issue:
    @3,411,041us: [+7 T:0x414b2470 S:0x414b178c] OM - Memory_getVirtualAddress> Error: buffer (physAddr=0x85ca0a75, size=0x1a9a0) not found in translationcache Ensure that you have registered this buffer with Memory_registerContigBuf()
    I'm looking the source problem and appears that it come from the integration between dmai and codec engine but unfortunately I don't found the exact issue location ... I guess in the ti forum talks about this issue ... Cheers Manel
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 26 2012, 11:57 AM - #permalink
    0
    Hi Tony,

    When you use TIVidenc1 with filesink after, like said manel, you only have a h264 video stream in your file.
    But h264 "pure" video stream can't be decode directly without NALU information . Try to set byteStream = true for TIVidenc1 parameters to generate Header in a encoded h264 frame and save it in a .h264 file (not a mp4). It may work this way with vlc player.

    the error seen in the dmesg can be corrected following this link (Last post) : http://e2e.ti.com/support/dsp/omap_appl ... spx#741742

    It is due to the sigsev signal handled by gsteamer/codecEngine/dsplink.

    Hope it help

    Mika
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat