[FFmpeg-trac] #8958(undetermined:closed): ffmpeg git: yuv4mpeg pipe seems to be broken

[FFmpeg]

#8958: ffmpeg git: yuv4mpeg pipe seems to be broken
-------------------------------------+-------------------------------------
             Reporter:  BlueSwordM   |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  minor        |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:  invalid
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by JEEB):

 For context, quoting the discussion I had with taliho on IRC last night.

 {{{
 02:11 < taliho4> JEEB: maybe interesting for you
                  https://trac.ffmpeg.org/ticket/8958
 02:13 <@JEEB> taliho4: yup, I plugged the pipes together, and the
               AVFrame received from the filter chain contained that
 02:13 <@JEEB> if the AVFrame didn't have that info set, it would not
               be set in the muxer, either
 02:15 <@JEEB> I'd say the current behavior of passing the AVFrame's
               flags by default makes sense. if that enables features
               in muxers etc which break other implementations it's a
               consideration whether that should be disabled by default
               (put under -strict experimental or so), or if the other
               implementations should be helped
 02:15 <@JEEB> and yea looking at that log it specifically sets the
               range in the h.264 stream
 02:15 <@JEEB> > Stream #0:0(eng), 9, 1/1000: Video: h264 (High), 1
               reference frame, yuv420p(tv, bt709, progressive, left)
 02:22 < taliho4> yeah makes sense
 }}}

 Long story short, the information is only specified if it is exactly
 specified in the AVFrame. And if passing that information - as would be
 expected - enables features in muxers etc that shouldn't be enabled by
 default, that is a separate problem, which was just not noticed before as
 often (as it would require setting the flag manually - or in some cases
 just utilizing the J pixel formats).

 For the record, I have no idea which features of y4m are "standard" and
 which are not, but as far as I can tell we're writing these values out
 without any checks. The only points where there are checks are with
 regards to certain pixel formats :) .

 So either:
 1. The flags are valid and considered standard enough - and aomenc should
 fix their Y4M parser (and in the mean time users unfortunately would have
 to utilize -color_range unknown in cases where their input actually
 defines that it is either full range or not). In this case the ticket
 should be closed like it is currently.
 2. The flags are not considered standard enough and we move them under
 some flag. Not exactly perfect either since then we by default lose the
 capability of saying that something is full range or limited range
 explicitly.

 '''Note1''':
 This was most likely already causing issues with aomenc with YUVJ pixel
 formats previously, since those cause the range to always be written
 looking at the muxer code.

 '''Note2''':
 https://linux.die.net/man/5/yuv4mpeg (which I think is the origin of y4m)
 notes that
 > X[string] - 'metadata' (optional; unparsed, but passed around)
 Thus, I am heavily leaning towards option 1, which would be no change on
 our output by default as clearly aomenc is not handling the format well
 enough.

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