The VideoLAN Forums

FreeBSD 12.1-RELEASE-p1 GENERIC amd64
vlc-3.0.8_2,4
NVidia HW acceleration enabled
(trying different drivers with same result)


vlc --avcodec-hw=any --avcodec-fast --no-avcodec-hurry-up
seek video sometimes can cause vlc to stop responding, picture freezing. Debug log messages reaction on seek/play etc. commands is
main error: input control fifo overflow, trashing type=0
main error: input control fifo overflow, trashing type=1
main error: input control fifo overflow, trashing type=3
main error: input control fifo overflow, trashing type=19
..
and so on

Does it reproduce without hardware acceleration? Does it reproduce on Linux with the same input?

Without HW acceleration it does not reproduced. Testing about two days with params:
vlc --avcodec-hw=none --avcodec-fast --no-avcodec-hurry-up

So do i need to install linux to test the same?
P.S.
Bescause NVidia's FreeBSD driver is the same linux driver running through FreeBSD linux binary cmpatibility layer
P.P.S.
I was trying 430.x (.40, .50., .64) and 440.x (.31, .36) version branches of driver with nearly the same result. Playing VBR h264 @baseline profile encoded test file. Rock solid stability in software mode and random stop with "main error: input control fifo overflow" in HW mode.

Are you able to stop the playback cleanly after it gets stuck? looks to me that the display driver just locks up.

No i can't. No reaction to stop/play,seek etc. Even choosing ohter file from play list does not work, still stalled movie picture in VLC and nothing is happened.Another copy of VLC can be runned well at the same time.

Get the debug symbol and check where it gets stuck from the stack traces. But it looks very much like a display driver problem.

Well issue is found and this is driver problem as you mentioned above.
syslog show error message "kernel: NVRM: Xid (PCI:0000:01:00): 68, pid=77679, CCMDs 00000027 0000c2b0"
So there was a therad on nvidia forum about near the same problem [url]https://devtalk.nvidia.com/default/topic/1024285/linux/vdpau-all-h-264-videos-cause-hardware-errors-nvrm-xid-pci-0000-01-00-68-ccmds-00000014-/[/url]
As I undersand after reading problem is in VDPAU video decoding acceleration engine and workaround is moving to mpv and use 'hwdec' option set to 'nvdec' in mpv. This mean (as i understand) there is no solution for VLC because VLC does not support this kind of acceleration.
That's right?

P.S.
Interesting why exactly seeking is so sensitive because regular playing does not produce error?..

NVDEC is planned in 4.0.

Presumably, seeking causing some transient corruption of the video bitstream, and the hardware decoder is not robust enough.