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.

Ducati MPEG4 encoder issue

Other Parts Discussed in Thread: AM5728, X5777AXGABC, X5777ATXGABC

Hello Sir,

Configuration Setup:
-----------------------------
1. glsdk_7.04.00.03 
2. gstreamer-1.0 
3. silicon version 1.1 (AM5728)

We are using this AM5728 silicon on our custom board. We have made 5 units of this custom board. 
Currently we have mpeg encoding  issue on one of the board, in all the other 4 it works fine.  On the board where we see a problem, we have observed that the encoder hangs after encoding 5 to 10 frames.
Please find the attached sample application.  This application generates alternate BLACK/ WHITE alternate frames. The encoding and streaming happens fine for BLACK/ WHITE alternate data. If I change this to colored data, then the gstreamer pipeline hangs. 
Only difference that  we noticed was the BLACK/ WHITE encoded data is of size 2.5kBytes/frame, where as for the colored data encoded size results in excess of 100kBytes/frame.
Can't figure out where its going wrong. 
Please Note:
1. The same application with colored data is working fine in all our other 4 boards with same silicon. So no problem with gstreamer pipeline I believe.
2. Also we tried to eliminate the RTP/UDP streaming part, by using fakesink dump =1. We see the same problem exists with fakesink also.
3. The other four boards were procured with version number as X5777AXGABC, however the problematic board has the latest silicon version (which was procured a year later ) with version as  X5777ATXGABC.
Can you please help up us in this regard. We have reached ***-end of the project and this issue has become a show stopper.
Thanks,
Naveen Shetti

6116.GST_Final.c
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#include <gst/gst.h>
#include <gst/app/gstappsrc.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include<gst/video/video.h>
#include <gdk-pixbuf/gdk-pixbuf.h>
uint8_t b_white[645*485*3];
uint8_t b_black[645*485*3];
GST_DEBUG_CATEGORY (appsrc_pipeline_debug);
#define GST_CAT_DEFAULT appsrc_pipeline_debug
typedef struct _App App;
struct _App
{
GstElement *pipeline;
GstElement *appsrc;
GMainLoop *loop;
guint sourceid;
GTimer *timer;
};
App s_app;
static gboolean read_data(App *app) {
static gboolean white = FALSE;
static GstClockTime timestamp = 0;
GstBuffer *buffer;
guint size;
GstFlowReturn ret;
size = 640 * 480 * 3;
buffer = gst_buffer_new_wrapped_full( 0, (gpointer)(white?b_white:b_black), size, 0, size, NULL, NULL );
white = !white;
GST_BUFFER_PTS (buffer) = timestamp;
GST_BUFFER_DURATION (buffer) = gst_util_uint64_scale_int (1, GST_SECOND, 4);
timestamp += GST_BUFFER_DURATION (buffer);
GST_BUFFER_TIMESTAMP(buffer)=timestamp;
g_signal_emit_by_name (app->appsrc, "push-buffer", buffer, &ret);
gst_buffer_unref (buffer);
if (ret != GST_FLOW_OK) {
/* something wrong, stop pushing */
printf("error\n");
// g_main_loop_quit (loop);
}
return TRUE;
}
static void
start_feed (GstElement * pipeline, guint size, App * app)
{
if (app->sourceid == 0) {
GST_DEBUG ("start feeding");
app->sourceid = g_idle_add ((GSourceFunc) read_data, app);
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Naveen,

    I've moved your thread to the device forum.

    Todd
  • Hi Naveen,

    Can you please dump ID registers starting from 0x4AE0 C200 , ending 0x4AE0 C214 (last reg)?

    I'm not sure it is a silicon issue, but be aware that the latest silicon is 2.0 and it's the recommended one for production.

    I also found a similar E2E thread but unfortunately without real solution:

    https://e2e.ti.com/support/arm/sitara_arm/f/791/p/515610/1873843

    Regards,

    Stan


  • If the application is running fine on 4 boards and have consistently problem with one of the board, board design can be a potential culprit too. Have you done thorough DDR mem testing and ruled out that as culprit?  Between black and white and color frame encoding, the encoder will access DDR at higher rate. You can try to reduce the clock speed of  IVA and DDR and see if that causes difference in behavior. 

  • There are multiple board causes that could contribute to the observed failures. Video streaming significantly increases current consumption. I recommend that a 2nd board be outfitted with the newer revision of the silicon. This will help divide the problem. Are you sure that everything else is the same between the boards? Differences in clocks or power supplies or decoupling or SDRAM or power/clock/reset sequencing can cause a function working on one board to fail on another.
    Tom
  • Hello Sir,

    Please find the attached dump of registers from 0x4AE0 C200 , ending 0x4AE0 C214 (last reg).

    Regards

    Naveen Shetti

    Register_dump.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    root@dra7xx-evm:~# devmem2 0x4AE0C200
    /dev/mem opened.
    Memory mapped at address 0x76f4d000.
    Read at address 0x4AE0C200 (0x76f4d200): 0x13008013
    root@dra7xx-evm:~# devmem2 0x4AE0C201
    /dev/mem opened.
    Memory mapped at address 0x76f40000.
    Read at address 0x4AE0C201 (0x76f40200): 0x13008013
    root@dra7xx-evm:~# devmem2 0x4AE0C202
    /dev/mem opened.
    Memory mapped at address 0x76f49000.
    Read at address 0x4AE0C202 (0x76f49200): 0x13008013
    root@dra7xx-evm:~# devmem2 0x4AE0C203
    /dev/mem opened.
    Memory mapped at address 0x76fa6000.
    Read at address 0x4AE0C203 (0x76fa6200): 0x13008013
    root@dra7xx-evm:~# devmem2 0x4AE0C204
    /dev/mem opened.
    Memory mapped at address 0x76fa3000.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hello Madam,

    This board is exact replica of other 4 boards. When we run our actual application which is related to different Signal Processing algorithms on Processor (on ARM + 2 DSP's), HMI, Display and with frequent communication with FPGA over GPMC -- on this faulty board it works absolutely fine without any issues. We have tested the application for hours and it works fine.

    Only when we enable encoding, we have seen the encoder hanging.

    As suggested by you, we may not be able to to outfit Silicon2.0 on this Unit, since its already delivered as complete unit to customer with ATP done for all functionalities minus the encoding. However we would like to re-verify the clocks, power supplies, SDRAM once again to rule out any inconsistencies.

    Will keep you posted.
  • We have two boards with processor top marking as “X5777ATXGABC” for silicon 1.1 versions :

    Board 1 (spare card - not used for production) :
    G-streamer works properly

    Board 2:
    Issue in G-streamer:
    1. Black and White pattern encoding test is working fine
    2. But colour pattern encoding test gets hanged within few seconds.
  • Naveen,

    Is this a separate issue or the same one as before?  If same as before, have you now been able to reproduce the same failure on an SR1.1 board that previously you only saw on the SR2.0 board?  If so, what are you now doing differently?

    Tom