Opened 2 years ago

Last modified 23 months ago

#4528 reopened defect

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

Reported by: diuser Owned by:
Priority: important Component: avformat
Version: git-master Keywords: mkv regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Attachments (3)

in.vob (1.4 MB) - added by diuser 2 years ago.
in.vob sample
Source.m4a (158.3 KB) - added by pat284e 23 months ago.
the source file seeming to lack global headers
SimpleCopy.m4a (158.3 KB) - added by pat284e 23 months ago.
a resultant file seeming to have global headers

Download all attachments as: .zip

Change History (10)

Changed 2 years ago by diuser

in.vob sample

comment:1 Changed 2 years ago by cehoyos

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of ticket #4472.

comment:2 Changed 2 years ago by heleppkes

#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...

comment:3 Changed 2 years ago by cehoyos

  • Component changed from undetermined to avformat
  • Keywords mkv regression added
  • Priority changed from normal to important
  • Resolution duplicate deleted
  • Status changed from closed to reopened

Too early...

comment:4 Changed 2 years ago by 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.

Last edited 2 years ago by diuser (previous) (diff)

comment:5 Changed 2 years ago by heleppkes

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

comment:6 Changed 2 years ago by svnpenn

Changed 23 months ago by pat284e

the source file seeming to lack global headers

Changed 23 months ago by pat284e

a resultant file seeming to have global headers

comment:7 Changed 23 months ago by 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.

Note: See TracTickets for help on using tickets.