figure out what floods the screen while running reprostim-videocapture

[yarikoptic]

in the screen console we have it flooding

DTS 261881707400, next:1070340518 st:0 invalid dropping.43 bitrate=150163.8kbits/s dup=0 drop=1 speed=0.114x    
PTS 261881707400, next:1070340518 invalid dropping st:0
DTS 261881807399, next:1070357184 st:0 invalid dropping
PTS 261881807399, next:1070357184 invalid dropping st:0
DTS 261881890348, next:1070373850 st:0 invalid dropping
PTS 261881890348, next:1070373850 invalid dropping st:0
DTS 261881990347, next:1070390516 st:0 invalid dropping.43 bitrate=150206.9kbits/s dup=0 drop=1 speed=0.114x    
PTS 261881990347, next:1070390516 invalid dropping st:0
DTS 261882090346, next:1070407182 st:0 invalid dropping
PTS 261882090346, next:1070407182 invalid dropping st:0
DTS 261882207492, next:1070423848 st:0 invalid dropping
PTS 261882207492, next:1070423848 invalid dropping st:0

so there is overlap of something reported from ffmpeg I guess (that bitrate=...) and probably from our script on those DTS PTS... and see what it means for us.

[yarikoptic]

other ones now... apparently we should also raise the thread_queue_size option

[video4linux2,v4l2 @ 0x55d68c20c240] Thread message queue blocking; consider raising the thread_queue_size option (current value: 4096)
[alsa @ 0x55d68c1f6080] ALSA buffer xrun.
[alsa @ 0x55d68c1f6080] ALSA buffer xrun. time=00:00:06.97 bitrate=209594.9kbits/s speed=0.0902x

which we do set explicitly:

reprostim@reproiner:/data/reprostim$ grep thread config.yaml
  a_opt: "-thread_queue_size 4096"
  v_opt: "-thread_queue_size 4096"
  n_threads: ""

and which is according to https://video.stackexchange.com/questions/25643/ffmpeg-thread-queue-size-warning-what-does-this-mean again -- we are not keeping up :-/ so I will reduce the -preset veryslow to first default medium and see how we cope with that.

[yarikoptic]

even with ultrafast when CPU never goes above 200% we get a flood of

DTS 267655382219, next:21632468 st:0 invalid dropping
PTS 267655382219, next:21632468 invalid dropping st:0
DTS 267655398847, next:21649134 st:0 invalid dropping
PTS 267655398847, next:21649134 invalid dropping st:0
DTS 267655415558, next:21665800 st:0 invalid dropping
PTS 267655415558, next:21665800 invalid dropping st:0
DTS 267655432212, next:21682466 st:0 invalid dropping
PTS 267655432212, next:21682466 invalid dropping st:0
DTS 267655448858, next:21699132 st:0 invalid dropping
PTS 267655448858, next:21699132 invalid dropping st:0
DTS 267655465556, next:21715798 st:0 invalid dropping
PTS 267655465556, next:21715798 invalid dropping st:0
DTS 267655482216, next:21732464 st:0 invalid dropping21.60 bitrate=88998.9kbits/s speed=0.993x
PTS 267655482216, next:21732464 invalid dropping st:0
DTS 267655498847, next:21749130 st:0 invalid dropping
PTS 267655498847, next:21749130 invalid dropping st:0
DTS 267655515572, next:21765796 st:0 invalid dropping
PTS 267655515572, next:21765796 invalid dropping st:0

so I left it on veryfast for now whenever generally CPU stays around 200% (we have 4 cores there).

[yarikoptic]

hm, even a plain simplest ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 out.mkv giving a flood of such PTS/DTS lines :-/

[vmdocua]

While I am still unable to reproduce this issue with my local development environment, still some notes related to the issue:

With fixes for issue #70 and issue #69 we have ffmpeg executed as subprocess monitored by background thread and all stdout/stderr outputs routed to reprostim-videocapture utility, also exists ability to restart all process starting from configuration on demand.

If issue is related to some slow hardware or similar we can't make this hardware faster, but at least we can monitor ffmpeg output streams for these "DTS ..., next:.. st:0 invalid dropping/ALSA buffer xrun/etc" problems and somehow react to it. E.g. send message to repromon, or restart recording (but it can be tricky as well - eternal loop etc).

IIUC to use ffmpeg in multithreading mode for transcoding we should first specify explicitly necessary numbers of threads, e.g. "-threads 4". In this case "thread_queue_size" will configure queue size for messages used in inter-thread communication. In my understanding large queue size only can help in some sporadic cases with low CPU resource, but in case of slow hardware applying to scheduled tasks in general it will not help, queue size will grow permanently till flood event.

We migrated to the latest Magewell SDK (issue #63). In this SDK they added features like "mw_venc" an "mw_mp4". According to docs "mw_mp4" helps converting video/audio streams into *.mp4 and *.mov files. And "mw_venc" provides GPU-accelerated H.264 and H.265 encoding (but as far as I understand it should be machine with powerful video card rather than cheap top set box). With this approach standard recording with ffmpeg should be replaced by MWCapture SDK API. Just my 2c..

[yarikoptic]

We migrated to the latest Magewell SDK (issue #63). In this SDK they added features like "mw_venc" an "mw_mp4". According to docs "mw_mp4" helps converting video/audio streams into *.mp4 and *.mov files. And "mw_venc" provides GPU-accelerated H.264 and H.265 encoding (but as far as I understand it should be machine with powerful video card rather than cheap top set box). With this approach standard recording with ffmpeg should be replaced by MWCapture SDK API. Just my 2c..

could you try that new functionality on your laptop/card to see what you would be getting and how it should make use of GPU and any particular GPU features would be needed? so if we are to replace the box, we choose in an informed fashion.

[vmdocua]

We migrated to the latest Magewell SDK (issue #63). In this SDK they added features like "mw_venc" an "mw_mp4". According to docs "mw_mp4" helps converting video/audio streams into *.mp4 and *.mov files. And "mw_venc" provides GPU-accelerated H.264 and H.265 encoding (but as far as I understand it should be machine with powerful video card rather than cheap top set box). With this approach standard recording with ffmpeg should be replaced by MWCapture SDK API. Just my 2c..

could you try that new functionality on your laptop/card to see what you would be getting and how it should make use of GPU and any particular GPU features would be needed? so if we are to replace the box, we choose in an informed fashion.

Regarding mw_venc and mw_mp4 - I was unable to quickly get any mp4 file sample from USB device and see how it works.

Did quick research and from mentioned SDK 3.3.1.1313 samples with "mw_mp4" only AVCapture is compiled but it doesn't support USB devices family (only Pro and Eco series).

Samples using mw_venc are not compiled on my environment at all (HDRCapture, HDRCaptureRecord, VideoEncode) - something wrong with libmw_venc.a binary or linker options there.

In other words if we need to try this new functionality, code recording video from USB device should be created from scratch...

[yarikoptic]

Thank you for looking into it! I think then we should just postpone this line of inquiry. ffmpeg'ing seems to work ok enough (I hope)

[yarikoptic]

FTR -- today we added -copyts option which disabled all the time stamp processing and thus disabled all those warnings. But we don't know what it lead to in terms of stored video -- ATM nobody is scanning.