This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Artifacts in lower portion of frame while using H264 HP encoder on C6678.

Hi,

I am using C6678 multi-core DSPs to encode 12 bit YUV screen captured data with 1280x720 resolution into H264 format using H264 High Profile encoder(version 1.0.2.0), at 15 fps and streaming RTP video to Android tablet running MPlayer(Android version),with a target bit rate of 1.5 Mbps with Constant Bit Rate setting and IDR frame interval of 10.

My issue is that after starting MPlayer to play the stream, I can see video plays okay but approximately after 200-300 frames, Mplayer shows artifacts accumulating in lower 1/2 to 1/3 portion of the screen which clears up after 400-500 frames and repeats it again.

Can TI video experts give us some guess or idea what might cause such artifacts? And recommend possible encoder settings to change ?

I have attached an image showing artifact on tablet MPlayer while playing H264 encoded stream.

Thank you,
Harshal Patel
HPC Systems Engineer
Signalogic Inc.

  

  • Hi Harshal, there is any way for you to check if the output clip (before RTP) is OK in those frames?. Also please share with us your used configuration params.

    thank you,

    Paula

  • Paula-

    It appears to be an RTP issue.  At least in some cases the problem occurs at higher resolutions so we suspect the receiving end may not dequeue our RTP packets fast enough for large I-frames.  Some receiving systems exhibit the issue and some do not, even if we use the same player (MPlayer or other).

    Question:  can you suggest which codec parameters or input video type, for test purposes, can reduce I-frame size for a given resolution?  For example at 720p, could we use all white (or all black) video ?

    Thanks.

    -Jeff 

  • Hi Jeff, yes you can try with a YUV template using just one color.. you can also can try different RC algorithms, I think constrained CBR (2 or 3) should help to reduce I-frame size picks. Also please use Intra 8x8 instead of 4x4 (transformBlockSize).

    You can also limit Intra MB to only intra frames (enableIntraPartition)

    configuration params:

    rcAlgo = 2 # Rate control algorithm used, 0: Variable Bitrate, 1 : Constant bitrate (low dealy), 2: Constrained CBR (No Frame Skips), 3:Constrained CBR (No Frame Skips with no scene change detection)

    transformBlockSize         = 1  # Tranform type, 0:4x4 only, 1: 8x8 only

    enableIntraPartition          = 1 # 0 => INTRA_PARTITION_NONE , 1 => INTRA_PARTITION_ISLICES, 2 => INTRA_PARTITION_IPSLICES, 3 => INTRA_PARTITION_IBSLICES, 

    thank you,

    Paula

  • Paula-

    Thanks for your help.  Your I-frame size debug suggestions are helpful.

    We now have C6678 720p H.264/RTP streaming working to an array of systems and devices:


      -Linux servers
      -Android tablets
      -Surface Pro 3 with Ubuntu installed

    We are configured for low latency, 15 fps, and we're using two (2) C6678 cores per stream.  Bitrates range from 1.5 Mbps to 5 Mbps.  From a VM desktop to an Android tablet we're at about 600 msec latency, working on reducing that to 300.


    There are various gotchas and modifications in all cases.  Mostly on the client side we're using MPlayer, for Android we've modified MPlayer somewhat for UDP buffer sizes and lower latency.  There were a number of artifact and lag/freezing issues to deal with on the client side; those are mostly resolved.  For the Surface there were WiFi mods.  Surprisingly enough quality is better than an equivalent ffmpeg stream (which we use for testing and comparison), although I'm not convinced we have tried all relevant ffmpeg settings yet (I've got our engineers doing that).

    -Jeff

  • Jeff, thanks a lot for the update, good to hear you are making good progress =)

    Paula