DM816x EVM Interlaced video field order

Hi,

Mostly it is problem with display. 1080i-60 display had a problem with HDVPSS and PSP releases. This will be solved in next release. Can you modify your chain to display 1080i-60 as 1080P30 combining both fields. This is to make sure that issue is with display and not decoder.

Regards,

Hardik Shah

The latest gstreamer release now has de-interlacer element available. You should be able to use that to handle interlace content, if you want to avoid 1080I display.

Thanks,

Satish

Satish,

Thanks for the response.  I did build and install gst-openmax-GST_DM81XX_00_04_00_00 and am running through omx_hdeiscaler and do have what appears to be a properly deinterlaced/progressive full frame output, however, the video appears to stall after only a few frames of output (i.e. freeze after a few frames).

gst-launch -v filesrc location=/home/root/TESTH264.mpg ! mpegtsdemux ! h264parse output-format=1 access-unit=true ! omx_h264dec ! omx_hdeiscaler ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! omx_scaler ! omx_videosink display-mode=OMX_DC_MODE_1080P_60

Any suggestions?

Thanks in advance,

Tate

Nevermind.  Found my own answer...  Need to pipe BOTH outputs (src_00 & src_01) of the deinterlacer to something or it stalls.

gst-launch -v filesrc location=/home/root/TESTH264.mpg ! mpegtsdemux ! h264parse output-format=1 access-unit=true ! omx_h264dec ! omx_hdeiscaler name=d d.src_00 ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! omx_videosink display-mode=OMX_DC_MODE_1080P_60 d.src_01 ! fakesink silent=true

Output looks nice and clean.  Anyone have any more comments on the above?  (Does this all look kosher?)

Tate

The above pipeline looks good. As you have observed, the deiscaler elements need 2 src ports to be connected to something, otherwise the OMX component stalls.

Hello Harinarayan Bhatta:

   When I Play a MPEG2 TS stream (HD video width 1920*1080) using the omx_mdeiscaler plugin,When Play over ,the gst-launch command can not exit normally,and the shell  dead there.I have to power off.The following is my infor:

Command:

gst-launch filesrc location=./1920*1080Mpeg2.ts ! mpegtsdemux ! video/mpeg ! mpegvideoparse ! omx_mpeg2dec ! omx_mdeiscaler name=d d.src_00 ! 'video/x-raw-yuv,width=480,height=300' ! omx_ctrl  display-mode=OMX_DC_MODE_1080P_60  display-device=LCD ! omx_videosink  sync=false display-device=LCD  top=20 left=20 d.src_01 ! fakesink silent=true -v

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

/GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0: pat-info = ((GValueArray*) 0

x185650)

/GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0: pmt-info = ((MpegTsPmtInfo*)

 0x165720)

/GstPipeline:pipeline0/GstCapsFilter:capsfilter2: caps = video/mpeg

/GstPipeline:pipeline0/GstCapsFilter:capsfilter2.GstPad:src: caps = video/mpeg,

mpegversion=(int)2, systemstream=(boolean)false

----------------------------

--------------------------------all above is ok

--------------------------------now play over and release resources

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

New clock: GstSystemClock

Recieved EOS event, press <CTRL+C> to terminate pipeline.

Recieved EOS event, press <CTRL+C> to terminate pipeline.

Got EOS from element "pipeline0".

Execution ended after 197382096100 ns.

Setting pipeline to PAUSED ...

Setting pipeline to READY ...

/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = NULL

/GstPipeline:pipeline0/GstOmxVideoSink:omxvideosink0.GstPad:sink: caps = NULL

/GstPipeline:pipeline0/GstOmxBaseCtrl:omxbasectrl0.GstPad:src: caps = NULL

/GstPipeline:pipeline0/GstOmxBaseCtrl:omxbasectrl0.GstPad:sink: caps = NULL

/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:src: caps = NULL

/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:sink: caps = NULL

/GstPipeline:pipeline0/GstOmxMDeiScaler:d.GstPad:src_01: caps = NULL

/GstPipeline:pipeline0/GstOmxMDeiScaler:d.GstPad:src_00: caps = NULL

/GstPipeline:pipeline0/GstOmxMDeiScaler:d.GstPad:sink: caps = NULLsink.

unrecoverable error: The cause of the error could not be determined (0x80001001-----------------------stop here,and shell dead.

    As the above showed,the shell stop at:

/GstPipeline:pipeline0/GstOmxMDeiScaler:d.GstPad:sink: caps = NULLsink.

unrecoverable error: The cause of the error could not be determined (0x80001001-----------------------stop here,and shell dead.

And  I try to  press <CTRL+C> to terminate pipeline，But no valid.,the shell can not response. I must powe off.

 Have you encountered this? Thanks very much.

Hardik/All TI guys,

With the latest release of EZSDK/PSP I am still seeing the fields out of order on 1080i video (likely output of all interlaced video).  You had mentioned that it would be fixed in the next HDVPSS/PSP release, but it doesn't seem to have been addressed as far as I can see.

Is there perhaps a patch available (or can be made available) to fix this?

Please advise,

Tate

Hi Hardik,

              We are also seeing the same issue with 1080i60 display (Field order is reversed) in EZSDK 5.05.02.00.  Changing 1080i60 display to 1080P30 is not an option for us since our output has to be interlaced.  Could you provide any other fix for this?

Thanks,

Senthil  

Senthil,

The problem is actually more complicated than field order.  We have found that the SAV and EAV codes are incorrect such that the F and V bits are not transitioning on the correct lines.  The issue is in the VPSS code.  Resolving this cost us quite a bit of time and expense, but I will say it can be fixed, providing you have the proper test equipment to analyze the SAV and EAV codes.

Tate

Hi Tate,

I did not get how this is vpss code issue? We had also seen earlier that in the input itself, FVH bits were not toggling correct causing field reversal issue. Have you done any changes in vpss code for resolving this issue?

Regards,

Brijesh

On the DM814x, our field reversal problem went away when we modified the EZSDK 5.05.02.00 VPSS overlay code to subtract one from dCfg->activeLineStart1 in the hdVencSetModeTiming(), in vpshal_hdvenc.c ...

Hi,

   About the problem, we improved the VPSS firmware to display the image correctly (the wrong order was obtained in the graphics and video layers), something important to mention is that getting the correct image didn't mean that the video was compliant with the standard, further work was needed to make it compliant with it.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/328536/1145231.aspx#1145231

-David