Mpeg2 encoding in interlace problems.

OskarM,

Once you put MPEG2 encoder in interlaced mode, how are you making sure you are passing interlaced frames (as opposed to progressive frame) to the encoder?  If you are still passing progressive frames (as our demos do by default), then this may explain why the image seem streched horizontally. 

Hi,

the problem described by OskarM is in fact our problem, sorry for the confusion. Going back to it, our goal is to capture and encode to mpeg2 PAL SD (720 x 576), 25 fps interlaced video. I started with "encode" demo application instead of writing something from scratch, next step was to inform mpeg2 encoder that the input stream is in interlace, after some quick research I've found inputContentType field of VIDENC1_Params structure and set its value to IVIDEO_INTERLACED. However  that doesn't work, that surprised me because all software codec's which I'm familiar with (MainConcept MPEG, Windows ICC)  in interlace are still working with full frames, just requires information that the frame contains two fields and internally does the job. It seems that in case DM365 mpeg2 encoder it works differently, after studying of points 4.2.1.5-4.2.1.7 of mpeg2_encoder_dm365_userguide.pdf I suspect that the encoder must be "feed" with single fields, however it isn't described how to do it correctly.  So first I will start with question to you: how to properly feed the encoder with raw data in interlaced mode?

best regards

Remigiusz Zukowski, HDP Electronics

Hi,

For interlaced input, we need to take care of the below scenario - It does not matter to the codec if the input fields are stored in seperate buffers or is in the same buffer in an inerleaved manner.

1. captureWidth -> This field specifies the stride to move from one row to the next within the same field. In case the input content is in seperate buffer, its value should be same as inputWidth(or sert to 0, because if set to 0, captureWidth is assumed to be same as inputWidth). In case the fields are in same buffer in interleaved manner, captureWidth = 2 x inputWidth.

2. The processs/encode call of the encoder is at a field level. To encode one frame(top and bottom field), one needs to call the encode process twice. First with the start pointer of the top field and 2nd with the strart pointer of bottom field. The application has to make arrangents to give the correct  start pointer of the correspoinding field.

Pls try the above change and you should get the correct output.

regards

Yashwant

Team

were you able to get the fix with this answer?

Hello,

thanks for the answer, it gives us the direction. However encoding interlace frames field by field as suggested still doesn't produce correct output. Only VLC is able to play captured *.m2v file, after some investigation I figured out that all fields in produced file are marked as "top". I was trying to search for some parameters responsible for field order and set it to correct values during field encoding. I've found two candidates: VIDENC1_InArgs::topFieldFirstFlag but flipping it on each call of Venc1_process (Venc1.c) doesn't change anything, the second candidate is IVIDEO1_BufDesc::topFieldFirstFlag but I haven't finished work on it. The development goes slowly because this project becomes low-priority :(

best regards

Remigiusz Zukowski, HDP Electronics

Hello once again.

further investigation of mpeg2 interlace encoding shows that:

-Calling encoding process twice for each frame (each call to encode one field) as suggested works fine, i.e. DM365 is not crashing, nor hanging.

-Created m2v file can be played only by VLC player. Other players are crashing or reporting "Invalid field order". Looking into the details of created file using MainConcept MPEG analysis tool:

  -MPEG 2 sequence extension::progressive_sequence = 0 which is OK

  -MPEG 2 picture coding extension has values as follows:

   * picture_structure = 10 or 01 (value flips from field to field) which looks OK

   * progressive_frame = 0 which looks OK

   * frame_pred_frame_dct = 0 which looks OK

   * repeat_first_field = 0 which looks OK

   * top_field_first = 1 which seems to be INVALID according to mpeg video compression standard, see here:

http://books.google.pl/books?id=f6Cuz9Tig-MC&pg=PA208#v=onepage&q=&f=false

I'don't know how to change top_field_first to 0, the only place which I've found (Venc1.c, function Venc1_process, line 163) does nothing.

best regards

 

Remigiusz Zukowski, HDP Electronics

 

 

Hi,

Can you send the stream you generated to us for analysis ?

regards

Yashwant

Sample streams are on our FTP: ftp2.hdp.com.pl user: texas password: texas

 

 

Thanks for pointing out the issue in the MPEG2 bitstream. I was able to reprooduce it. This is syntax flag check and made few changes. I have uploaded the testvector on ftp. Can you verify it and let me know the result. Give me your mail Id, I will send the FTP details. 

DM365 MPEG2 encoder supports
1.       Coding as progressive
2.       Coding as two fields when interlace field is set
It does not support coding as single frame when the source content is interlace. 

 Regards,

Neelakanth

Hello,

thanks, send details to my company email: remek@hdp.com.pl

 

best regards

 

Remigiusz Zukowski, HDP Electronics

 

As I know the problem was inside mpeg2 encoder and has been solved, can somebody inform me when official release of upgraded DM356 mpeg2 encoder will be available? Or should I periodically check following page: http://software-dl.ti.com/dsps/dsps_public_sw/codecs/DM365/index_FDS.html an official DM365 for the upgrage?

best regards

 

Remigiusz Zukowski, HDP Electronics

Hello,

I do see similar problem with MPEG2 interlaced encoding. Capture setting with resizer 720*480,  V4L2_FIELD_INTERLACED, V4L2_PIX_FMT_NV12. Resizer output size 736*480. Encoder setting  params->inputChromaFormat = XDM_YUV_420SP and params->inputContentType   = IVIDEO_INTERLACED. I noticed the encoded content playing twice the speed of capture and encoder generating only one coded frame per two resizer output frame. Do I need to call twice VIDENC1_process per resizer output frame?

I've implemented interlaced encoding for H.264.  You cannot get interlaced frames from the composite input unless you set the oper_mode=1 in your bootargs (u-boot).  You cannot capture NV12 interlaced.  You have to capture UYVY and then call the resizer to convert to NV12.  Be aware that this is a big performance hit.  Perhaps that's why the SDK doesn't implement interlaced encoding.

John A

John,

By default, DVSDK and LSP drivers when configured in continuous mode (oper_mode=0), does deinterlacing when interlaced input is connected. The way it is implemented in the driver is that one field is ignored and the other field is upscaled vertically to get a frame. This "deinterlacing" is done by just using the resizer.

As you correctly pointed out, when you set oper_mode=1, you can get the complete frame (both the fields) and then use resizer the way you want to get YUV420 data for each field.

The reason why LSP driver does that "deinterlacing" feature is that on DM36x there might be no other resources to do deinterlacing and hence doing it in capture flow itself is most efficient. But if you want to capture both fields with oper_mode=0, it will need changes in the driver, mainly the interrupt handler. I can guide you for the changes if you want to take that approach.

Regards,

Anshuman

PS: Please mark this post as verified, if you think it has answered your question. Thanks.

Anshuman Saxena said:

But if you want to capture both fields with oper_mode=0, it will need changes in the driver, mainly the interrupt handler. I can guide you for the changes if you want to take that approach.

Anshuman, I absolutely need to make these mods to the driver.  Running the resizer like I am doing right now is killing my performance.  My current board is an encoder/decoder and cannot do both operations simultaneously without dropping frames on the encode.

In addition, my next board will use a TVP5158 for 4 channels of simultaneous encode.  I need to be able to encode interlaced D1, 1/2 D1, and deinterlaced CIF.  I'd like to use both resizers together to deliver two streams (D1 and CIF) if possible as well.  I was just commenting yesterday to my boss about the need to modify the drivers to do this.  So your help is very timely.

John A

 

John,

I could do interlaced video capture and mpeg2 encoding using oper_mode=1.  As you said I noticed some performance  issue with it. I was searching for a way to do it using oper_mode=0 too. Anshuman, Even I would like to know about the changes we need to make to the driver to get both the fields. Thanks in advance.

 Muhammed

 

Ansuman-san,

 

Would you please give some assistance how should I change the driver to support both fields capturing with oper_mode=0 such as you describe above?

You can email to me if you want. (yuasa.t@teldevice.co.jp)

 

This answer could very helpful for my customer's problem that they have right now.

 

Regards,

Takeshi Yuasa

Yuasa-san,

John Anderson was able to get the interlaced frame in the continuous mode of capture (oper-mode=0). I am putting some information that i had shared with him to get the capture mode working. I dont have a ready solution, but you can try making these changes to make the driver work. Hopefully John can give some more pointers.

 

If you refer to dm365_ipipe.c, you will find the below code. In this code, we are setting the input height to be height/2 which would mean that we would do 2x upscale in the vertical direction.

if (!oper_state.frame_format) {
  param->ipipe_vsz = (win->height >> 1) - 1;
  param->ipipe_vps = (win->vst >> 1);
 }

You need one more change in the vpfe_imp_dma_isr in davinci_vpfe.c.

Looking at vpfe_imp_dma_isr() you can see that for fid=1, we are changing the buffer address but for fid=0, there is no case. You still need to change the output buffer address, but not for the nextframe. You need to use the address from the current frame + the line offset.

imp_hw_if->update_outbuf1_address(NULL,    common->curFrm->boff + lineOffset);

I did not dig how we can get lineoffset here, but i guess there should be somewhere in the buffer property that you should get line offset.

Now, there is one more thing that we need to take care. The input vertical size in the original driver was set to 1/2 of 480 lines need to be kept like that. The output also has to be set to 1/2 of 480 i.e. 240. This means between each VD interrupt you will get 240 lines of a field passed to the resizer and resizer will give you 240 lines output.

The VDINT0 register has to have values in the range of 220-239. I think it is currently set to similar value. If it is not correct, you would not get VPFE ISR.

I hope i am making sense.

Regards,

Anshuman

I needed to modify the driver to provide interlaced video in "on the fly" mode (i.e. oper_mode=0) because only UYVY video is available in "one shot" mode.  The H264 encoder cannot use UYVY and requires 420SEMIP.  If I captured in "one shot" mode then I had to run the UYVY through the resizer to convert to 420SEMIP and that was a performance killer.  If the MPEG2 encoder can use UYVY then "one shot" mode can work.

If you need to use chained (on the fly) mode then you'll need to modify the driver as mentioned.  The resizer needs to see an output "line length" double the line length of the capture driver (vpfe_capture).  This is so it knows to skip over a whole line on the output.  You need to double the line length in the resizer and then half it when the capture driver asks for it back.  You also need to update the resizer output address in the dma irq interrupt after the capture of the top field.  The FID equals zero during this interrupt when the update is made.

The line length is available as part of the pixel format and can be gotten from the capture device instance.

Lastly, I found that the field order on capture is different between the "single shot" interlaced and "on the fly" interlaced.  I haven't figured out why there is a difference and I haven't figured out which one is wrong.  When in single shot mode I had to kluge the DM368 decoder to get a picture without interlaced jitter, but VLC worked fine.  With "on the fly" the DM368 works fine, but VLC has jitter.

John A