I am using H263 codec with Ipp5.3 gold to encode a YUV file 182.yuv which I will provide as an attachment. I am using a bitrate of 50000 bps. I have frame skippling enabled.
There are 168 frames in the file, after encode almost 150 frames are skipped, pnly 18 are remaining. This is totally unacceptable Am i doing something wrong here. The YUV file is not too complex in motion, it is a news clip.
I am unable to attach the file as it is 25 MB. Is there a frp server i can upload to.
My encoder parameters are as follows :
30000 // frame scale
1001 // frame interval
7 // IVOP quant
7 // PVOP quant
9 // BVOP quant
10 // IVOP distance
1 // PVOP distance
15 // PVOP searchWidth in full pel
15 // PVOP searchHeight in full pel
1 // Motion Estimation algorithm: 0 - full search, 1 - fast search
2 // Motion Estimation accuracy: 1 - full pel, 2 - half pel
0// calculate PSNR
1// RateControl 0 - no, 1 - FrameLayer(VBR)
50000 // BitRate, Kbps
50 // SceneChangeThreshold, %
1// unrestricted motion vector: 0 - off; 1 - no PLUSPTYPE; 2 - PLUSPTYPE, UUI==1; 3 - PLUSPTYPE, UUI==01
0// advanced prediction: 0 - off (1MV), 1 - on (4MV, OBMC)
0// advanced Intra coding -- Annex I support
0// insert GOB headers: 0 - off, 1 - GOB headers without stuffing, 2 - GOB headers with stuffing (GSTUF)
0// modified quantization mode: 0 - off, 1 - on -- Annex T
1 // frame skipping: 0 - disabled, 1 - enabled, default 1
The YUV input isof size CIF. The max frame size generate is about 4189 bytes, but almost all frames are skipped.
does that answer your question ? Do you think i can upload the YUV file somewhere.
Ram, can you please try to upload the stream to
If, for any reasonm this doesn't work, you can encode the stream with high quality settings into any format and attach it. I believe the skip-frame issue won't be gone after stream compression/decompression.
OK.. I have uploaded the file. The filename is 182.yuv
It is in YUV 420 format. I am using H263 encoder, I have specified the encoder options in the previous post.
Also considering that there are many networks wired and wireless, supporting different packet payload types, there should be provision for limiting the encoded frame sizes.
With the parameters you use (I-frame distance set to 10 being the key one) encoding the stream into 50000 bps is impossible: encoding an all-black (DC only) Intra MB requires 53 bits, which for 352x388 frame makes 20988 bits, thus for 3 Intra frames per second (30/10) the resultant bitrate will inevitably exceed 63000 bps. Setting the I-frame distance to a value > 168 reduces the number of skipped frames considerably: 66 frames get encoded. With the rate control (and frame skipping) off and quantizers set to 31 (maximum), the stream is encoded with the bitrate exceeding the target 50000 bps by a factor of ~2.5. Which means that the stream can not be encoded into 50000 bps without dropping a considerable number of frames, unless some extra-low-bitrate tricks like forced MB skipping or transform coefficients zeroing are employed (and they are not impemented in our encoder).
These techniques like forced MB skipping or zeroing transform coefficients, are they implemented in the MPEG4 rate control or H264 rate control.
if so, can it be brought into H263, or it needs a lot of modification.
For the same example I sent you, using the bitrate as 384K with 30 fps. I do MPEG4 encoding with IVOPdist as 150 i.e everey 5 seconds. I get a frame of size 24568 bytes for the frame immediately after the black frame, although it should have been encoded as an I-frame, it was encoded as a P-frame with huge size. I am using a scene change threshold of 50.
why is this happening. The same encoding for a bitrate of 50 Kbps encodes the frame immediately after the black frame as an I-frame.
Please throw some light on resolving this issue.