Hello,
I am trying to track down a problem using the TIVidenc1 Gstreamer plug-in to encode video on a custom-designed board with a DM368. The symptoms are that the video codec does not generate any output (and the pipeline stalls). The exact same software (identical binary image) runs fine on a DM368 LeopardBoard so I suspect either a software configuration problem (DDR2 controller settings, etc.) or a hardware problem. Also, the pipeline does sometimes run successfully on the custom hardware, although this is rare (maybe one time in ten or twenty attempts). Can anyone suggest any further ideas to help diagnose the root cause of the problem?
Software is the TI DV SDK v4.02.00.00 with the standard codecs.
Here is the pipeline I'm using as a test case, with sample output when it stalls:
DMAI_DEBUG=2 gst-launch -e videotestsrc ! 'video/x-raw-yuv, format=(fourcc)NV12, width=720, height=576, framerate=(fraction)25/1' ! dmaiperf ! TIVidenc1 engineName=codecServer codecName=mpeg2enc encodingPreset=3 ! fakesink silent=true
@0x00064b46:[T:0x400205c0] ti.sdo.dmai - [Dmai] Dmai log level set to '2'. Note that calling CERuntime_init after this point may cause unexpected change to DMAI tracing behavior.
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPipeline:pipeline0/GstDmaiperf:dmaiperf0: There is no codec present that can handle the stream's type.
Additional debug info: gsttidmaiperf.c(285): gst_dmaiperf_start (): /GstPipeline:pipeline0/GstDmaiperf:dmaiperf0: Engine name not specified, not printing DSP information
@0x00169879:[T:0x41105490] ti.sdo.dmai - [Venc1] Creating encoder mpeg2enc for max 720x576 bitrate 2000000 ratectrl 4
INFO: Timestamp: 0:10:11.448349935; bps: 0; fps: 0;
@0x00177469:[T:0x41105490] ti.sdo.dmai - [Venc1] Setting dynParams size 720x576 bitrate 2000000
@0x00177768:[T:0x41105490] ti.sdo.dmai - [Venc1] Made XDM_SETPARAMS control call
@0x00177ac3:[T:0x41105490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 622080 at 0x41556000 (0x84fa5000 phys)
@0x00177d72:[T:0x41105490] ti.sdo.dmai - [Buffer] Alloc Buffer of size 1536000 at 0x415ee000 (0x8503d000 phys)
[...hangs here...]
Although this is encoding SD video with the MPEG-2 codec, I see exactly the same behaviour with HD video and either MPEG-4 or H.264 codecs. I've done most of the investigative work using the H.264 codec as that's the end goal for this application.
By comparing trace output with the working pipeline I believe the codec is stalling within the VIDENC1_process() routine.
If I interrupt the pipeline and run it again, I see the same behaviour. In this case, the CPU is fully loaded and oprofile shows all the time is being spent in a routine waiting for completion of a DMA transfer - specifically, H264V_TI_DMA_Wait() when using the H.264 codec. By dumping the EDMA registers it looks as though there may be an outstanding transfer where both the source and destination addresses are within the HDVICP DMA port address range (although I have not looked at this in great detail).
Since the pipeline is not using any external video capture hardware, I have focused on behaviour of the external SDRAM as a possible reason for the stall. I have checked that the DDR2 controller configuration is correct, and have modified the UBL to run the SDRAM with slacker timing but this makes no apparent difference. I have also been able to run successfully the edma_test module provided with the SDK (although I'm not convinced that's a very aggressive test).
There are obviously some hardware differences between this custom board and the DM368 LeopardBoard used as a reference, but as I mentioned above, the boards are similar enough to run identical software builds. I have since modified the UBL, U-Boot and Linux kernel builds for the custom hardware to ensure that the pin multiplexing and GPIO configuration exactly suits the custom hardware, but again this has not affected the behaviour of the video encode pipeline.
Fundamentally, given that the video encoder and DMA controller hardware are all on-chip, it's hard to think of many differences between the two boards that could cause the observed behaviour. Apart from the external memory timing, and i/o pin configuration, the only other things I can think of are power supply stability and sequencing. Could problems in that area affect the HDVICP/MJCP or EDMA in this way?
To summarise, I'd be very grateful if anyone can suggest either:
- hardware differences that might cause the video encoder to stall
- software configuration differences (other than those mentioned) that might cause the video encoder to stall
- methods to track down the source of the problem
Thanks,
Ian
