On 22.05.2018 00:07, Mark Thompson wrote:
On 16/05/18 08:19, Haihao Xiang wrote:
In lavc/hevec_vaapi, colour properties in AVCodecContext are needed to
write the sequence header
Tested by the command below:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i input-with-hdr.mkv -c:v hevc_vaapi
-profile:v main10 output.h265
Signed-off-by: Haihao Xiang <haihao.xi...@intel.com>
---
fftools/ffmpeg.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5a19a09d9a..80b5441f8f 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3298,6 +3298,10 @@ static int init_output_stream_encode(OutputStream *ost)
dec_ctx = ist->dec_ctx;
enc_ctx->chroma_sample_location = dec_ctx->chroma_sample_location;
+ enc_ctx->color_range = dec_ctx->color_range;
+ enc_ctx->color_primaries = dec_ctx->color_primaries;
+ enc_ctx->color_trc = dec_ctx->color_trc;
+ enc_ctx->colorspace = dec_ctx->colorspace;
} else {
for (j = 0; j < oc->nb_streams; j++) {
AVStream *st = oc->streams[j];
There are outstanding patches passing color_range through the filter chain (see
<https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2018-May/229248.html>), and
that would be the right solution for the rest of these properties as well, but it
would require significantly more work.
I think hacking it like this is ok for now? It's not worse than before since a
change during filtering wasn't visible anyway, and the manual options do still
work to override it. I think the commit message could be a little clearer
about the problem (really, that this colour information doesn't pass through
filtering) and its limitations (requires a single input matched to the output;
will write the wrong thing if filtering changes anything) though, or maybe that
could be explained in a comment.
Does anyone else have any thoughts on this? If there are no objections then I
would apply it updated with a clearer explanation.
Recently I checked why interlacing information is not forwarded
correctly from the decoded+filtered frame to the encoder and noticed
that the encoder is just updated too late to be picked up by the muxer
when writing header information. I think something similar is happening
here.
Initializing the encoder here will fix the situation in case the filter
graph between decoder and encoder doesn't change one of the settings,
else it will write wrong information -- which is worse than the status
quo. In my opinion the best solution would be to change ffmpeg.c to
write a header after it has fetched a frame from each output filter
graph, so it can use the actual output frame properties. Until then a
work-around is to initialize the encoder manually on the command-line,
in case you are able to determine the output values in advance (e.g. by
using ffprobe).
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
