I'm using DVSDK 4, dm368, and encoding H.264 std resolution interlaced streaming to the network using RTP packetization. The problem I'm having is that the decoder can't seem to decode the video correctly. The video looks fine when playing through VLC. But the decoder appears to be getting the temporal order of the fields confused. All horizontal motion demonstrates a jittery edge.
The problem is observed both in my decoder app, which decodes streaming h264 from the network. And in the decode sample app provided with the SDK. Has anyone ever seen interlaced video properly displayed by the DM368 using the decoder provided with 4_00_00_22 sdk?
I've even swapped the top and bottom field encoding on the encoder. This fixed the temporal order issue but resulted in visually flipped field lines. Because the DVSDK is delivered with no interlaced encoding I'm suspicious that it doesn't work and hasn't been tested properly.
John A
John,
I am not sure about the DVSDK support for interlaced decoding. Will check and get back.
But DM36x H.264 decoder is very much capable of decoding intrelaced content. You can try using the sample test app provided with the decoder release and check the stream. The sample test app can also help you to understand the way decoder buffers needs to be presented for intrelaced content.
regards
Yashwant
Quite frankly, I'm not sure that the problem isn't in the encoder. When I watch the video on VLC the jittery motion isn't as clear as watching an NTSC monitor using the dm368 as the decoder. It's like the encoder is mixing the bottom field of frame n with the top field of frame n+1.
I'd like to feed an entire frame to the decoder as a single buffer but It doesn't act like I would expect. I would expect the decoder to consume only the amount of bytes for the first field if it's going to return a Dmai_EFIRSTFIELD code.
Hi John,
I am able to run decoder demo application provided with DVSDK for interlace streams, the application reads stream from file and displays output on TV. Video on TV is fine, there is no flip flop of fields. Can you provide your stream I will try here.
And are you seeing the issue only when you provide one frame/field data to decoder?
I am using DVSDK3.1.
I'm coming to the conclusion that the encoder is my problem. I will provide a sample video file soon.
Here is a sample h.264 encode that demonstrates the field order problem. When you run it with the dvsdk sample decoder you can see the jitter trails on the moving cars. If I encode the bottom field first the jitter goes away but the field order is visually reversed.
http://dl.dropbox.com/u/3345452/test.264
We decoded the stream with Decoder demo, observed jitter trails on moving cars. And same jitters trials can be observed when we play stream in VLC player.
We open stream in stream analyser with Top field and bottom fieldd seperately, motion in bottom field is lagging compare to Top field. In Interlace video when we encode top field 1st, motion in bottom field will be ahead of top field but in this streams its not. So we suspect input to the encoder might going wrong. Please check input YUV.
If your YUV is fine, please share your encoded stream with bottom field 1st.
Thanks for checking this Veeranna. It's nice to confirm that it's in the encoder. So now the question is whether it's in the UYVU or a problem with the encode operation. I have to write a tool everytime I want to check something like this. I've already wrote a simple app to render the UYVY and 420 frames. Maybe I'll render the UYVY in gray scale and make the even line green hue and the odd ones red. That way I can see if the issue is in the UYVY capture.
I dont think the problem is with encoder. The problem seems to be in the way the encoder is getting the YUV input. The encoder is verified to be working fine with interlaced mode.
I verified that the problem exists on the DM365EVM, so that eliminates the possibility that we made an error on our board design.
I really don't see what I could be doing to mess up the YUV input. I'm using DMAI calls so it's all pretty high level, hands off the guts.
Does anyone have any interlaced video captured with the composite input of the EVM? Maybe this design is untested.
This is a frame of the UYVY data. I have rendered the top field even lines (starting at 0) with green and the bottom field odd lines with red. The top field is trailing behind the car, which means the bottom field is rendered second. IOW the UYVY data looks correct in temporal order. This leads back to the encoder not working correctly.
In this image it looks that red lines are at top. To confirm encoder functionality, please run test app provided with package for interlace video. Test app has routines to convert 420 planar to 420 uv interleaved and uv interleaved to 420 planar. We tested it for many interlace inputs we did not see such issue.
It looks like the top field is red because of the 5 lines of black video above the first red line. So the 1st red line is line 5 (numbered 0..479).
I'm guessing that the test program is not the one using DMAI, which I am. I'll take a look.
The encode program in ths dvsdk -demos directory does not encode interlaced video. The test apps under the codecs hierarchy do not build using the sdk top level make. It's not worth trying to figure out how to compile these apps as it does nothing for me. I'm using the DMAI API, so even if it encodes properly I wouldn't know what to change.
I will take a look at the code and see if any kind of parameters might be used that I'm not using. That would be the only help it would provide.
My theory right now is that the bottom field of frame N is being encoded with the top field of frame N+1. If I'm right I could play some tricks with what I send to the encoder. If that works then I go with that and let those who follow figure it out themselves and use my posts as a clue.
I just saw the test.264 which you have shared. I feel that is encoded fine. I see the top field ahead which should be if top field is captured first. The car edge appears jittery to me because it is an interlaced content and I am playing it on a progressive display (my PC/laptop). Had it been played on a TV, it would have looked fine. Where are you seeing the o/p after decoder ?
Yashwant,
I agree the top field is ahead, but should not be because it's captured first. The bottom field captured last is later in time, and since the car has advanced forward the latest field should be ahead.
I am viewing this video using the DM368 composite output displayed on an NTSC CRT monitor. The jitter is present and clearly indicates a problem with the video.