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.
Hi Eric,
Unfortunately, GStreamer port is not part of the official DVSDK software release and hence it does not get updated or tested with every DVSDK release (although I agree this would be nice); it was ported to DVSDK 1.20 and offered as a potential solution for our customer base to consider (better than not offering any such solution at all). Unfortunately, this means that the customer should take this solution (based on DVSDK 1.20) as-is and make any necessary adjustments (e.g. port to DVSDK 1.30) themselves.
My recommendation would be to go back to DVSDK 1.2 and test with that and start slowly porting to DVSDK 1.30. I believe the Linux drivers are quite different, hence this is a potential place to start debugging (or comparing DVSDK releases).
Juan,
I agree with your statement that it would be nice. As a potential volume customer of devinci components, this is more than just an annoyance though.
What is the officially sanctioned TI demux package? What are most customers doing about this? This seems like such an essential piece of any media decoder that it would be under the TI/Montavista development and support window. Do you know if there is any plans to make it so? Having such a widely used, and apparently essential, package break because an underlying API was changed seems like a fatal flaw in the release process and highlights the problem with Open Source that the business unit managers lose sleep over. Is there a TI plan to both help fix the Davinci G-Streamer, to pull it (or an equivalent package) under the Montavista umbrella, and then to better control releases that affect existing APIs so something like this will not happen again, or is this just an accepted part of the Linux world?
There are a few third parties that may be able to help with Gstreamer port for a fee. Z3 technoligies (the host of this project under GIT) is probably a good starting point. Please understand that this is an open source community supported project.
We at TI certainly are certainly interested in this type of feedback from our customers. we are not a software house, but do understand the importance of software and do our best to engage our 3rd party network to meet those needs; however, we are always glad to receive feedback from customers to help us plan for better customer experience in the future.
Thanks Juan, I have contacted Z3Technology and am in the process of contacting several other s in the TI ecosystem as well. The few that do this, appear to have very expensive proprietary demux framework solutions. I will also have someone look closer to see if we could get the Gstreamer to work with the new APIs, or like your earlier suggestion, go back a level for now.
If any other member of this forum has a suggestion for both a short-term tactical proof-of-concept solution that would allow us to to demo a MP4 or AVI as well as a longer term production solution, please leave a post or contact me. ... thanks
I am trying to run video files using gstreamer-ti for
da-vinci. But i always encounter problem of VIDDEC_proces returing
value of -1 saying the XDM_CORRUPTED DATA and XDM_UNSUPPORTEDPARAM.
The Media files is avi format which contains mpeg4 video and
mp3 audio files. The command i use ./test_AVI.sh ./<media>.avi command
as in the Readme.txt .
So i am asking the following questions
1) Is there any dependies on demuxers for
seperating audio and video.
2) What does XDM_CORRUPTEDDATA means ? and how does
the codec check the condtion ?
I take it you are using either DVSDK 1.20 or have appropriately ported to DVSDK 1.30; if so, then the next thing I would check in to make sure the DSP codec server I am using with GStreamer supports the MPEG4 video and MP3 audio. I believe by default, the DVSDK DSP codec server supports AAC audio and not MP3 (but I am not familiar enough with GStreamer port to know if there is a separate DSP codec Server for it), hence this is a place to start looking.
I am also encountering porting issues with gstreamer and DVSDK 1.3. Are there any solutions at this point or should I go back to DVSDK 1.2?
Thanks
Hi all,
I have been too busy to keep an eye on this thread and provide some more info :(
Juan and all, there is a new gstreamer project for support most Davinci and OMAP parts that's is being developed by TI and RidgeRun and supported commercially by RidgeRun. Even if you don't need the commercial support, the project is a lot more alive than the other previous gstreamer ports and has more capabilities and way better performance. The releases are being formally tested by TI and RidgeRun with latest DVSDKs and for bugs or issues there is bug tracker and IRC channel available.
The project is not official yet (meaning it hasn't been officially presented), but will save you guys some pain. Please visit gstreamer.ti.com
Regards,
Diego Dompe
RidgeRun Engineering
Diego,
Thank you for the update; we have been aware (and have suggested an upcoming new and improved gstreamer in some posts), but were waiting for the official launch. From everything I have heard, this version should be much more robust and better quality as it was developed from the ground up with detail to software arcchitecture and compatibility with codec engine roadmap, as opposed to quick ports that are only compatiable with one DVSDK version (as we have seen with many gstreamer ports in the past). I am really excited to have this solution for our customers
Hi everyone .
I download the gst-ti-plugin-full-0.99.00.tar.gz from https://gstreamer.ti.com.
But when I compile the ti_build , the compile failed with the following
errors:
----------------------------------------------------------------------------
libtool: link: link -dump -symbols
.libs/libgstticodecplugin_la-gstticodecplugin.o
.libs/libgstticodecplugin_la-gsttiauddec.o
.libs/libgstticodecplugin_la-gsttiauddec1.o
.libs/libgstticodecplugin_la-gsttividdec.o
.libs/libgstticodecplugin_la-gsttividdec2.o
.libs/libgstticodecplugin_la-gsttiimgenc1.o
.libs/libgstticodecplugin_la-gsttiimgdec1.o
.libs/libgstticodecplugin_la-gsttidmaibuffertransport.o
.libs/libgstticodecplugin_la-gstticircbuffer.o
.libs/libgstticodecplugin_la-gsttidmaivideosink.o
.libs/libgstticodecplugin_la-gstticodecs.o
.libs/libgstticodecplugin_la-gstticodecs_platform.o
.libs/libgstticodecplugin_la-gsttiquicktime_aac.o
.libs/libgstticodecplugin_la-gsttiquicktime_h264.o | | /bin/sed 's/.* //' |
sort | uniq > .libs/libgstticodecplugin.exp
../libtool: eval: line 798: syntax error near unexpected token `|'
../libtool: eval: line 798: `link -dump -symbols
.libs/libgstticodecplugin_la-gstticodecplugin.o
.libs/libgstticodecplugin_la-gsttiauddec.o
.libs/libgstticodecplugin_la-gsttiauddec1.o
.libs/libgstticodecplugin_la-gsttividdec.o
.libs/libgstticodecplugin_la-gsttividdec2.o
.libs/libgstticodecplugin_la-gsttiimgenc1.o
.libs/libgstticodecplugin_la-gsttiimgdec1.o
.libs/libgstticodecplugin_la-gsttidmaibuffertransport.o
.libs/libgstticodecplugin_la-gstticircbuffer.o
.libs/libgstticodecplugin_la-gsttidmaivideosink.o
.libs/libgstticodecplugin_la-gstticodecs.o
.libs/libgstticodecplugin_la-gstticodecs_platform.o
.libs/libgstticodecplugin_la-gsttiquicktime_aac.o
.libs/libgstticodecplugin_la-gsttiquicktime_h264.o | | /bin/sed 's/.* //' |
sort | uniq > .libs/libgstticodecplugin.exp'
make[5]: *** [libgstticodecplugin.la] Error 1
make[4]: *** [all] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [ticodecplugin] Error 2
make: *** [ti_build] Error 2
-----------------------------------------------------------------------------
My board is DM355 EVM from spectrum.
The following is my dvsdk version:
dvsdk_1_30_01_41
bios_5_31_08
biosutils_1_00_02
dsplink_140-05p1
codec_engine_2_00_01
biosutils_1_00_02
cmem_2_00_01
framework_components_2_00_01
dm355_codecs_1_12_003
xdais_6_00_01
xdc_3_00_06
dmai_1_16_00_03
The MVL version is 4.0.1.
Thanks and regards,
ddompe said:Hi all,
I have been too busy to keep an eye on this thread and provide some more info :(
Juan and all, there is a new gstreamer project for support most Davinci and OMAP parts that's is being developed by TI and RidgeRun and supported commercially by RidgeRun. Even if you don't need the commercial support, the project is a lot more alive than the other previous gstreamer ports and has more capabilities and way better performance. The releases are being formally tested by TI and RidgeRun with latest DVSDKs and for bugs or issues there is bug tracker and IRC channel available.
The project is not official yet (meaning it hasn't been officially presented), but will save you guys some pain. Please visit gstreamer.ti.com
Regards,
Diego Dompe
RidgeRun Engineering
I believe this port will be supported by the open source community, with additional services provided by RidgeRun for a fee. I noticed there is a forum section at https://gstreamer.ti.com; have you tried posting there? I notice there is nothing there yet, but this is likely because this project has not been officially annouced yet.
The gstreamer.ti.com was announced on the Davinci open source list (and probably elsewhere as well) last Friday.
Chase Maupin said:
All,
GStreamer is an open-source multimedia pipeline engine. TI is pleased to announce that we have created a plugin for GStreamer that contains several elements to enable the use of TI hardware with GStreamer. This includes elements to use the DSP or other hardware accelerators to encode and decode audio, video, and images. This is a base port to enable developers to use GStreamer on their embedded devices to allow for a more multimedia rich offering. The code has been designed to be highly portable between TI processors. We currently support the following processors:
- DM644x
- DM355
- DM6467
- OMAP3
On those processors we support playback of elementary streams as well as transport streams, AVI files, and mp4 streams. As new processors are released we are adding their support to the GStreamer implementation.
We have partnered with RidgeRun for support. The support model is that customers can use open-source resources to solve problems but if they need more detailed help, custom features, or help in productizing their offering they can buy a support contract from RidgeRun.
The project is hosted on a GForge server at
http://gstreamer.ti.com. There is an initial 0.99.00 release available at that site which will support decoding of audio, video, and images as well as the encoding of images. Support for encoding of audio and video is in the development trunk of the repository but has not yet been fully tested. For more information on this project please visit http://gstreamer.ti.com
What's coming:
1. Support for DM357
2. Support beagleboard (using Arago/OpenEmbedded) 3. New release with tested audio/video encoders
Sincerely,
Chase Maupin
This being said, in addition to the forums on the gstreamer.ti.com site you may want to try the Davinci Linux Open Source List.
I solved this problem.
I found that libtool 1.5.8 works well , but libtool 2.2.2 and later will pops the error message.
So , I installl libtool 1.5.8 on my host machine , and compile the ti_build successfully.
yangsb said:Hi everyone .
I download the gst-ti-plugin-full-0.99.00.tar.gz from https://gstreamer.ti.com.
But when I compile the ti_build , the compile failed with the following
errors:Hi all,
I have been too busy to keep an eye on this thread and provide some more info :(
Juan and all, there is a new gstreamer project for support most Davinci and OMAP parts that's is being developed by TI and RidgeRun and supported commercially by RidgeRun. Even if you don't need the commercial support, the project is a lot more alive than the other previous gstreamer ports and has more capabilities and way better performance. The releases are being formally tested by TI and RidgeRun with latest DVSDKs and for bugs or issues there is bug tracker and IRC channel available.
The project is not official yet (meaning it hasn't been officially presented), but will save you guys some pain. Please visit gstreamer.ti.com
Regards,
Diego Dompe
RidgeRun Engineering
[/quote]
When I finished compiling the gstreamer project , I tried to run the demo on my EVM.
First , I run ./loadmodules.sh
Second , I run the decode_avi.sh : ./decode_avi.sh -f star.avi
The gstreamer failed with the following errors:
-----------------------------------------------------------------------------------------------------------------
gst-inspect TIViddec2
(gst-inspect-0.10:1105): GStreamer-WARNING **: Failed to load plugin '/opt/gstr
eamer/lib/gstreamer-0.10/libgstticodecplugin.so': /opt/gstreamer/lib/gstreamer-
0.10/libgstticodecplugin.so: undefined symbol: MP4VENC_TI_IMP4VENC
ERROR: Failed to execute 'gst-inspect TIViddec2'
------------------------------------------------------------------------------------------------------------------
Anyone could give me some advice ?
Best regards
If you are running gst on DM6446 (DVSDK 1.30) then you should be using TIViddec not TIViddec2. Refer readme.txt for element name and its corresponding xDM version. e.g TIViddec is for xDM 0.9 codec (which is inlcuded in DVSDK 1.3 - dm6446).
Thanks - Brijesh Singh
Hi Brijesh,
Even I am running the encode_elementary.sh from the gst release version 1.00 & getting following errors.
I have DVSDK version : dvsdk_1_40_00_28 & Platform : DM6467
/opt/gstreamer_demo/dm6467# ./encode_elementry.sh -f D1_720x480_Tractor_420P.yuv -o out.264 -v
gst-inspect filesrc
gst-inspect TIVidenc1
*********** Pipeline Settings *************
platform = dm6467
source = filesrc
source_args = location=D1_720x480_Tractor_420P.yuv
encoder_plugin = TIVidenc1
encoder_plugin_args = codecName=h264enc engineName=encode contiguousInputFrame=FALSE iColorSpace=Y8C8 resolution=720x480 contiguousInputFrame=FALSE
gst-launch --gst-debug-no-color --gst-debug=TI*:2 filesrc location=D1_720x480_Tractor_420P.yuv ! TIVidenc1 codecName=h264enc engineName=encode contiguousInputFrame=FALSE iColorSpace=Y8C8 resolution=720x480 contiguousInputFrame=FALSE ! filesink location=out.264
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
0:00:00.467631677 1205 0x81f70 WARN TIVidenc1 gsttividenc1.c:1695:gst_tividenc1_frame_duration: framerate not specified; using 29.97fps
0:00:00.878941246 1205 0x81f70 ERROR TIVidenc1 gsttividenc1.c:1422:gst_tividenc1_encode_thread: Failed to execute CCV job
0:00:00.879788808 1205 0x81f70 ERROR TICircBuffer gstticircbuffer.c:492:gst_ticircbuffer_data_consumed: when circular buffer is created with fixedBlockSize=TRUE consumers must always consume an entire window at a time
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 6639912 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...
Your help would be greatly appreciated.
Thanks,
Manoj