| Message ID | 20180119120156.6796-1-robux4@ycbcr.xyz |
|---|---|
| State | New |
| Headers | show |
ping ? Le 19/01/2018 à 13:01, Steve Lhomme a écrit : > If we don't do that get_format might not be called for a while and the proper > SAR not used. > > See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435 > --- > libavcodec/h264_slice.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c > index e6b7998834..319a37f5b6 100644 > --- a/libavcodec/h264_slice.c > +++ b/libavcodec/h264_slice.c > @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int first_sl > || (non_j_pixfmt(h->avctx->pix_fmt) != non_j_pixfmt(get_pixel_format(h, 0)))) > must_reinit = 1; > > - if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) > + if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) { > must_reinit = 1; > + ff_set_sar(h->avctx, sps->sar); > + } > > if (!h->setup_finished) { > h->avctx->profile = ff_h264_get_profile(sps);
On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme <robux4@ycbcr.xyz> wrote: > If we don't do that get_format might not be called for a while and the proper > SAR not used. > > See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435 > --- > libavcodec/h264_slice.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c > index e6b7998834..319a37f5b6 100644 > --- a/libavcodec/h264_slice.c > +++ b/libavcodec/h264_slice.c > @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int first_sl > || (non_j_pixfmt(h->avctx->pix_fmt) != non_j_pixfmt(get_pixel_format(h, 0)))) > must_reinit = 1; > > - if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) > + if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) { > must_reinit = 1; > + ff_set_sar(h->avctx, sps->sar); > + } > > if (!h->setup_finished) { > h->avctx->profile = ff_h264_get_profile(sps); > -- > 2.14.2 Why do we even do a get_format call for aspect ratio changes in the first place? It doesn't change the physical image properties, the format of image buffers etc remains the same, hwaccel decisions remain the same.. anyone know why this is? - Hendrik
On Tue, 24 Apr 2018 08:28:35 +0200 Hendrik Leppkes <h.leppkes@gmail.com> wrote: > On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme <robux4@ycbcr.xyz> wrote: > > If we don't do that get_format might not be called for a while and the proper > > SAR not used. > > > > See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435 > > --- > > libavcodec/h264_slice.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c > > index e6b7998834..319a37f5b6 100644 > > --- a/libavcodec/h264_slice.c > > +++ b/libavcodec/h264_slice.c > > @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int first_sl > > || (non_j_pixfmt(h->avctx->pix_fmt) != non_j_pixfmt(get_pixel_format(h, 0)))) > > must_reinit = 1; > > > > - if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) > > + if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) { > > must_reinit = 1; > > + ff_set_sar(h->avctx, sps->sar); > > + } > > > > if (!h->setup_finished) { > > h->avctx->profile = ff_h264_get_profile(sps); > > -- > > 2.14.2 > > Why do we even do a get_format call for aspect ratio changes in the > first place? It doesn't change the physical image properties, the > format of image buffers etc remains the same, hwaccel decisions remain > the same.. anyone know why this is? Commit 5388f0b479c56179d566c49afd8765fefef4a18e. https://ffmpeg.org/pipermail/ffmpeg-devel/2010-February/085931.html I bet it's not a real reason anymore, but didn't try.
Le 24/04/2018 à 08:28, Hendrik Leppkes a écrit : > On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme <robux4@ycbcr.xyz> wrote: >> If we don't do that get_format might not be called for a while and the proper >> SAR not used. >> >> See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435 >> --- >> libavcodec/h264_slice.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c >> index e6b7998834..319a37f5b6 100644 >> --- a/libavcodec/h264_slice.c >> +++ b/libavcodec/h264_slice.c >> @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int first_sl >> || (non_j_pixfmt(h->avctx->pix_fmt) != non_j_pixfmt(get_pixel_format(h, 0)))) >> must_reinit = 1; >> >> - if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) >> + if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) { >> must_reinit = 1; >> + ff_set_sar(h->avctx, sps->sar); >> + } >> >> if (!h->setup_finished) { >> h->avctx->profile = ff_h264_get_profile(sps); >> -- >> 2.14.2 > Why do we even do a get_format call for aspect ratio changes in the > first place? It doesn't change the physical image properties, the > format of image buffers etc remains the same, hwaccel decisions remain > the same.. anyone know why this is? How are we supposed to know the display format has changed ? Checking each AVFrame sample_aspect_ratio to see if something changed ? > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Apr 25, 2018 at 9:55 AM, Steve Lhomme <robux4@ycbcr.xyz> wrote: > Le 24/04/2018 à 08:28, Hendrik Leppkes a écrit : >> >> On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme <robux4@ycbcr.xyz> wrote: >>> >>> If we don't do that get_format might not be called for a while and the >>> proper >>> SAR not used. >>> >>> See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435 >>> --- >>> libavcodec/h264_slice.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c >>> index e6b7998834..319a37f5b6 100644 >>> --- a/libavcodec/h264_slice.c >>> +++ b/libavcodec/h264_slice.c >>> @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const >>> H264SliceContext *sl, int first_sl >>> || (non_j_pixfmt(h->avctx->pix_fmt) != >>> non_j_pixfmt(get_pixel_format(h, 0)))) >>> must_reinit = 1; >>> >>> - if (first_slice && av_cmp_q(sps->sar, >>> h->avctx->sample_aspect_ratio)) >>> + if (first_slice && av_cmp_q(sps->sar, >>> h->avctx->sample_aspect_ratio)) { >>> must_reinit = 1; >>> + ff_set_sar(h->avctx, sps->sar); >>> + } >>> >>> if (!h->setup_finished) { >>> h->avctx->profile = ff_h264_get_profile(sps); >>> -- >>> 2.14.2 >> >> Why do we even do a get_format call for aspect ratio changes in the >> first place? It doesn't change the physical image properties, the >> format of image buffers etc remains the same, hwaccel decisions remain >> the same.. anyone know why this is? > > > How are we supposed to know the display format has changed ? Checking each > AVFrame sample_aspect_ratio to see if something changed ? > Exactly. There is a lot more properties that do not and should not call get_format, like color properties (matrix,trc,primaries,range,etc). get_format should be called when the physical properties of the image buffer change, not its interpretation. - Hendrik
On Wed, 25 Apr 2018 09:55:10 +0200 Steve Lhomme <robux4@ycbcr.xyz> wrote: > Le 24/04/2018 à 08:28, Hendrik Leppkes a écrit : > > On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme <robux4@ycbcr.xyz> wrote: > >> If we don't do that get_format might not be called for a while and the proper > >> SAR not used. > >> > >> See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435 > >> --- > >> libavcodec/h264_slice.c | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c > >> index e6b7998834..319a37f5b6 100644 > >> --- a/libavcodec/h264_slice.c > >> +++ b/libavcodec/h264_slice.c > >> @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int first_sl > >> || (non_j_pixfmt(h->avctx->pix_fmt) != non_j_pixfmt(get_pixel_format(h, 0)))) > >> must_reinit = 1; > >> > >> - if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) > >> + if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) { > >> must_reinit = 1; > >> + ff_set_sar(h->avctx, sps->sar); > >> + } > >> > >> if (!h->setup_finished) { > >> h->avctx->profile = ff_h264_get_profile(sps); > >> -- > >> 2.14.2 > > Why do we even do a get_format call for aspect ratio changes in the > > first place? It doesn't change the physical image properties, the > > format of image buffers etc remains the same, hwaccel decisions remain > > the same.. anyone know why this is? > > How are we supposed to know the display format has changed ? Checking > each AVFrame sample_aspect_ratio to see if something changed ? Yes. get_format is for allocating memory only.
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c index e6b7998834..319a37f5b6 100644 --- a/libavcodec/h264_slice.c +++ b/libavcodec/h264_slice.c @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int first_sl || (non_j_pixfmt(h->avctx->pix_fmt) != non_j_pixfmt(get_pixel_format(h, 0)))) must_reinit = 1; - if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) + if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) { must_reinit = 1; + ff_set_sar(h->avctx, sps->sar); + } if (!h->setup_finished) { h->avctx->profile = ff_h264_get_profile(sps);