4

I've got a Reolink security camera, which saved .mp4 files via FTP to a local server. I've then got my own Python-based application processing those videos. It's been working fine for the past year or so, although I often noticed warnings in the Python console (from OpenCV) about "error reading header", but it worked anyway so ignored it.

Since getting a new server and reinstalling all of the software, which happens to mean updated versions of Debian Linux, Python and OpenCV, it no longer tolerates the errors and fails to load those videos. Worryingly, around 1 in 4 of the videos saved via FTP give this error in my Python app, and if I try to load them via FFMPEG on either my server or on my (Mac) laptop, I get the error [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7ff492000400] error reading header [path]: Operation not permitted

I've put one of the videos on Dropbox so you can see: https://www.dropbox.com/s/tu4ddegh6yn05nu/ErrorReadingHeader.mp4?dl=0

Anyone have any ideas what's causing this, or how to fix it? I think I've got a few options, but don't have enough info to progress any of them:

  • Fix the videos so they're not corrupt. I have asked Reolink, the manufacturer, if they can shed any light...
  • Make FFMPEG etc tolerate the errors. Not sure how... also not sure which codec OpenCV is using (I know it's definitely not FFMPEG, so there's more than one codec not happy with these headers!)
  • Try to 'repair' the videos before processing. There may be some mileage in this as a solution, but feels very inefficient so would rather avoid if possible... but it's there as a final resort!

Thanks a lot!

DaveWalker
  • 143
  • 1
  • 4
  • My answer provides a workaround for now. I shall be patching this in ffmpeg in a few days. I'll post a comment here when I do. – Gyan Jul 20 '19 at 16:50
  • Thanks, workaround is working brilliantly. Please do let us know when there's a patched version of FFMPEG available and I'll look to see if I can do the upgrade. Thanks a lot, I've been pulling my hair out because of this! – DaveWalker Jul 21 '19 at 16:39
  • ffmpeg has been patched, Get an up to date static git binary from https://johnvansickle.com/ffmpeg/ – Gyan Jul 22 '19 at 17:28

1 Answers1

5

The sample MP4 is fragmented and so instead of having a global index for samples i.e. frames, the metadata is per fragment. Within each fragment's metadata, there is a track run box trun which has data for all samples within the fragment. There was a change made in Oct 2017 (ffmpeg 4.0+) where ffmpeg would bail if the trun box indicated that 0 samples were stored within the fragment.

mp4box or older versions of ffmpeg do not fail, so you may use them to remux the file to regular MP4s.

ffmpeg-3.4 -i in.mp4 -c copy out.mp4

or

mp4box -add in.mp4 -new out.mp4
Gyan
  • 34,439
  • 6
  • 56
  • 98
  • Thanks @Gyan, that's brilliant - fixed my problem! I decided to go with mp4box, purely to avoid any potential conflicts with other versions of FFMPEG etc. Reading around it sounds like getting OpenCV to use another custom install of FFMPEG will be a painful process, and it doesn't look like Debian Buster has older FFMPEG available easily via apt-get install, so can't bring myself to try that at the moment. Maybe once there's a patched version I'll give it a go... but this answer explains the issue and workaround perfectly, thank you! :o) – DaveWalker Jul 21 '19 at 16:37
  • I implemented the mp4box workaround with the following: ``` `vc = cv2.VideoCapture(video_fullpath)` `if not vc.isOpened():` `subprocess.run([mp4box_path, '-add', video_fullpath, '-new', video_fullpath_fixed])` `vc = cv2.VideoCapture(video_fullpath_fixed)` `if not vc.isOpened():` `print('ERROR after Fixed')` `else:` `print('ERROR not Opened')` – DaveWalker Jul 21 '19 at 16:46
  • +1 came here with exactly the same problem. Retrying with ffmpeg-3.4 worked! – Coops Aug 10 '20 at 03:21
  • great, somehow older versions of ffmpeg do the trick and fix the mp4 file. Thanks – shukshin.ivan Oct 13 '21 at 19:28