When VIDDEC_process() hangs, do you have tracing enabled? If so, does
it also hang when there is no tracing enabled? I'm grasping at straws,
but we've seen several occasions where the servers were built with stack
sizes so close to the edge that even turning on trace will cause them to
overrun their stack and cause a crash.
It seems like the GStreamer distribution has the right memory map (as
Engine_open() succeeds, and even VIDDEC_create() succeeds!). The
loadmodules.sh script you tried has a different memory map, and because
Engine_open() is failing, that makes me think it's incorrect for the
server you're using. So... I think you should stick with the first, and
see if we can find why VIDDEC_process() is crashing.
And for your last comment, when VIDDEC_process() returns -1, it should
also be returning a value in the 'extendedError' field that may provide
further context (maybe something as simple as "unsupported parameter").
These extendedError's are typically codec specific, so you likely would
need the codec data sheets to interpret them further.
Chris
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 10:36 PM
To: Ring, Chris
Cc: davinci-linux-open-source@linux.davincidsp.com;
[EMAIL PROTECTED]
Subject: RE: GStreamer issue on DaVinci board
Hi Chris,
Thanks for your response.
You had suggested us to look into memory mismatch. But in our
case, both the DSP image (the codec servers) and the application
(gdecoder) are from TI. The memory map required for TI's GStreamer
implementation is packaged in their download. Even with that memory map,
however, we were getting an error.
Below are the steps that we have executed:
************************************************************************
************************************************************************
***************************************************
We executed the code using the memory map specified in the TI
GStreamer Plugins files. The script that sets it is as follows
(equivalent to loadmodules.sh in the DVEVM directory):
insmod cmemk.ko phys_start=0x87800000 phys_end=0x88E00000
pools=20x4096,8x202752,10x131072,2x1048576,1x2097152,18x614400
insmod dsplinkk.ko ddr_start=0x8F800000 ddr_size=0x600000
rm -rf /dev/dsplink
mknod /dev/dsplink c `awk "\\$2==\"dsplink\" {print \\$1}"
/proc/devices` 0
We executed this with MPEG4combo.x64p as codec server.
It was not returning from the "VIDDEC_process" API call and on
pressing Ctrl-C, started to pre-roll the pipeline hanging there. On
pressing another Ctrl-C, the system hanged and had to be rebooted.
Now, the original loadmodules.sh script that came with DVEVM has
the following commands:
insmod cmemk.ko phys_start=0x87800000 phys_end=0x88000000
pools=1x3145728,5x829440,1x61440,1x10240
# insert dsplinkk, tell it that DSP's DDR is at physical
250MB-254MB
insmod dsplinkk.ko ddr_start=0x8fa00000 ddr_size=0x400000
rm -f /dev/dsplink
mknod /dev/dsplink c `awk "\\$2==\"dsplink\" {print \\$1}"
/proc/devices` 0
These settings gave the "Process create failure" error, which is
presumably due to memory map mismatch.
************************************************************************
************************************************************************
***************************************************
To make sure for version compatibility we are using released
tested version of GStreamer with DVSDK 1.2
I have tried two different versions of the open source component
of GStreamer - 0.10.11 (which TI has packaged) and 0.10.17 (the latest
from GStreamer website). Both rendered the same results.
One experiment I did has actually provided a different behavior.
I changed the command executed to include a max buffer sizes for queues
(in line with the demo scripts from TI). So the command looks like:
gst-launch-0.10 --gst-debug-level=0 filesrc
location=sample_mpeg4.mpeg4 ! queue max-size-buffers=60 ! gdecoder
Codec=1 ! queue max-size-buffers=180 ! ffmpegcolorspace ! videorate !
video/x-raw-yuv,framerate=10fps ! avimux ! filesink location=sample3.avi
On running this, we do not get the hanging VIDDEC_process
anymore. However, it returns a -1 (without much trace information) so
the decoding fails.
Hope to hear from you.
Regards,
Jitendra
Ext: 864
________________________________
From: Ring, Chris [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 15, 2008 7:14 PM
To: Jain, Jitendra [PROTOOL/RTC/INPU];
davinci-linux-open-source@linux.davincidsp.com; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: GStreamer issue on DaVinci board
http://www.google.com/search?q=0X80008013
<http://www.google.com/search?q=0X80008013>
This is Engine_open() failing - 0x80008013 often indicates a
memory map mismatch between the DSP image and your application.
Chris
________________________________
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, April 15, 2008 4:30 AM
To: davinci-linux-open-source@linux.davincidsp.com;
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: FW: GStreamer issue on DaVinci board
Hello All,
I am getting Process_create failed error messages when
running GStreamer.
I am usjng MPEG4combo.x64p as codec server.
Error messages are:
[EXECUTED COMMAND: gst-launch-0.10 --gst-debug-level=0
filesrc location=sample_mpeg4.mp4 ! gdecoder Codec=1 ! ffmpegcolorspace
! ffenc_wmv2 ! ffmux_asf ! filesink location=sample3.avi]
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
gdecoder: plugin_init BEGIN..
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_base_init BEGIN...
gdecoder: gst_gdecoder_base_init END...
gdecoder: gst_gdecoder_class_init BEGIN...
gdecoder: gst_gdecoder_get_codec_type Begin
gdecoder: gst_gdecoder_get_codec_type End
gdecoder: gst_gdecoder_class_init END...
gdecoder: plugin_init END..
gdecoder: gst_gdecoder_init BEGIN..
gdecoder: gst_gdecoder_reset BEGIN..
gdecoder: gst_gdecoder_reset END..
gdecoder: gst_gdecoder_init END..
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_set_property BEGIN...2..
gdecoder: set ARG_CODEC_NAME property
gdecoder: Codec set to enum value 1
gdecoder: gst_gdecoder_set_property END...
gdecoder: gst_gdecoder_sink_getcaps invoked and call
gst_caps_copy
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_change_state BEGIN..
gdecoder: State Changed from NULL_TO_READY
gdecoder: gst_gdecoder_change_state END..
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_change_state BEGIN..
gdecoder: State Changed from READY_TO_PAUSED
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_sink_activate invoked
gdecoder: STREAMING IS FALSE
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_sink_activate_pull BEGIN..
gdecoder: gst_gdecoder_sink_activate_pull END...
gdecoder: gst_gdecoder_change_state END..
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_loop BEGIN..
gdecoder: gst_gdecoder_process BEGIN....0...
gdecoder: gst_gdecoder_decoder_initialize BEGIN..
gdecoder: gst_gdecoder_open_engine BEGIN..
gdecoder: Opening MPEG4 Engine...
@0x000cf336:[T:0x41a38b60] OP - Process_create_d>
Loading and starting DSP server FAILED, status=[0x80008013]
@0x000cf47d:[T:0x41a38b60] OP - Process_delete_d>
Closing remote transport FAILED, status=0x8000800b.
@0x000cf5c1:[T:0x41a38b60] OP - Process_delete_d>
Stopping DSP FAILED, status=0x8000801b
@0x000cff10:[T:0x41238b60] CE - rserverOpen: can't start
'./MPEG4Combo.x64P'; Process_create failed
gdecoder: Engine_open failed
gdecoder: Engine_open failed
gdecoder: Fatal error, Open_Engine failed
gdecoder: Could Not Initialize Decoder
gdecoder: gst_gdecoder_loop END..
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_loop BEGIN..
gdecoder: gst_gdecoder_process BEGIN....0...
gdecoder: gst_gdecoder_decoder_initialize BEGIN..
gdecoder: gst_gdecoder_open_engine BEGIN..
gdecoder: Opening MPEG4 Engine...
ERROR: from element /pipeline0/gdecoder0: Could not
write to resource.
Additional debug info:
gstgdecoder.c(971): gst_gdecoder_process ():
/pipeline0/gdecoder0:
Could Not Initialize Decoder
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_change_state BEGIN..
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_sink_activate_pull BEGIN..
@0x000e314e:[T:0x41a38b60] OP - Process_create_d>
Loading and starting DSP server FAILED, status=[0x80008013]
@0x000e3268:[T:0x41a38b60] OP - Process_delete_d>
Closing remote transport FAILED, status=0x8000800b.
@0x000e33a7:[T:0x41a38b60] OP - Process_delete_d>
Stopping DSP FAILED, status=0x8000801b
@0x000e3cf0:[T:0x41238b60] CE - rserverOpen: can't start
'./MPEG4Combo.x64P'; Process_create failed
gdecoder: Engine_open failed
gdecoder: Engine_open failed
gdecoder: Fatal error, Open_Engine failed
gdecoder: Could Not Initialize Decoder
gdecoder: gst_gdecoder_loop END..
gdecoder: gst_gdecoder_sink_activate_pull END...
gdecoder: State Changed from PAUSED_TO_READY
gdecoder: gst_gdecoder_change_state END..
gdecoder: gst_gdecoder_get_type Begin
gdecoder: gst_gdecoder_get_type End
gdecoder: gst_gdecoder_change_state BEGIN..
gdecoder: gst_gdecoder_cleanup BEGIN..
Caught SIGSEGV accessing address (nil)
#0 0x402b504c in ?? ()
Spinning. Please run 'gdb gst-launch 1700' to continue
debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
[PRESSED CTRL-C TO INTERRUPT]
Caught interrupt --
If any one of you has got same error kindly help me in
resolving above error.
Waiting for response.
Regards,
Jitendra
Ext: 864
________________________________
From: Jain, Jitendra [PROTOOL/RTC/INPU]
Sent: Monday, April 14, 2008 9:07 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: GStreamer issue on DaVinci board
Hello All,
I am facing issue in GStreamer on DaVinci dm6446 target
board.
Here's what we've done so far:
1. The environment we're using is Fedora Core 5
Linux from Red Hat.
2. GStreamer version we're using is 0.10.17
3. Codec servers we tried were the default that
came with the TI plugins (MPEG4Combo from executable MPEG4Combo.x64P),
decodeCombo (from executable decodeCombo.x64P, mod MPEG4DEC) and
video_copy (from executable video_copy.x64P, mod VIDDEC_COPY). The first
one gives contiguous memory allocation errors (presumably due to memory
map mismatch between the codec servers and the target platform), the
second one hangs and the third one returns error (error code -1 ) for
VIDDEC_Control API call.
4. The sample files we used were some generic MPEG4
files downloaded from the web. The TI supplied data files were huge, so
we thought we'll start with something manageable and small. Also, these
files were decoded successfully using FFMPEG on DaVinci (albeit not
using the TI codecs).
5. The code changes that were made were primarily
configuration changes for building libce (for using different codec
servers) and adding debug statements in the application code file
(gdecoder.c from the ti_plugins directory under ti_build). Experiments
were done to comment out certain parts of the code that were returning
error and substituting with some trial alternatives. Also, we tried
rebuilding cmem upon finding a post from a TI engineer on the DaVinci
blog site that cmem has an issue when allocating contiguous memory
buffers. He had supplied the substitute code too. In fact, this did help
in eliminating the contiguous memory allocation errors we were getting.
We also played with the memory map
Also I am attaching with this mail log of error
messages.
Kindly let us know if anything wrong we have configured
or changes required solving our issue in GStreamer.
Thanking you in advance.
Regards,
Jitendra
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
