H.263 encoder issues with low-motion video

[jmason]

Setup: IPP H.263 encoding of video converencing video that is transmitted to different brands and models of H.323 endpoints.

Some EncoderParams: not all params are listed here but I can add the rest if required.
info.clip_info.width = 352;
info.clip_info.height = 288;
info.bitrate = 320000;
info.framerate = 30;
m_Param.IPicdist = 9000;// 5 minutes
m_Param.PPicdist = 1;
m_Param.RateControl = 1;
m_Param.FrameSkip = 0;
m_Param.PPicsearchWidth = 15;
m_Param.PPicsearchHeight = 15;


Problem: In the case of low or no motion taking place in the H.263 encoded video, green and magenta lines begin to show up after about 20 - 30 seconds. These lines start small and few but over time grow larger in both size and their numbers. Intra frames clear up these lines but if we are sending intra frames every 20 seconds, those viewing the decoded H.263 will experience lower framerates than expected (our encoding application must adhere to bitrate restrictions). Now if I take this same data and decode it with the IPP H.263 Decoder, I do not get the same results. I, in fact, do not see the same lines. However, this happens on every single H.323 endpoint I have tested it with. Attached is an example of the issue.

1.) Could this type of problem be caused by incorrect RFC 2190 H.263 Header?
2.) Are there any Initialize params that could cause this?
3.) What could be the cause of this?

Any input on the subject would be fantastic.
Thanks,
Justin

[jmason]

So far I have not had any success fixing the issue I mentioned in my previous post. I have found, and temporarily fixed, an issue with the H.263 encoder where it was encoding unchanging MBs as intra which caused way too many Intra frames to be generated.

In this test case, I was encoding YUV consisting of 2x2 CP mode with only one participant. To elaborate, the CIF YUV frame consisted of 4 equal QCIF frames where only one contained live/changing video and the other 3 were all black YUV. That is, 3/4ths of the picture was all black. But for some reason, the luminance SAD calculations for the MBs in these black areas were returning 64 for each sadL0 - sadL3, all while sadU and sadV where both equal to 0. I do not understand how there can be such differences in luminance when the YUV data in these areas is the exact same and simple ( the function making these SAD calculations is ippiSAD8x8_8u32s_C1R ).

So is there a bug in ippiSAD8x8_8u32s_C1R ?
If there is a bug, could it also somehow cause my original issue?

Anything helpful would be very appreciated.


Justin

[Ying_H_Intel]

Hi Justin,

Could you provide more information like IPP version, platform?

It would be very helpful to have

-the problematic output for the "green and magenta lines" issue,

-the stream and configuration on which the "issue with the H.263 encoder where it was encoding unchanging MBs as intra" shows up,

-the input 3/4th-black YUV on which the SAD calculation issue can be observed (along with the encoding configuration).

for example, I try withw_ipp-samples_p_6.1.0.035, IPP 6.1.1.035 on Core 2 duo machine WindowXP 32bit. with a almost still YUV file, the problem seems not be reproducible at my side. Attached is the par file and encoder executable fiel. Use the command line,

C:\Documents and Settings\yhu5\Desktop\IPP6.1&6.1b\w_ipp-samples_p_6.1.0.035\ipp
-samples\audio-video-codecs\_bin\Win32\debug_ascii>umc_video_enc_con h263 a320_h
263.par a320.h263

Starting H263 encoding C://stream_320x240_755.yuv to file a320.h263
Source video width = 320, height = 240, frameRate = 29.97
Max frames to encode = 2147483647
Encoding bit rate = 320000 bits per second
0.10.20.30.40.50.60.70.80.90.100.110.120.130.140.150.160.170.180.190.200.210.220
.230.240.250.260.270.280.290.300.310.320.330.340.350.360.370.380.390.400.410.420
.430.440.450.460.470.480.490.500.510.520.530.540.550.560.570.580.590.600.610.620
.630.640.650.660.670.680.690.700.710.720.730.740.750.
Summary:
Num frames encoded = 755
Encoding Time = 1.16 sec, 650.16 fps
Overall Time = 3.80 sec, 198.90 fps
Average CPU usage = 48.76%
Encoded Size = 319967 bytes
Compression Ratio = 271.83
EncodedSize/ExpectedSize = 0.32

C:\Documents and Settings\yhu5\Desktop\IPP6.1&6.1b\w_ipp-samples_p_6.1.0.035\ipp
-samples\audio-video-codecs\_bin\Win32\debug_ascii>simple_player a320.h263

The videois playedon screen, it is white background, no motion, but no green and magenta lines show up.
Video Render : DX
-RenderFormat: YV12

Stream Type : H263PV
Video Info :
-Video Type : H263
-Resolution : 320x240
-Frame Rate : 29.97
DecRate:892.52 fps(Dec 0.99ms/f + Conv 0.13ms/f = 1.12ms/f) RndrRate 30.01fps Au
dio Dec 0.00chnls
DecRate:938.72 fps(Dec 0.93ms/f + Conv 0.14ms/f = 1.07ms/f) RndrRate 29.94fps Au
dio Dec 0.00chnls
DecRate:946.82 fps(Dec 0.92ms/f + Conv 0.14ms/f = 1.06ms/f) RndrRate 29.92fps Au
dio Dec 0.00chnls
DecRate:939.71 fps(Dec 0.93ms/f + Conv 0.14ms/f = 1.06ms/f) RndrRate 29.94fps Au
dio Dec 0.00chnls

[Ying_H_Intel]

Hi Justin,

Could you provide us a small test case, for example, the code of call ippsSAD8x8_8u32s_C1R (and it's input and output)?

Or would you like to try the latest IPP version, IPP 6..16 or IPP 7.0 beta with IPPstatic library (like ippvcemerged.lib ippvcmerged.lib (ippi_l.lib if in 7.0 and later). and see if the problem still insist?

Regards,
Ying