> On Jun 5, 2018, at 1:17 PM, Marton Balint <[email protected]> wrote:
>
> On Tue, 5 Jun 2018, Dave Rice wrote:
>
>>> On Jun 4, 2018, at 4:21 PM, Marton Balint <[email protected]> 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.
Dave
_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
