[FFmpeg-trac] #4528(avformat:reopened): [regression] [matroska] Codec for stream 1 does not use global headers but container format requires global headers

[FFmpeg]

#4528: [regression] [matroska] Codec for stream 1 does not use global headers but
container format requires global headers
-------------------------------------+-------------------------------------
             Reporter:  diuser       |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  important    |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mkv          |               Blocked By:
  regression                         |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (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.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4528#comment:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker