[regression] [matroska] Codec for stream 1 does not use global headers but container format requires global headers

[diuser]

Summary of the bug:
ffmpeg -i in.vob -c:a copy -c:v libx264 out.mkv prints

[matroska @ 0xc166aa0] Codec for stream 1 does not use global headers but container format requires global headers

since n2.6-dev-3056-g9598946 merge from libav.

Could be related to ​https://trac.ffmpeg.org/ticket/4485

How to reproduce:

% ffmpeg -i in.vob -c:a copy -c:v libx264 out.mkv
ffmpeg version N-45235-gd2184bf-   http://johnvansickle.com/ffmpeg/    Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.9.2 (Debian 4.9.2-10)
  configuration: --enable-gpl --enable-version3 --disable-shared --disable-debug --enable-runtime-cpudetect --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --cc=gcc-4.9
  libavutil      54. 23.101 / 54. 23.101
  libavcodec     56. 35.101 / 56. 35.101
  libavformat    56. 31.100 / 56. 31.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 14.100 /  5. 14.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mpeg, from 'in.vob':
  Duration: 00:00:02.12, start: 0.360000, bitrate: 5500 kb/s
    Stream #0:0[0x1bf]: Data: dvd_nav_packet
    Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg), 720x576 [SAR 16:15 DAR 4:3], max. 8000 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:2[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 224 kb/s
[libx264 @ 0xc167820] using SAR=16/15
[libx264 @ 0xc167820] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
[libx264 @ 0xc167820] profile High, level 3.0
[libx264 @ 0xc167820] 264 - core 146 r61 121396c - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
[matroska @ 0xc166aa0] Codec for stream 1 does not use global headers but container format requires global headers
Output #0, matroska, to 'out.mkv':
  Metadata:
    encoder         : Lavf56.31.100
    Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv420p, 720x576 [SAR 16:15 DAR 4:3], q=-1--1, 25 fps, 1k tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.35.101 libx264
    Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, 224 kb/s
Stream mapping:
  Stream #0:1 -> #0:0 (mpeg2video (native) -> h264 (libx264))
  Stream #0:2 -> #0:1 (copy)
Press [q] to stop, [?] for help
[mpeg2video @ 0xc163700] ac-tex damaged at 40 4
[mpeg2video @ 0xc163700] Warning MVs not available
[mpeg2video @ 0xc163700] concealing 1440 DC, 1440 AC, 1440 MV errors in P frame
frame=   57 fps= 53 q=-1.0 Lsize=     332kB time=00:00:02.20 bitrate=1235.3kbits/s    
video:277kB audio:53kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.475006%
[libx264 @ 0xc167820] frame I:2     Avg QP:22.62  size: 12346
[libx264 @ 0xc167820] frame P:49    Avg QP:24.02  size:  5006
[libx264 @ 0xc167820] frame B:6     Avg QP:26.03  size:  2166
[libx264 @ 0xc167820] consecutive B-frames: 78.9% 21.1%  0.0%  0.0%
[libx264 @ 0xc167820] mb I  I16..4: 15.1% 83.8%  1.0%
[libx264 @ 0xc167820] mb P  I16..4:  2.7% 13.7%  0.1%  P16..4: 42.1%  5.2%  3.1%  0.0%  0.0%    skip:33.1%
[libx264 @ 0xc167820] mb B  I16..4:  0.3%  0.8%  0.0%  B16..8: 42.0%  1.8%  0.2%  direct: 1.5%  skip:53.4%  L0:26.4% L1:71.4% BI: 2.2%
[libx264 @ 0xc167820] 8x8 transform intra:83.4% inter:97.1%
[libx264 @ 0xc167820] coded y,uvDC,uvAC intra: 63.2% 44.5% 0.2% inter: 19.4% 23.0% 0.0%
[libx264 @ 0xc167820] i16 v,h,dc,p:  9% 67%  4% 19%
[libx264 @ 0xc167820] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 25% 46%  2%  3%  3%  5%  2%  5%
[libx264 @ 0xc167820] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 43% 18%  1%  2%  2%  3%  1%  2%
[libx264 @ 0xc167820] i8c dc,h,v,p: 60% 25% 14%  2%
[libx264 @ 0xc167820] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0xc167820] ref P L0: 64.7% 10.2% 18.0%  7.2%
[libx264 @ 0xc167820] ref B L0: 80.2% 19.8%
[libx264 @ 0xc167820] kb/s:992.93

[diuser]

in.vob sample

[Carl Eugen Hoyos]

Duplicate of ticket #4472.

[Hendrik]

#4472 is about AAC, there is no AAC in this file? How is it a dupe of that?

Fixing this particular problem probably works by adding "-flags +global_header", although I imagine that ffmpeg.c should be able to set that flag automatically based on the muxer in use...

[Carl Eugen Hoyos]

Too early...

[diuser]

In my case encoding works, unlike #4472. Resulting file looks playable.

But this error message was not there before the 959894632ae67e356ede734e352eabda6bb55794 merge:

[matroska @ 0xb7bbaa0] Codec for stream 1 does not use global headers but container format requires global headers

I'm not sure if this bug is related to #4485 because samples from the #4485 report look good in my player, no jittery video.

[Hendrik]

It looks like this warning itself is the bug, it can be safely ignored, the produced files are perfectly fine.

[svnpenn]

Same problem here

​http://superuser.com/q/914050

[pat284e]

the source file seeming to lack global headers

[pat284e]

a resultant file seeming to have global headers

[pat284e]

heleppkes wrote,

this warning itself is the bug

However, this warning may be correct and not a bug. Nevertheless, this warning needs to be rephrased for clarity.

I have an m4a file, which is a good example for the present issue. Let this m4a file be "Source.m4a". I will try to upload it.

FFmpeg 2.7.1 was used in the following experiments.

ffmpeg -i Source.m4a -codec copy SimpleCopy.m4a

The above command causes the following warning.

Codec for stream 0 does not use global headers
but container format requires global headers

If this warning is correct, then Source.m4a must be lacking global headers, and hence violating the specification of m4a. In fact, QuickTime Player fails to open Source.m4a, though VLC can open and play it without any problem. QuickTime posts the error message, "The document Source.m4a could not be opened". QuickTime Player is pickier than VLC. QuickTime seems to reject minor violations of the format.

On the other hand, the resultant file SimpleCopy.m4a is successfully opened and played by QuickTime Player.

So, it seems that ffmpeg has automatically added global headers to SimpleCopy.m4a, because ffmpeg has found a violation in the source upon stream copy, and found a need to correct it for the output.

If this is the case, then it follows that the warning is correct and is not a bug. If this is the case, then the warning should be revised into the following.

"Codec for stream 0 does not use global headers but container format requires them; hence global headers have been added."

The last part, "hence global headers have been added" should be added to the warning, so that users will better understand what has happened.

Now, let us look at some more commands.

ffmpeg -i Source.m4a -codec copy -flags global_header GlobalHeader.m4a

ffmpeg -i Source.m4a -codec copy -flags +global_header PlusGlobalHeader.m4a

The above two commands cause no warning. Even if the source carries a violation, the flags option corrects it for the output. Thus, ffmpeg has nothing to complain. In fact, QuickTime Player can open them.

Here is another command.

ffmpeg -i Source.m4a -codec copy -flags -global_header NegGlobalHeader.m4a

The above command causes the following warning.

Codec for stream 0 does not use global headers
but container format requires global headers

The negative option "-flags -global_header" requests ffmpeg to deprive NegGlobalHeader.m4a of global headers. However, it would be a violation to the m4a format. Hence, ffmpeg rejects the request, adds global headers to NegGlobalHeader.m4a, and posts the warning. Indeed, QuickTime Player can open it.

However, I am not sure whether this behavior of ffmpeg is right. It may be more appropriate for ffmpeg to obediently follow the negative option, and to generate NegGlobalHeader.m4a without global headers, even if the resultant output is slightly erroneous.

Note that all the four outputs, SimpleCopy.m4a, GlobalHeader.m4a, PlusGlobalHeader.m4a, and NegGlobalHeader.m4a are identical, according to the diff command.

diff SimpleCopy.m4a GlobalHeader.m4a
diff SimpleCopy.m4a PlusGlobalHeader.m4a
diff SimpleCopy.m4a NegGlobalHeader.m4a

ffprobe may be able to find out whether Source.m4a really lacks global headers, and whether SimpleCopy.m4a really has global headers. Unfortunately, however, I do not know how to have ffprobe check the existence of global headers. Someone, please show me how.

By the way, in my situation, this problem has nothing to do with mkv. In my situation, this problem is more related to the m4a format. Please add "m4a" to the Keywords.

[mkver]

This bogus warning has been removed in 521dc78366c6ea54b7b69426dab302a57231f81e. (It was bogus because the flags of the AVCodecContext are irrelevant e.g. for stream copying; so deciding whether to warn or not based on this flag is wrong.)