Raw .264 files cannot be muxed to MP4 anymore

[Andreas Unterweger]

Summary of the bug: Muxing .264 files, even ones which have been created by ffmpeg, cannot be muxed to playable MP4 files anymore.
How to reproduce:

% ffmpeg -s 352x288 -r 30 -i foreman.yuv foreman.264
[..]
% ffmpeg -i foreman.264 -vcodec copy foreman.mp4
ffmpeg version N-91715-gd71dfc087b Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 8.2.1 (GCC) 20180813
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
  libavutil      56. 19.100 / 56. 19.100
  libavcodec     58. 27.100 / 58. 27.100
  libavformat    58. 17.103 / 58. 17.103
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 26.100 /  7. 26.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, h264, from 'foreman.264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(progressive), 352x288, 30 fps, 30 tbr, 1200k tbn, 60 tbc
File 'foreman.mp4' already exists. Overwrite ? [y/N] y
Output #0, mp4, to 'foreman.mp4':
  Metadata:
    encoder         : Lavf58.17.103
    Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 352x288, q=2-31, 30 fps, 30 tbr, 1200k tbn, 1200k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[mp4 @ 00000226e8c79300] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 00000226e8c79300] pts has no value
    Last message repeated 299 times
frame=  300 fps=0.0 q=-1.0 Lsize=     547kB time=00:00:09.90 bitrate= 452.7kbits/s speed=21.9x
video:544kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.705765%

The issue seems to be the lack of timestamps (possibly related to ​https://trac.ffmpeg.org/ticket/502). However, even adding -fflags +genpts and a frame rate via -r does not change the output, nor does it generate an MP4 file that can be played back.
Older versions of ffmpeg did not have this issue. In particular, the ffmpeg version that comes with Ubuntu 16.04 (ffmpeg 2.8.14) happily muxes .264 files to MP4 with the commands above.

[Carl Eugen Hoyos]

Please provide the file foreman.264.

[Gyan]

Can't reproduce here. Output plays in multiple players, including ffplay and VLC. How are you testing playback?

[Andreas Unterweger]

VLC 3 inside a VM on Ubuntu 18.04. With VLC 3 on Windows, the playback is choppy - there seems to be some issue with the time stamps of the B frames.

Other formats don't work altogether without time stamps, e.g., MKV:

% ffmpeg -i foreman.264 -vcodec copy foreman.mkv
[..]
[matroska @ 0000014602089300] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[matroska @ 0000014602089300] Can't write packet with unknown timestamp
av_interleaved_write_frame(): Invalid argument

[Carl Eugen Hoyos]

Replying to dustsigns:

VLC 3 inside a VM on Ubuntu 18.04. With VLC 3 on Windows, the playback is choppy - there seems to be some issue with the time stamps of the B frames.

Other formats don't work altogether without time stamps, e.g., MKV:

But this is not a regression, fails also with older FFmpeg and is a known (and, as you say, reported) issue.
If there is a regression with respect to remuxing to mp4, please run git bisect and tell us which commit introduced the bug.

[Andreas Unterweger]

It seems that the created MP4 files are identical (apart from the version number in the last few bytes), so this must be an issue related to my new Ubuntu system rather than ffmpeg. I think that this issue can be closed then.