Feezing and frame drops on files from action camera

[zuf]

Hello!

I have minor but very annoying issue while playing MP4 files recorded with GoPro action camera.

When I load that file into Shotcut or Kdenlive or just playing it with melt file.mp4 command the video starts playing and hangs for a few moments twice, first at the 17th frame and second at frame 24.

When I load large amount of clips from GoPro to project in Kdenlive or Shotcut I see this little "freezes" for every clip in the timeline when playing or freezes when just switch playhead to this clips for the first time.

After "repacking" clips with commands like MP4Box -add bad_clip.mp4 fixed_clip.mp4 or ffmpeg -i bad_clip.mp4 -c copy fixed.mp4 all this little freezes not reproduced anymore.

How to reproduce

Download example file from here: https://www.dropbox.com/s/qdejdqu7sza77ns/20190511_141509_GH026992.MP4?dl=0 (file should has sha1 checksum: 1f3d38d6388a72f003eb6cc76e46673b0ddb2753)

OS: Arch linux x86_64
ffmpeg version n4.2.1
melt 6.16.0 (or latest git d850010)

1. Put example file 20190511_141509_GH026992.MP4 to relatively slow storage (External HDD or USB Flash drive or some kind of network file system)
2. Clear filesystem cache:

   # sync && echo 3 > tee /proc/sys/vm/drop_caches

3. Run melt and see freezes at 17th and 24th frame (maybe frame numbers may change, but for me that numbers always same):

   melt 20190511_141509_GH026992.MP4 

Additional steps

4. "Repack" file with command like that: MP4Box -add 20190511_141509_GH026992.MP4 fixed.mp4 or ffmpeg -i 20190511_141509_GH026992.MP4 -c copy fixed.mp4

5. Clear filesystem cache:

   # sync && echo 3 > tee /proc/sys/vm/drop_caches

6. Run melt and see there are no freezes or hangs:

   melt fixed.mp4

7. You can also clear filesystem cache again and play original file with fflpay:

   ffplay 20190511_141509_GH026992.MP4

   or any other video player without freezes.

Maybe there are some issue in seeking or loading metadata heuristics that required to read large amount of file when it just start playing.

[ddennedy]

I have noticed this as well, but I have not found the source of it in the MLT code even when reading from SSD. Once it is opened/played once (without flushing filesystem cache), the problem does not reoccur again for a while I suppose due to caching. There seems to be something strange with the way it is muxed and libavformat's handling of it based on MLT's call sequence.