On Thu, Oct 28, 2021 at 1:25 AM Paul B Mahol <one...@gmail.com> wrote:
>
> probably fine
This can be verified by specifying - say - chromal topleft, and seeing
that the ffmpeg.c Output: bit right now would end up being "left"
(most likely). While if you apply this, you should get "topleft".
Technically if the values were unsanitized, having a mapping function
like we have the other way would be better, but since the code already
utilized +/- 1... I went with that way of just fixing the logic to go
the right way.
For verification of the internal values, something like the following
can be utilized:
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 1288c5efc1..50df90e9ec 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -126,6 +126,8 @@ typedef struct ZScaleContext {
enum AVColorPrimaries in_primaries, out_primaries;
enum AVColorRange in_range, out_range;
enum AVChromaLocation in_chromal, out_chromal;
+
+ int lel;
} ZScaleContext;
static av_cold int init(AVFilterContext *ctx)
@@ -687,6 +689,12 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
update_output_color_information(s, out);
+ av_log_once(s, AV_LOG_VERBOSE, AV_LOG_TRACE, &(s->lel),
+ "output frame chroma location: %s "
+ "(s->chromal: %d, dst_format.chroma_location: %d)\n",
+ av_chroma_location_name(out->chroma_location),
+ s->chromal, s->dst_format.chroma_location);
+
av_reduce(&out->sample_aspect_ratio.num, &out->sample_aspect_ratio.den,
(int64_t)in->sample_aspect_ratio.num * outlink->h * link->w,
(int64_t)in->sample_aspect_ratio.den * outlink->w * link->h,
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
