-ss with codec copy corrupts output

[Balint Laczko]

Summary of the bug:
The fast -ss tool with -codec copy seems to produce videos with incorrect metadata(?). The cuts sometimes cause video players (tested on VLC and win10 Movies & TV) to get confused, and start to playback the video from the "beginning" (of the input file) with a black screen of just a frozen frame (which is the frame at the -ss timepoint). Meanwhile sound plays back as if it was not cut at all. What is even more confusing that the behavior of this problem is inconsistent, some timepoints (typically the ones further from 0:00 in the input) are okay, some produce the incorrect black screens/glitches (see an example here: ​https://github.com/fourMs/MGT-python/issues/168). In some cases the metadata doesn't even get changed and the output claims to have the same number of frames and length as the input. The problem seems to be related to the mp4 container(?). It happens all the time with my test mp4 file, but if I first convert it to an avi and try to trim that the problem never happens. If I take the converted avi video, convert it back to mp4, and try to trim that with -ss and -codec copy, the problem reappears.
How to reproduce:

% ffmpeg -i input.mp4 -ss 5 -t 5 -codec copy output.mp4
ffmpeg version ffmpeg-2020-12-12-git-5148740e79-full_build
built on windows

[Balint Laczko]

this is the result of ffmpeg -i dance.mp4 -ss 5 -t 5 -codec copy problem.mp4

[Carl Eugen Hoyos]

This has currently no similarities with a valid ticket.

Please provide the input (!) sample you used and post the command line you tested together with the complete, uncut console output here in the ticket to make it valid.

(Please do not attach output files unless specifically asked.)

[Balint Laczko]

input file

[Balint Laczko]

> ffmpeg -i dance.mp4 -ss 5 -t 5 -codec copy out.mp4
ffmpeg version 2020-12-12-git-5148740e79-full_build-www.gyan.dev Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 10.2.0 (Rev5, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-libsnappy --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libglslang --enable-vulkan --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      56. 62.100 / 56. 62.100
  libavcodec     58.115.102 / 58.115.102
  libavformat    58. 65.100 / 58. 65.100
  libavdevice    58. 11.103 / 58. 11.103
  libavfilter     7. 93.100 /  7. 93.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'dance.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.29.100
  Duration: 00:00:10.05, start: 0.000000, bitrate: 1066 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080 [SAR 1:1 DAR 16:9], 923 kb/s, 59.94 fps, 59.94 tbr, 19001 tbn, 119.88 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 129 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Output #0, mp4, to 'out.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.65.100
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 923 kb/s, 59.94 fps, 59.94 tbr, 19001 tbn, 19001 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 129 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=  102 fps=0.0 q=-1.0 Lsize=     267kB time=00:00:04.99 bitrate= 437.5kbits/s speed=2.16e+03x
video:184kB audio:78kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.779118%

[Carl Eugen Hoyos]

Why do you believe that there is something wrong with the output file?
You requested a file that starts with an I-frame, begins exactly five seconds into the input file and is five seconds long. It appears to me this is exactly what you got.

[Balint Laczko]

Thank you for your quick response! Can you upload your output so I can check if I experience the same issue on my end? I also uploaded my output earlier (problem.mp4), and you can see screenshots from the glitch (played back in VLC) here: ​https://github.com/fourMs/MGT-python/issues/168

Is your platform also Windows? Could it be a platform-specific issue?

[Carl Eugen Hoyos]

Replying to balintlaczko:

Is your platform also Windows? Could it be a platform-specific issue?

You misunderstand: I am not saying that I get different output than you, I tried to explain that what you got is what you asked for.

[Balint Laczko]

I see. I have been using the same process for ages without this kind of issue before, that is why I thought this time that this is not normal. Do you have a suggestion then how to avoid the problem?

[Balint Laczko]

two screen captures illustrating the issue

[Carl Eugen Hoyos]

Replying to balintlaczko:

I see. I have been using the same process for ages without this kind of issue before

That sounds unlikely / you probably missed the issue before.

that is why I thought this time that this is not normal. Do you have a suggestion then how to avoid the problem?

You cannot avoid it for the given input file and the given start point if you don't re-encode (although feel free to test with -copyinkf).

[Carl Eugen Hoyos]

Please do not attach more files unless asked!

[Balint Laczko]

That sounds unlikely / you probably missed the issue before

Okay, thanks for the assumption. :-)

Nevermind the problem, it's "normal". OK!