I notice four encoders ( H264, H265, VP8, VP9 ) all claims to support SliceIntraRefreshEnable and SliceIntraRefreshInterval.
But there is very little info on Internet how to use them. As I understand it will smooth the throughput of output packet flow, make every frame partial I/P containing I slice and P slice.
I tried to enable omxh265enc SliceIntraRefreshEnable=true SliceIntraRefreshInterval=30, but I found the output frame size is still very similar to w/o them. We can still observer perdiodic I frame about 60K bytes and 7K-10K for P frames.
Besides, I read from some article, that VP9 doesn’t support slice, so why does jetson tx2 claim the the encoder support it?
Hi pin,
Please try [Set virtual buffer size] and [Enable stringent bitrate] in gstreamer user guide
https://developer.nvidia.com/embedded/dlc/l4t-accelerated-gstreamer-guide-28-2-ga
Hi, DaneLLL
I found a thread discussing slice encoding:
https://devtalk.nvidia.com/default/topic/1020558/jetson-tx1/h265-decode-failed/post/5196041/#
I use similar gstreamer script to save the stream :
gst-launch-1.0 videotestsrc ! ‘video/x-raw, width=1920, height=1080, framerate=60/1, format=UYVY’ ! nvvidconv ! ‘video/x-raw(memory:NVMM), width=1920, height=1080, format=I420, framerate=60/1’ ! omxh265enc control-rate=2 bitrate=8000000 preset-level=3 SliceIntraRefreshEnable=true SliceIntraRefreshInterval=30 ! ‘video/x-h265, stream-format=(string)byte-stream’ ! filesink location=slice_encoding.265
I analyze it with ffprobe. I found periodic I frame in the stream, here is the ffprobe result for jetson tx2 encoder output.
[url]https://github.com/rivertomoon/ULLRC/blob/master/nvidia_encoder_ffprobe.txt[/url]
My jetson BSP version is:
# R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t186ref, EABI: aarch64, DATE: Fri Mar 2 04:57:01 UTC 2018
So I tried to do slice encoding with libx264 and it resulted single I frame at very beginning and all P frames follows, that’s what we think correct for slice encoding.
I attach the libx264 h264 file here for your reference:
nvidia_encoder_ffprobe.txt (3.97 KB)
[i]Also referring to the discussion in this thread: [url]https://devtalk.nvidia.com/default/topic/1020558/jetson-tx1/h265-decode-failed/post/5196041/#[/url][/i]
The expected behaviour of SliceIntraRefreshEnable would be to generate partial I frames inside the P frames. Setting SliceIntraRefreshInterval to 30 should mean that each P frame should include an 1/30th slice I frame (like a 720/30=24 pixel height row of a 720p image in cycles). This even works over UDP, since all P frames are also I frames too, the decoder will be able to reconstruct the whole stream after receiving 30 frames. The purpose of this is to even the bandwidth usage and decoding computation power as much as possible in a per frame basis (to avoid chopping, etc. especially on super low latency setups).
Unfortunately the current implementation does not work like this. I wasnt even able to get rid of the I frames, whatever I set (liceIntraRefreshInterval=0 iframeinterval=0 EnableStringentBitrate=true etc) there is always a large I frame after some P frames.
Maybe a detailed explanation about the following options could help us to understand what is going on inside the encoder:
SliceIntraRefreshEnable
SliceIntraRefreshInterval (how it differs from iframeinterval?)
EnableStringentBitrate
Thank you.
Hi,
The properties have to be configured all together.
omxh264enc control-rate=2 vbv-size=1 EnableTwopassCBR=true EnableStringentBitrate=true
The sample pipeline is in
https://developer.nvidia.com/embedded/dlc/l4t-accelerated-gstreamer-guide-32-2
Thank you.
The mentioned properties with the EnableTwopassCBR option does a really good job in evening out the P frame sizes - however there are still 2-8x larger I frames generated in the given iframeinterval.
The SliceIntraRefreshEnable and SliceIntraRefreshInterval options are just to make the stream a bit more error tolerant to data loss? So it does not distribute entire I frames across n i[/i] P frames?