On Tue, 5 Jun 2018, Dave Rice wrote:
On Jun 5, 2018, at 1:17 PM, Marton Balint <c...@passwd.hu> wrote:
On Tue, 5 Jun 2018, Dave Rice wrote:
On Jun 4, 2018, at 4:21 PM, Marton Balint <c...@passwd.hu> wrote:
The default memory allocator is limited in the max number of frames available,
and therefore caused frame drops if the frames were not freed fast enough.
I’ve been testing this patchset today. Yesterday I was occasionally getting
“Decklink input buffer overrun!” errors with this command:
/usr/local/opt/ffmpegdecklink/bin/ffmpeg-dl -v info -nostdin -nostats -t 1980 -f decklink -draw_bars 0 -audio_input embedded
-video_input sdi -format_code ntsc -channels 8 -raw_format yuv422p10 -i "UltraStudio Express" -metadata:s:v:0
encoder="FFV1 version 3" -color_primaries smpte170m -color_trc bt709 -colorspace smpte170m -color_range mpeg -metadata
creation_time=now -f_strict unofficial -c:v ffv1 -level 3 -g 1 -slices 16 -slicecrc 1 -c:a pcm_s24le -filter_complex
"[0:v:0]setfield=bff,setsar=40/27,setdar=4/3; [0:a:0]pan=stereo| c0=c0 | c1=c1[stereo1];[0:a:0]pan=stereo| c0=c2 |
c1=c3[stereo2]" -map "[stereo1]" -map "[stereo2]" -f matroska output.mkv -an -f framemd5 output.framemd5
With the patchset applied, I haven’t had that buffer overrun error re-occur.
That is very strange, it should work the opposite way. Without the patch, the
decklink driver is dropping frames (silently), so you should never get a
Decklink input buffer overrun error message, but silent frame drops instead if
you don't release (transcode) the frames fast enough.
With the patch, you won't get silent frame drops, but you might fill the
internal queue and therefore get Decklink input buffer overruns. On the other
hand, if you get Decklink input buffer overruns, that typically means that your
computer is too slow to handle transcoding in real time…
Trying to detect unreported dropped frames is why I added the framemd5 output
as a second output. After the command runs, I would use this command
grep -v "^#” output.framemd5 | awk -F',' '$2!=p+1{printf p+1"-"$2-1" "}{p=$2}'
to report the ranges of pts that weren’t incrementing the pts by 1 within the
pts. I had presumed that getting a gap in the pts within the framemd5 was
corresponding with the buffer overrun error in the terminal output. I’ve tested
a few hours of recorded with your patch applied and haven’t gotten any pts
discontinuity in the framemd5s yet.
Pushed the series.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
