Current system: Ubuntu 18.04.1 LTS
NVIDIA driver: 410.73
NVIDIA graphics card: Quadro P5000
I was trying to encode interlaced video captured from Blackmagic Design DeckLink device with nvenc(h264) into approximately 2 seconds long segments using ffmpeg. However, ffmpeg failed to find a point to segment the video and the second segment was never created. I would like to share my problem and get some help or answers.
Long story short, it seems like when ffmpeg’s ildct flag is set, information of the encoded packet retrieved from nvenc is never marked as key frame. However, when the resulting file(undesirably long first segment) is analyzed with ffprobe there appears to be IDR frames(key frames). I found two ffmpeg tickets related to this issue and thought there might be a problem with the driver or the SDK. Links to the tickets are the following.
Now is the more elaborate version of my experience with this issue. The ffmpeg command I used is along the following line.
ffmpeg -f [DeckLink device specific options] -i [decklink device name] -c:v h264_nvenc -b:v 5000k -r 30000/1001 -g 15 -pix_fmt yuv420p -flags ilme+ildct+cgop -f segment -segment_time 2 -segment_format mpegts -segment_list list.m3u8 segment_%03d.ts
Not certainly sure about how ffmpeg works but
- ffmpeg requests h264_nvenc to encode something
- receives the result through h264_nvenc(nvenc.c)
- sends result to the segment muxer(segment.c)
- segment muxer requests mpegts muxer(mpegtsenc.c) to finally write the packet
Whether the file must be segmented or not is decided by the segment muxer. One of the conditions that must be met for the file to be segmented is for the packet being written is an IDR frame(key frame). Since, all the packet information was never marked as a key frame the file was never segmented.
Contrary to the information while encoding, the resulting undesirably long first segment contains IDR frames for sure as I analyzed it with ffprobe and is segmented as desired when used as input. I’m assuming that the encoded packet by h264_nvenc encoder is correctly encoded but the information provided from nvenc via getting the bitstream state by locking it is not working properly.
Right now I got around this problem by adding some code to determine if the packet contains nal unit indicating it as an IDR frame and manually set the key frame flag in the segment muxer.
I would like to know…
- if it is a driver or sdk issue
- if this problem can be reproduced on Windows with the latest drivers
- other possibilities than issues with the driver or sdk