In GStreamer, we feed just one frame at a time to the decoder.
(h264dec can also work in slice mode, but we don't utilize this.) So
there is no significant buffering on the input side.
OTOH there is a display-delay / re-order queue on the output of the
codec, to deal with B-frames. With h264, depending on the resolution,
the size of the re-order queue can be significant.. IIRC 2 x n where n
is # of reference frames, so for lower resolutions it could be a 32
frame delay.
If you know that there are no B-frames, you can explicitly disable the
re-order queue. I'm not aware of any way to do this through OMX, but
you might want to check out gst-ducati[1] which is using libdce[2] to
access the CE interface directly, which gives you a bit more control
on the a9 side.
[1] http://github.com/robclark/gst-ducati
[2] http://github.com/robclark/libdce
> Also, the "Ducati for Dummies" page reports that codecs are available for
> various formats H264, H263, etc. but I see that in the Ubuntu 10.10,
> GStreamer only the h264 decoder is available. Is it that the other codes are
> NOT available or they are not integrated in Gstreamer?
not all codecs are publicly available, but h263 is handled actually by
the mpeg4 decoder, so it is there..
BR,
-R
oh.. I wonder if you are either still using the original omx firmware
(base_image_appm3.xem) or just haven't loaded the ducati firmare?
That would cause an error at this point.
If you are using ubuntu filesystem, have a look at
/usr/bin/omap-ducati-setup.. and modify it to load dce_app_m3.xem3
instead.
(Then I guess your next problem will be that you don't have encoders
and dce at the same time.. although if someone wants to add encoder
support to libdce and gst-ducati, patches welcome.. actually the
libdce part should be easy, but I've not had time to write encoder
elements in gst-ducati yet)
BR,
-R
syslink_daemon.out Notify_MPUSYS_reroute_Test_Core0.xem3 dce_app_m3.xem3
(or Ipc_MPUSYS_reroute_core0.xem3 instead of
Notify_MPUSYS_reroute_Test_Core0.xem3)
There are a few ways this can go wrong if you the syslink kernel and
userspace parts don't match what the .xem3's were built against. But
the dce_app_m3.xem3 should match what was in the 10.10 release (or at
least 10.10 w/ updates)
BR,
-R
the kernel traces would be useful here.. depending on bootargs, they
might go to UART.. or dmesg cmd would dump them
> can you give an overview on how to build ducati framework and gstreamer
> plugins (versions as well)
all the userspace stuff is pretty standard autotools build setup..
just like compiling some sw on your linux box
ducati side, is a whole different story. Hopefully someone else can
chime in with some help, since I'm a bit short on time at the moment.
Probably the easiest thing to do is use a kernel and userspace
packages that match the dca_app_m3.xem3 firmware, which should match
what is described here:
http://www.omappedia.org/wiki/Ubuntu_OMAP_trunk
(or at least used to as of last Dec-Jan timeframe)
BR,
-R
Is there some file permission issue or something like this? It sounds
like loading ducati firmware did not succeed, so I'd suspect that
nothing further would work..
BR,
-R
do you have the syslink entries in /dev?
e.g.:
crw-rw---- 1 root root 240, 0 Jun 17 00:30 /dev/syslink-proc4430
crw-rw---- 1 root root 241, 0 Jun 17 00:30 /dev/syslink-procmgr
crw-rw---- 1 root root 242, 0 Jun 17 00:30 /dev/syslink_ipc
Well, syslink can be a bit temperamental about mismatches between
version on linux vs ducati side. The current dce_app_m3.xem firmware
was built against 10.10 plus mid-term updates, see:
http://www.omappedia.org/wiki/Ubuntu_OMAP_trunk
I suggest using ubuntu 10.10 plus updates described at above wiki page.
I'm starting to put together instructions on rebuilding dce firmware,
now that public codec libs are available. (On ducati-build branch..
although that is still work in progress.. setting up the build
environment for ducati side is not so straightforward, and it is
something I'm just working on when I have a few free minutes here and
there, so it is a bit slow going.)
BR,
-R
you can't. As I understand it these are TI internal releases that get mentioned on public wikis,
it isn't the first time that happens....
that is correct, ducati OpenMAX is not opensrc.
As far as building (a libdce/gst-ducati) ducati image, I've started
putting together instructions:
http://www.omappedia.org/wiki/DistributedCodecEngine
this is based on GA codec, BIOS, CE, FC, etc, releases, and newer
syslink/tiler compared to 10.10 kernel / 2.6.35, and (currently) the
version of syslink kernel driver that is in 2.6.38 ubuntu/linaro
kernels. But I don't recommend that you look at that yet *unless* you
know what you are doing and want to help (ie. it is still work in
progress).
BR,
-R
I'm not entirely sure this combo will work, due to syslink changes
between 2.6.35 kernel and 2.6.38 kernel.. you'd probably need older
versions of some of the other components to get a matching set, and
these earlier engineering release versions were not all publicly
available.
BR,
-R
>
> On Fri, Jun 17, 2011 at 2:40 AM, B U J J I <sivaits4u@...> wrote:
> >
> > ProcMgr_open Status [0xbabe000]
> > root <at> ubuntu:~/userspace-syslink/syslink/daemons/syslink# ProcMgr_attach
Hi,
I get the same errors too :
I build everyting according to https://github.com/robclark/libdce.
My configuration is as follows :
bios_6_31_03_25
codec_engine_3_20_00_16
framework_components_3_20_02_29
ivahd_h264dec_01_00_00_00_production
ivahd_hdvicp20api_01_00_00_19_production
ivahd_jpegvdec_01_00_00_00_production
ivahd_mpeg2vdec_01_00_00_00_production
TMS470CGT4.6.6
xdctools_3_20_07_86
xdais_7_21_00_02
userspace syslink
ti-syslink-mpu-rls-27.12-p1-27gee7e519
(git://git.omapzoom.org/platform/hardware/ti/tiler.git origin/memmgr_2.0)
userspace tiler
24.7.2-39-ga6dda46
(git://git.omapzoom.org/platform/hardware/ti/syslink.git)
and
kernel-omap4
24.7.2-39-ga6dda46
(git://github.com/robclark/kernel-omap4.git ti-omap4-drm branch)
This error also occurs with kernel 2.6.35-903-omap4.
Was anyone able to resolve this issue? if so, how was it done?
Any insights on what may be cause?
Thank you
Biju
~
syslink_daemon /home/vu/ducati/Notify_MPUSYS_reroute_Test_Core0.xem3
/home/vu/ducati/dce_app_m3.xem3
(note that in syslink v3.0, the xem3 images actually get combined into
a single firmware binary..)
BR,
-R
Install Code Generation Tools (CGT) from:
Install to $HOME/ducati/ti_cgt_tms470_<version>
Download XDC tools from:
XDC tools - 3.20.07.86
Install to $HOME/ducati/xdctools_<version>
Download BIOS (the RTOS) from:
Install to $HOME/ducati/bios_<version>
Download Codec Engine (CE) from:
The lite version is fine. Install to $HOME/ducati/codec_engine_<version>
Download Framework Components (FC) from:
The lite version without fctools is fine. Install to $HOME/ducati/framework_components_<version>
Download XDAIS from:
Untar to $HOME/ducati/xdais_<version>
Install HDCICP2 plus desired codecs from:
export TMS470_C_DIR="$HOME/ducati/ti_cgt_tms470_4_6_1/include;$HOME/ducati/ti_cgt_tms470_4_6_1/lib" export TMS470CGTOOLPATH="$HOME/ducati/ti_cgt_tms470_4_6_1" XDCPATH="" for f in $HOME/ducati/*/packages; do XDCPATH="$XDCPATH$f;" done export XDCPATH export XDCROOT="$HOME/ducati/xdctools_3_20_07_86" export XDCARGS="profile=release"
cd $HOME/ducati git clone git://gitorious.org/bios-syslink/bios-syslink.git cd bios-syslink/packages git checkout 48e98007e21e311c126f89ff51616bf6d7067b9d
diff --git a/packages/config.bld b/packages/config.bld index 01113a1..17e9862 100644 --- a/packages/config.bld +++ b/packages/config.bld @@ -228,6 +228,5 @@ M3.platform = M3.platforms[0]; //Uncomment the require targets Build.targets = [ - C64T, M3, ];
export XDCBUILDCFG="`pwd`/config.bld" $XDCROOT/xdc clean -PR ./ti $XDCROOT/xdc -PR ./ti/sdo ./ti/omap/uart/ ./ti/omap/mem/ ./ti/omap/platform/ ./ti/omap/slpm/ ./ti/omap/deh ./ti/omap/hdmiwa $XDCROOT/xdc -PR ./ti/omap/samples/notify
cd $HOME/ducati git clone git://github.com/robclark/libdce.git cd libdce export XDCBUILDCFG="`pwd`/ducati/build/config.bld" cd ducati/platform/base_image $XDCROOT/xdc -j4 -PD .
$TMS470CGTOOLPATH/bin/strip470 Notify_MPUSYS_reroute_Test_Core0.xem3 $TMS470CGTOOLPATH/bin/strip470 dce_app_m3.xem3
git clone git://git.omapzoom.org/platform/hardware/ti/tiler.git cd tiler git checkout origin/memmgr_2.0 ./bootstrap.sh ./configure --prefix=/usr make -j4 sudo make install
git clone git://git.omapzoom.org/platform/hardware/ti/syslink.git cd syslink/syslink git checkout origin/syslink-2.0 ./bootstrap.sh ./configure --prefix=/usr make -j4 sudo make install
cd libdce ./autogen --prefix=/usr make -j4 sudo make install
how many buffer is gst trying to allocate?
you can get up to 20 1080p buffers from tiler for sure.
please do:
echo 1 > /sys/module/tiler_omap/parameters/alloc_debug
and rerun
> I added the property flags=0x00000067 for playbin2 : It seems that
> when doing so, there is less queuing (not sure, I am not a gstreamer
> expert).
> At least it worked for me ! Just try that way :
> gst-launch-0.10 playbin2 flags=0x00000067 uri=file:///home/work/
> sample.mp4 video-sink=fakesink -v
>
> Regards,
>
> Wolfgar
> PS : If you find how to increase the bufferpool, please share it...
>
no problem.. I think the problem is the wiki was pointing to wrong
kernel branch (there was one linux side kernel patch needed if you
have the above patch) and the branch I was originally pointing to
didn't have it. Sorry 'bout that.
BR,
-R
hmm, yeah, it sounds like there is definitely some sort of leak going on.
fwiw, it might be helpful to visualize the pipeline to see what
elements end up in the pipeline:
http://gstreamer.freedesktop.org/wiki/DumpingPipelineGraphs
in the TI gst packages we had patched playbin2 to pick the
'stridetransform' element instead of ffmpegcolorspace. Possibly
missing that patch causes some issue.
/me looks fwd to gst 0.11/1.0 with proper stride support and not so
many TI patches ;-)
BR,
-R
I'd recommend using the tree's at:
http://gitorious.org/gstreamer-omap
the L24.14 tags should be good
BR,
-R
I'm actually working on a similar solution, using Xbox Media Center, the
experimental gstreamer backend and gst-ducati. Unfortunatly i currently
do not have to much time for this project. Current status is XBMC is
running fine and i started to set up gst-ducati. Please keep us posted
with your progress on getting gst-ducati up and running! It is much
appreciated.
Best regards,
Stephan
>
>
>> BR,
>> -R
>>
>>> I get this error with this command :
>>
>>> gst-launch --gst-debug-no-color --gst-debug=playbin2:4,ducati:4
>>> playbin2
>>> uri=file:///CRYS2multPROPHETSeV70hd.mkv video-sink=fakesink audio-
>>> sink=fakesink
>>
>>> If I add the flags=0x00000067 property, it just works (while
>>> ffmpegcolorspace and videoscale are not used by playbin2 for my
>>> sample)
>>
>>> If I perform the test :
>>
>>> gst-launch --gst-debug=ducati:5 filesrc location=/
>>> CRYS2multPROPHETSeV70hd.mkv ! matroskademux ! nal2bytestream_h264 !
>>> ducatih264dec ! fakesink
>>
>>> It also works great (there are only a few allocations before the
>>> switching to playing state in these 2 later cases)
>>
>>> As a conclusion, I fear that we hit a strange queuing mechanism
>>> related to playbin2 and the tiler allocations are not responsible in
>>> any way for our troubles (Well it is only the symptom but we can
>>> easily understand that the pool runs out of memory after so many
>>> allocations)
>>
>>> Best regards
>>
>>> Wolfgar
>>
yes, only NV12
> After getting errors when I tried to create the codec with another
> format I found the H264_Decoder_HDVICP2_UserGuide and I understood
> that I am out of luck to get another format out of the ducati
> decoder ...
>
> So I will switch to a software conversion from NV12 to I420...
>
> Yet, I have another silly question : gst-ducati advertises caps with
> padded dimensions.
> How the gstreamer video sinks are supposed to extract the useful part
> of the image and to know the "real" dimensions ?
> I thank you for any help...
There is a crop event that is pushed downstream towards the sink
element to tell what are the real dimensions and what part of the
buffer should be displayed
See the GST_EVENT_CROP stuff in v4l2sink (on TI branch) for example
BR,
-R
> Regards,
>
Are you sure you cant teach the downstream element to handle NV12?
Most likely it will touch that data anyway and convert it to RGB or so,
so doing another memory2memory conversion inbetween seems pointless
> ffmpegcolorspace in the pipeline but I fear it would be a inefficient
whatever you do, please do not consider ffmpegcolorspace, despite having
FFmpeg in its name it is slow, pure C code with no assembler
optimization whatsoever..
> If the way I describe is not doable, I will stop trying to use EGL +
> clutter + media explorer and I will try to setup an image based on
> more conventional stuff like enna I think...
and using one of the hardware overlays directly is not an option
at all?
Or do you need to further "transform" the video using the sgx unit?
http://omapedia.org/wiki/V4L2-GFX
bc-cat is a bit old, and was never updated for NV12/tiler buffers on
omap4.. v4l2-gfx accomplishes basically the same thing but is updated
to support the hw codecs on omap4.
BR,
-R
Note that, if you don't need transformational effects on the video,
you could perhaps put the video overlay layer *behind* the fb layer.
I guess there must be some way with some shader tricks to convince GL
to output ARGB with a hole left for video? (It would let you use GL
to implement OSD and that sort of thing, while still using using
overlay for the video layer.)
Not sure if that is harder/easier than v4l2-gfx.. but just throwing an
idea out there.
BR,
-R