#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
