• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 629 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.

Trouble with H264 decoding..

John Anderson
Genius 5240 points


I'm using DVSDK 4 and the DM368 to encode, stream to network, and decode interlaced std definition h264.  I having a problem with what seems to be the decoder.  The decoded video appears to have the temporal order of the fields flipped.  When things move horizontal I get jittery images.  And when there is an instant scene flip it looks like a flash of the old picture with the new,

The first thing that came to mind was the field order of the encoder was swapped, so I encoded the frame by sending the bottom field to the encoder first, then the top.  That fixed my temporal problem with the decoder.  Horizontal motion produced smooth images.  However, the fields are visibly flipped.  Any horizontal edges are messed up and diagonals are obviously field flipped.  The field flipping is obvious when using VideoLan client to view the video.  So clearly swapping the fields at encoder is not the solution to this problem.

Logically I can't seem to figure out how this could be happening,  If the order of field display is reversed then I would expect it to be both spacial and temporal.

Now, I'm focusing on the possibility that I'm feeding the decoder the coded information improperly.  In the h264dec users guide there is a statement that you must feed the decoder at least one whole frame.  However, I am only feeding the decoder a field per Vdec1_process call.  The coded video is in byte stream format.  I tried feeding it a complete frame of two fields, but the decoder fails to operate correctly when I do this.

Feeding the decoder a complete frame of two fields would be easier for me because I can easily ensure that the first and second field order never get swapped.  When I feed it separate fields I send each RTP sequence (i.e. seq of packets terminated with a marker) as a complete field.  It's possible for the top and bottom fields to get confused without extra work on my part.  When I send the decoder a complete frame then I put both fields in one RTP sequence.

It seems like if I sent the decoder a complete frame of two fields that I should never get the Dmai_EFIRSTFIELD return code and it should handle the whole frame. Oh yeah, I'm using DMAI.

Does anyone have any comments on this?

Thanks,

John A

 

  • 0
    TI__Genius 17215 points

    John,

    If you see your previous post http://e2e.ti.com/support/embedded/f/356/t/96270.aspx, we confirmed that the DVSDK 3.1 demo decodes and dsiplays interlaced content properly. I will ask DVSDK 4 team to check it in DVSDK 4.

    As far as decoder process call is concerned, you should give only 1 field of data per process call. But the outBufs provided needs to be shared for 2 process call. After decoding the top field (assuming top comes before bottom), decoder returns outBufsInUseFalg set to 1(as part of GET_STATUS control call), which means that app need to resend the OutBufs which it provided in the last call(Not send a new frame buffer). This also means that the outBufs given to decoder still operates in frame mode(as most of the siplay device needs it that way).

    Please note that decoder cannot accept both the fields together.

    regards

    Yashwant

  • 0 in reply to Yashwant Dutt
    Genius 5240 points

    Yes, I had no luck sending the complete frame w/ 2 fields in one call. So I switched to 1 field per Vdec2_process.   I send the same output buffer whenever I get a return code of Dmai_FIRSTFIELD from the Vdec2_process call.  I also prepend the first field of each IDR frame (1 per sec  @30 fps) with the SPS/PPS.  I'm feeling like the field order issue is coming from the encoder.  VLC appears to mask the problem so I thought it was the deocder.

    John A