Exception in encode thread when extracting motion events on v1.6

[radpopl]

After update tonight to v1.6 DVR-Scan stops working :/

E:_na pena\$2>"c:\Program Files\DVR-Scan\dvr-scan.exe" -i output.mp4 -t 0.3 [DVR-Scan] DVR-Scan 1.6 [DVR-Scan] Initializing scan context... [DVR-Scan] Opened video output.mp4 (1920 x 1080 at 30.000 FPS). [DVR-Scan] Using subtractor MOG2 with kernel_size = 7 (auto) [DVR-Scan] Scanning input video for motion events... [DVR-Scan] Fatal error: Exception raised in encode thread. Detected: 1 | Progress: 0%| | 7/45891 [00:00<1:28:43, 8.62 frames/s] [DVR-Scan] Critical Error: Traceback (most recent call last): File "dvr_scan__main__.py", line 41, in main File "dvr_scan\cli\controller.py", line 309, in run_dvr_scan File "dvr_scan\scanner.py", line 768, in scan File "dvr_scan\scanner.py", line 918, in _encode_thread File "dvr_scan\scanner.py", line 837, in _on_encode_frame_event AssertionError

E:_na pena\$2>"c:\Program Files\DVR-Scan\dvr-scan.exe" -i output.mp4 -t 0.3 -c H264 [DVR-Scan] DVR-Scan 1.6 [DVR-Scan] Loading config from file: H264 [DVR-Scan] File not found: H264 [DVR-Scan] Failed to load config file.

[radpopl]

PS. I installed the complete version from the installer.

[Breakthrough]

DVR-Scan v1.6 has some new output modes which may help with cases like this, you can try using ffmpeg for video output instead of OpenCV:

"c:\Program Files\DVR-Scan\dvr-scan.exe" -i output.mp4 -t 0.3 -m ffmpeg

That being said, for your first command, that failure shows that one of the frames decoded from the video had a different frame size. That could be related to the update of the OpenCV/FFmpeg libraries DVR-Scan uses for decoding videos. Are you able to share a sample of that video for testing?

Lastly, if you still wish to use OpenCV for video output to have the same command you previously did, you need to create a config file with the following line:

opencv-codec = H264

You should then specify the path to that file as the -c/--config argument. Note it was changed from a previous version where it used to specify the codec, now you must use a configuration file.

Please share any other information you can (let me know if any of the above works for you), especially a sample clip if you are able to share it.

Thank you for the report!

[radpopl]

DVR-Scan v1.6 has some new output modes which may help with cases like this, you can try using ffmpeg for video output instead of OpenCV: "c:\Program Files\DVR-Scan\dvr-scan.exe" -i output.mp4 -t 0.3 -m ffmpeg

Thanks.

That being said, for your first command, that failure shows that one of the frames decoded from the video had a different frame size. That could be related to the update of the OpenCV/FFmpeg libraries DVR-Scan uses for decoding videos. Are you able to share a sample of that video for testing?

When I added -m ffmpeg the problem disappeared.

The file is 15GB, but I am attaching the beginning (ffmpeg -i in.mp4 -c copy -t 20 out.mp4) -- the error still appears.

The source file was created by combining MP4 files using ffmpeg. There have been no problems so far with these files, but there is a problem with this file. I was also using the previous version of DVR-Scan, but then it generated output files of 11kB. (Reencoding using ffmpeg helps)

https://files.fm/u/t879tpr6ba

[Breakthrough]

Do you recall what version of DVR-Scan you were running before?

Thanks for the reply - I'm not totally sure if this can be solved purely on my end with DVR-Scan since we offload video IO to separate libraries, but I'll see if this can be handled more gracefully in the future. At least an improved error message that recommends re-muxing the input video like you have said.

Really appreciate the sample you provided, that was very useful for debugging! This issue was happening for a few users but I was never able to obtain a sample that could reproduce it.

[Breakthrough]

For your reference: I ran the video through DVR-Scan just now, and it looks like the error happens because two of the decoded frames are only 1920x1080, but the rest of the frames are 3480x2160. I will also look into how other video decoding libraries handle this.

I also need to look more into how this affects score calculation - it seems these frames are still included in the motion score, but OpenCV doesn't recognize this condition. I suspect based on the code it only compares these frames with the upper left corner of the background model, which may lead to inaccurate results.

I will look into adding a warning instead and discard those frames both during detection and when saving events. I am unsure how ffmpeg handles this case internally, but in general ffmpeg output mode is better for most users so I recommend that now. I have not made that the default mode yet but am considering it in a future release.

Also note there is a -m copy output mode that uses stream copying like how you extracted the beginning. You may want to try that as well to generate the output faster without re-encoding.

[radpopl]

Thank you for the information.

As for the "-m copy" function, I don't know if it will work in this situation. ffmpeg then cuts the source at the nearest keyframe, and such a frame may be further ahead beyond the portion that DVR-Scan should cut. But I'll check.

[Breakthrough]

In the next release, DVR-Scan will ignore these frames. This isn't ideal, but is the quickest solution. To assist with indicating when this happens, I've added warnings when generating output in this manner, as well as a warning in the scan path.

I considered ignoring frames where the resolution didn't match, but this might change behavior, so for now I've left this as is. In the long term it might be a good idea to ignore these frames, but some research should be done first into how the background subtractor handles this case.

In the meantime, the next release should avoid crashing in these cases, and provide warnings on each frame including the frame # and timecode.