• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 944 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problem with m2v decode

Markus Fritsche
Prodigy 130 points


I am having a problem with my DM368 (LeopardBoard LI-TB02) and a specific mpeg2 video. As far as I can tell, mpeg2dec is not decoding it correctly (I looked at the yuv). 


The video I am trying to transcode is test.m2v, the one I am getting by transcode is test.264. 


My gstreamer pipeline is

gst-launch -v filesrc location=test.m2v ! TIViddec2 codecName=mpeg2dec engineName=codecServer ! TIVidenc1 framerate=25/1 byteStream=false codecName=h264enc engineName=codecServer ! capsfilter caps="video/x-h264,framerate=25/1,pixel-aspect-ratio=(fraction)1777/1222" ! mp4mux ! filesink location=test.264

Is there an obvious problem with my pipeline?


  • 0
    Prodigy 130 points

    This is the output I get from gstreamer doing 

    gst-launch filesrc location=test.m2v ! TIViddec2 codecName=mpeg2dec engineName=codecServer ! filesink location=test.yuv

    And this is the one I get with dvtb-r

    Any pointers what I might do wrong with the gstreamer pipeline?

  • 0 in reply to Markus Fritsche
    Prodigy 130 points

    Hello Markus, 

    I really enjoy the conversation with you. 

    When I adjust the settings in vlc to look at the yuv-file gstreamer creates, I found out that I am able to see the video undistorted when I set the video width to 736. Not sure if this is a hardware or software issue?

  • 0 in reply to Markus Fritsche
    Guru 31670 points

    Hello Markus,

    Looks like you are playing chess against yourself :)

    If I remember correctly, the encoder has some 32 pixels constraint where it needs the horizontal resolutions to be in multiple of 32 pixel. So either 704 or 736 will only work for you. I'm not sure about the exact reason behind it.

  • 0 in reply to Renjith Thomas
    Prodigy 130 points

    Hello Thomas, 

    thanks for your input. The mystery to me is, why the same input could be decoded with dvtb (same board) just fine, while it couldn't with gstreamer. I looked at the code, and so far, I don't see any obvious difference in the DMAI parameters of gstviddec2.c (gsttiplugin) and encodedecode.c (dvtb). 

    I changed the ...dm368.cfg in gstreamer to include "groupId: 2" to the gstreamer config, that's the only difference I see so far.

    encodedecode.c is not the right place to look as I know now.

  • 0 in reply to Markus Fritsche
    Guru 31670 points

    Markus,

    What is the version of the DVSDK that you are using in both the cases?

  • 0 in reply to Renjith Thomas
    Prodigy 130 points

    Hi, 

    I am using ti-dvsdk_dm365-evm_4_02_00_06; in both cases. 

    The dvtb-s decoding code I am looking at seems to be in dvtb_4_20_18/packages/ti/sdo/dvtb/dm365/linux/dvtbMPEG2Dec2.c - and the handling looks quite different than in gsttividdec2.c - I am trying to understand the whole thing, but not being very familiar with C doesn't help. 

    Fun fact: if I play the .yuv with vlc using 
    vlc --rawvid-aspect-ratio 16:9 --rawvid-fps 25 --rawvid-width 736 --rawvid-height 576 test.yuv 
    I get this screenshot:

    So it looks to me (just a guess) that the buffer calculation that is invoked by the gstreamer-plugin is not accurate, while the code used by the dvtb-decoder is. 

  • 0 in reply to Markus Fritsche
    Prodigy 130 points

    I just found

    On DM365, there are known issues with the MPEG-2 decoder's output buffer size
calculation that cause it not to work with D1 resolutions unless you hard-code
the size.  H.264 and MPEG-4 decoders work as expected, and MPEG-2 works as
expected for 720p.

    in the changelog of gsttividdec2.c - sounds like a hint!?

  • 0 in reply to Markus Fritsche
    Guru 31670 points

    Markus,

    I am from device drivers background than multimedia. I may be wrong here, but as I told before this can be an issue with the encoder.  

    What's there is gsttividdec2.c changelog?

  • 0 in reply to Renjith Thomas
    Prodigy 130 points

    Hi, 

    from the code comments of gsttidmaivideosink.c:

    /* DM365: TO componsate resizer 32-byte alignment, we need to set
    * lineLength to roundup on 32-byte boundry.
    */

    So I think, the buffer gets allocated with a pixel line length of 736 and the caps gets constructed with a line length of 720. When I use the dvtb, the allocation seems to happen the same, but the yuv file created gets cropped correctly to 720 px line length, while the h264 encoder within the gstreamer pipeline gets passed a 736 px buffer but extracts the size being 720 px from the mimetype/ caps. That, from my view, explains the picture distortion seen in the posted example. 

    A possible solution I see is to adjust the input buffer for the h264enc pipeline element to 736px, although I don't know if it is possible to get the output cropped back to 720px per line. From the comment I would understand that the 32px alignment is a constraint of the hardware resizer, not the hardware codec, but I guess the gstreamer-plugin-code is not the right place to look for hardware documentation. 

    The comment I found in revision 858 of the ticodecplugin: https://gstreamer.ti.com/gf/project/gstreamer_ti/scmsvn/?action=browse&path=%2F&view=rev&revision=858

     Edit: The goal is to use the dm368 board as a hardware based transcoder. Cropping in advance on another device would defeat the purpose ;-)