- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there,
I have modified the function EncodeISlice in mp4_enc_vop.cpp to reflect the following :
nBitsInBuf = slice->cBS.GetNumBits() - prevnBits;
//slice->cBS.
// Number of bits for the macroblock
nBits = slice->cBS.GetNumBits(MBsPtr, MBsBitOff);
if(nBitsInBuf > mVideoPacketLength)
{
Ipp32u numBytesToCopy;
Ipp32u EndBitOffset;
Ipp8u *TempBuffer;
Ipp32u numBitsRemaining;
Ipp32u ind;
// mark MBs in current VideoPacket as invalid for prediction
MBcurr->block[1].validPredIntra = 0;
for (i = 0; i < IPP_MIN(mbnvp, mNumMacroBlockPerRow + 1); i++)
{
MBcurr[-i].block[2].validPredIntra = MBcurr[-i].block[3].validPredIntra = 0;
MBcurr[-i].block[4].validPredIntra = MBcurr[-i].block[5].validPredIntra = 0;
}
What I am doing is that :
Once the number of bytes in the output encoded b uffer exceeds the RTP MTU length,
I copy the encoded macroblock into a temporary buffer, then add the resync marker before this macroblock and mark the current macroblock invalid for MV prediction.
It's different fro what u guys do ,where when the number of bits for macroblock exceeds videopacket length, u put the resync marker after the encoded macroblock.
But, due to my modification, the depacketized and the decoded picture has some artifacts, like small bands appearing here and there, I am not sure whether I need to do anything more to fix it.
Please find the sample video file attached.
The IVOP distance is 90, BVOP is 0.
Only the IVOPS are big and get split into multiple RTP packets,but once the IVOP is screwed, everything else follows :)
Thanks a lot for your help,
Ram
p.s : Please rename the attache file to .m4v before playing it
Link Copied
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page