Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: set HTTP options before writing WebVTT HLS playlists
According to Patchwork the patch results in 2 "Failed to apply" warnings
for contexts "yinshiyou/configure_loongarch64" and "andriy/configure_x86".
This is not something I saw in the `make fate` output.
Is there something I should know allowing me to fix this? Or can this be
ignored?
Thanks && kind regards.
On 10/2/23 05:50, Léon Spaans wrote:
Thanks Steven!
Have a wonderful day!
Léon
On 2 Oct 2023, at 01:17, Steven Liu wrote:
Léon Spaans 于2023年10月1日 周日22:40写道：
Fixes: Erroneous HTTP POST instead of HTTP PUT for WebVTT HLS variant
playlists.
Signed-off-by: Léon Spaans
---
libavformat/hlsenc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 08f3746ce7..150320a880 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1585,6 +1585,7 @@ static int hls_window(AVFormatContext *s, int
last, VariantStream *vs)
ret = 0;
goto fail;
}
+av_dict_free(&options);
for (en = vs->segments; en; en = en->next) {
if (target_duration <= en->duration)
@@ -1635,8 +1636,11 @@ static int hls_window(AVFormatContext *s, int
last, VariantStream *vs)
ff_hls_write_end_list(byterange_mode ? hls->m3u8_out : vs->out);
if (vs->vtt_m3u8_name) {
+set_http_options(vs->avf, &options, hls);
snprintf(temp_vtt_filename, sizeof(temp_vtt_filename),
use_temp_file ? "%s.tmp" : "%s", vs->vtt_m3u8_name);
-if ((ret = hlsenc_io_open(s, &hls->sub_m3u8_out,
temp_vtt_filename, &options)) < 0) {
+ret = hlsenc_io_open(s, &hls->sub_m3u8_out, temp_vtt_filename,
&options);
+av_dict_free(&options);
+if (ret < 0) {
if (hls->ignore_io_errors)
ret = 0;
goto fail;
--
2.40.1
___
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".
LGTM
Thanks
Steven
___
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".
___
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".
Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: set HTTP options before writing WebVTT HLS playlists
Léon Spaans 于2023年10月5日 周四15:15写道：
> According to Patchwork the patch results in 2 "Failed to apply" warnings
> for contexts "yinshiyou/configure_loongarch64" and "andriy/configure_x86".
>
> This is not something I saw in the `make fate` output.
>
> Is there something I should know allowing me to fix this? Or can this be
> ignored?
Don’t worry, These days are holidays in China mainland, maybe two days
later will check it.
>
>
>
> Thanks && kind regards.
>
>
> On 10/2/23 05:50, Léon Spaans wrote:
> > Thanks Steven!
> >
> > Have a wonderful day!
> >
> > Léon
> >
> >
> >> On 2 Oct 2023, at 01:17, Steven Liu wrote:
> >>
> >> Léon Spaans 于2023年10月1日 周日22:40写道：
> >>
> >>> Fixes: Erroneous HTTP POST instead of HTTP PUT for WebVTT HLS variant
> >>> playlists.
> >>>
> >>> Signed-off-by: Léon Spaans
> >>> ---
> >>> libavformat/hlsenc.c | 6 +-
> >>> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >>> index 08f3746ce7..150320a880 100644
> >>> --- a/libavformat/hlsenc.c
> >>> +++ b/libavformat/hlsenc.c
> >>> @@ -1585,6 +1585,7 @@ static int hls_window(AVFormatContext *s, int
> >>> last, VariantStream *vs)
> >>> ret = 0;
> >>> goto fail;
> >>> }
> >>> +av_dict_free(&options);
> >>>for (en = vs->segments; en; en = en->next) {
> >>> if (target_duration <= en->duration)
> >>> @@ -1635,8 +1636,11 @@ static int hls_window(AVFormatContext *s, int
> >>> last, VariantStream *vs)
> >>> ff_hls_write_end_list(byterange_mode ? hls->m3u8_out :
> vs->out);
> >>>if (vs->vtt_m3u8_name) {
> >>> +set_http_options(vs->avf, &options, hls);
> >>> snprintf(temp_vtt_filename, sizeof(temp_vtt_filename),
> >>> use_temp_file ? "%s.tmp" : "%s", vs->vtt_m3u8_name);
> >>> -if ((ret = hlsenc_io_open(s, &hls->sub_m3u8_out,
> >>> temp_vtt_filename, &options)) < 0) {
> >>> +ret = hlsenc_io_open(s, &hls->sub_m3u8_out, temp_vtt_filename,
> >>> &options);
> >>> +av_dict_free(&options);
> >>> +if (ret < 0) {
> >>> if (hls->ignore_io_errors)
> >>> ret = 0;
> >>> goto fail;
> >>> --
> >>> 2.40.1
> >>>
> >>> ___
> >>> 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".
> >>>
> >> LGTM
> >>
> >>
> >> Thanks
> >> Steven
> >> ___
> >> 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".
> ___
> 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".
>
___
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".
Re: [FFmpeg-devel] [PATCH] aacdec: padding skip improvements
On 10/3/2023 5:07 AM, Lynne wrote: > Despite this being a standard MDCT-based codec with a frame size of 1024, > hence a delay of 1024 samples at the start, all major encoders, excluding > faac and FFmpeg, use 2048 samples of padding. Apple's uses 2112. - Derek ___ 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".
[FFmpeg-devel] [PATCH] avformat/matroskadec: Output palette as stream side data
This is simpler implementation-wise (it avoids an almost-always-false
check in read_packet and decreases sizeof(MatroskaTrack) by about 2/3)
and makes the side-data available directly after read_header.
It also fixes the Matroska analog of ticket #10602: If a Matroska track
has a palette, said palette will be attached as side-data to the
first packet of said track and most likely, this is one read during
avformat_find_stream_info(). Yet if this packet is discarded because
of a seek performed immediately after avformat_find_stream_info(),
the information about the global palette will never reach the user.
Signed-off-by: Andreas Rheinhardt
---
Ticket #10602 can unfortunately not be fixed in this way,
because avi allows to update the palette mid-stream,
so that the palette contained in extradata must not be
exported via global side data due to the semantics of the latter.
libavformat/matroskadec.c | 39 ---
1 file changed, 12 insertions(+), 27 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 941c0bcdc9..74f3fc7ae7 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -285,9 +285,6 @@ typedef struct MatroskaTrack {
int needs_decoding;
uint64_t max_block_additional_id;
EbmlList block_addition_mappings;
-
-uint32_t palette[AVPALETTE_COUNT];
-int has_palette;
} MatroskaTrack;
typedef struct MatroskaAttachment {
@@ -2852,7 +2849,8 @@ static int mka_parse_audio(MatroskaTrack *track, AVStream
*st,
}
/* Performs the codec-specific part of parsing a video track. */
-static int mkv_parse_video_codec(MatroskaTrack *track, AVCodecParameters *par,
+static int mkv_parse_video_codec(AVStream *st, MatroskaTrack *track,
+ AVCodecParameters *par,
const MatroskaDemuxContext *matroska,
int *extradata_offset)
{
@@ -2886,11 +2884,15 @@ static int mkv_parse_video_codec(MatroskaTrack *track,
AVCodecParameters *par,
if (track->codec_priv.size >= 86) {
FFIOContext b;
unsigned bit_depth = AV_RB16(track->codec_priv.data + 82);
+uint32_t palette[256] = { 0 };
ffio_init_read_context(&b, track->codec_priv.data,
track->codec_priv.size);
-if (ff_get_qtpalette(codec_id, &b.pub, track->palette)) {
+if (ff_get_qtpalette(codec_id, &b.pub, palette)) {
+void *side_data = av_stream_new_side_data(st,
AV_PKT_DATA_PALETTE, AVPALETTE_SIZE);
+if (!side_data)
+return AVERROR(ENOMEM);
+memcpy(side_data, palette, AVPALETTE_SIZE);
bit_depth &= 0x1F;
-track->has_palette = 1;
}
par->bits_per_coded_sample = bit_depth;
}
@@ -2934,7 +2936,7 @@ static int mkv_parse_video(MatroskaTrack *track, AVStream
*st,
if (track->video.color_space.size == 4)
par->codec_tag = AV_RL32(track->video.color_space.data);
-ret = mkv_parse_video_codec(track, par, matroska,
+ret = mkv_parse_video_codec(st, track, par, matroska,
extradata_offset);
if (ret < 0)
return ret;
@@ -3398,30 +3400,13 @@ static int matroska_read_header(AVFormatContext *s)
/*
* Put one packet in an application-supplied AVPacket struct.
- * Returns 0 on success or -1 on failure.
+ * Returns 0 on success or < 0 (most likely AVERROR(EAGAIN)
+ * if no packet was available.
*/
static int matroska_deliver_packet(MatroskaDemuxContext *matroska,
AVPacket *pkt)
{
-if (matroska->queue.head) {
-MatroskaTrack *tracks = matroska->tracks.elem;
-MatroskaTrack *track;
-
-avpriv_packet_list_get(&matroska->queue, pkt);
-track = &tracks[pkt->stream_index];
-if (track->has_palette) {
-uint8_t *pal = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE,
AVPALETTE_SIZE);
-if (!pal) {
-av_log(matroska->ctx, AV_LOG_ERROR, "Cannot append palette to
packet\n");
-} else {
-memcpy(pal, track->palette, AVPALETTE_SIZE);
-}
-track->has_palette = 0;
-}
-return 0;
-}
-
-return -1;
+return avpriv_packet_list_get(&matroska->queue, pkt);
}
/*
--
2.34.1
___
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".
Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Anton Khirnov (12023-10-04): > It is IMO perfectly reasonable to wonder why does someone who does not > agree with the basic rules participate in the project. Or you could have given the issue just two more seconds of thought and realized that FFmpeg is a software project rather than a Nomic game, and therefore where the code goes matters more than how it is decided. So yes, it was definitely an ad-hominem attach, an attempt to smear me. But I do not care, I do not weaponize the formal rules of politeness, I leave that to my detractors, some seem to make a habit of it; I only observe with amusement that their arguments are becoming weaker and more desperate. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH 4/4] lavu/fixed_dsp: R-V V vector_fmul_window
Le keskiviikkona 4. lokakuuta 2023, 22.51.10 EEST Rémi Denis-Courmont a écrit : > +vwmul.vv v12, v16, v28 > +vwmul.vv v8, v16, v24 > +// vwnmsac.vv does _not_ exist so multiply & subtract separately > +vwmul.vv v4, v20, v24 > +vwmacc.vv v8, v20, v28 Retaining 3 whole double-width multiply vectors is really hurting here. This would be a lot smoother with just the top-halves (vsmul.vv), but then we need to round each multiplication. Of course the final results would differ slightly then, and I am not sure what that entails for the audio codecs (nor would I know how to update the x86 code). N.B.: Don't ask for benchmarks, this can't run on v0.7.1 proto-RVV hardware. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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".
[FFmpeg-devel] [PATCH] lavc/exrdsp: R-V V reoder_pixels
---
libavcodec/exrdsp.c| 4 +++-
libavcodec/exrdsp.h| 1 +
libavcodec/riscv/Makefile | 2 ++
libavcodec/riscv/exrdsp_init.c | 38 ++
libavcodec/riscv/exrdsp_rvv.S | 38 ++
5 files changed, 82 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/riscv/exrdsp_init.c
create mode 100644 libavcodec/riscv/exrdsp_rvv.S
diff --git a/libavcodec/exrdsp.c b/libavcodec/exrdsp.c
index 8259da4841..752e1eb553 100644
--- a/libavcodec/exrdsp.c
+++ b/libavcodec/exrdsp.c
@@ -51,7 +51,9 @@ av_cold void ff_exrdsp_init(ExrDSPContext *c)
c->reorder_pixels = reorder_pixels_scalar;
c->predictor= predictor_scalar;
-#if ARCH_X86
+#if ARCH_RISCV
+ff_exrdsp_init_riscv(c);
+#elif ARCH_X86
ff_exrdsp_init_x86(c);
#endif
}
diff --git a/libavcodec/exrdsp.h b/libavcodec/exrdsp.h
index aba3d3cf51..ea37c8b08e 100644
--- a/libavcodec/exrdsp.h
+++ b/libavcodec/exrdsp.h
@@ -28,6 +28,7 @@ typedef struct ExrDSPContext {
} ExrDSPContext;
void ff_exrdsp_init(ExrDSPContext *c);
+void ff_exrdsp_init_riscv(ExrDSPContext *c);
void ff_exrdsp_init_x86(ExrDSPContext *c);
#endif /* AVCODEC_EXRDSP_H */
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index cc9c13e6b6..31ad493cd3 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -10,6 +10,8 @@ RVV-OBJS-$(CONFIG_AUDIODSP) += riscv/audiodsp_rvv.o
OBJS-$(CONFIG_BSWAPDSP) += riscv/bswapdsp_init.o \
riscv/bswapdsp_rvb.o
RVV-OBJS-$(CONFIG_BSWAPDSP) += riscv/bswapdsp_rvv.o
+OBJS-$(CONFIG_EXR_DECODER) += riscv/exrdsp_init.o
+RVV-OBJS-$(CONFIG_EXR_DECODER) += riscv/exrdsp_rvv.o
OBJS-$(CONFIG_FMTCONVERT) += riscv/fmtconvert_init.o
RVV-OBJS-$(CONFIG_FMTCONVERT) += riscv/fmtconvert_rvv.o
OBJS-$(CONFIG_G722DSP) += riscv/g722dsp_init.o
diff --git a/libavcodec/riscv/exrdsp_init.c b/libavcodec/riscv/exrdsp_init.c
new file mode 100644
index 00..690a2231c5
--- /dev/null
+++ b/libavcodec/riscv/exrdsp_init.c
@@ -0,0 +1,38 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/cpu.h"
+#include "libavcodec/avcodec.h"
+#include "libavcodec/exrdsp.h"
+
+void ff_reorder_pixels_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t size);
+
+av_cold void ff_exrdsp_init_riscv(ExrDSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+c->reorder_pixels = ff_reorder_pixels_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/exrdsp_rvv.S b/libavcodec/riscv/exrdsp_rvv.S
new file mode 100644
index 00..f4a35f58ff
--- /dev/null
+++ b/libavcodec/riscv/exrdsp_rvv.S
@@ -0,0 +1,38 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+func ff_reorder_pixels_rvv, zve32x
+sraia2, a2, 1
+add t1, a1, a2
+1:
+vsetvli t0, a2, e8, m4, ta, ma
+vle8.v v0, (a1)
+sub a2, a2, t0
+vle8.v v4, (t1)
+add a1, t0, a1
+vsseg2e8.v v0, (a0)
+add t1, t0, t1
+sh1add a0, t0, a0
+bneza2, 1b
+
+ret
+endfunc
--
2.42.0
___
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
Re: [FFmpeg-devel] [PATCH] aacdec: padding skip improvements
> On Oct 4, 2023, at 7:37 PM, Lynne wrote: > > 2048 is just more widely encountered. I'm posting these patches > to get an opinion: > - do we cut nothing at all (currently) > - do we cut 1024 (required by the standard/algorithm, and currently what our > AAC ENcoder outputs) > - do we cut 2048 (what is most widely expected) > > My preference would be 1024. Note: this is only for raw AAC > streams outside of a container. Streams inside of a container are currently > correctly cut, with this value being overridden. I think it would be good by default to have the ffmpeg encoder and decoder roundtrip correctly, and then leverage an option to specify a different padding if a different encoder was used. I think the important property is that if we take a PCM input, encode it to raw AAC with ffmpeg and then decode it to PCM output that we have the same number of PCM samples and they're all properly aligned. Since we can't correctly handle unknown encoders (that might be using 2048 or 2112 priming samples) for the option to override the priming samples should be used in that case (which could also be set to 0 if someone really wants potentially distorted output before the decoder was properly primed). - Cosmin ___ 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".
Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
On Thu, Oct 5, 2023 at 8:55 AM Nicolas George wrote: > Anton Khirnov (12023-10-04): > > It is IMO perfectly reasonable to wonder why does someone who does not > > agree with the basic rules participate in the project. > > Or you could have given the issue just two more seconds of thought and > realized that FFmpeg is a software project rather than a Nomic game, and > therefore where the code goes matters more than how it is decided. Code never matters more than people. It's people who make the community and it's the community who writes the code or who decides what belongs to the project -- never a single individual. There is a lot of content on the web that exemplifies that in professional environments: - https://hackernoon.com/thoughts-on-software-development-heroes-5ec656c2e31a How To Prevent Coding "Heroes" From Destroying The Team - https://leaddev.com/culture-engagement-motivation/eliminating-hero-culture-software-engineering-teams Eliminating hero culture in software engineering teams - https://medium.com/@LuiscaGuerrero/the-myth-of-the-hero-developer-70870e76c00b The myth of the Hero developer I am as puzzled as you are why we let this kind of abuse happen in this community, so claiming a CoC violation for a legitimate question seems a bit ridiculous in my opinion. Just my 2 cents -- Vittorio ___ 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".
Re: [FFmpeg-devel] [PATCH] aacdec: padding skip improvements
Oct 5, 2023, 14:24 by derek.buitenh...@gmail.com: > On 10/3/2023 5:07 AM, Lynne wrote: > >> Despite this being a standard MDCT-based codec with a frame size of 1024, >> hence a delay of 1024 samples at the start, all major encoders, excluding >> faac and FFmpeg, use 2048 samples of padding. >> > > Apple's uses 2112. > I counted 2048 with af-convert. Are you referring to qaac? ___ 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".
Re: [FFmpeg-devel] [PATCH v3] avformat/mov: Add support for demuxing still HEIC images
On Wed, Oct 4, 2023 at 12:40 PM Vignesh Venkatasubramanian via ffmpeg-devel
wrote:
> They are similar to AVIF images (both use the HEIF container).
> The only additional work needed is to parse the hvcC box and put
> it in the extradata.
>
> With this patch applied, ffmpeg (when built with an HEVC decoder)
> is able to decode the files in
> https://github.com/nokiatech/heif/tree/gh-pages/content/images
>
> Also add a couple of fate tests with samples from
> https://github.com/nokiatech/heif_conformance/tree/master/conformance_files
>
> Partially fixes trac ticket #6521.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavformat/isom.h| 2 +
> libavformat/mov.c | 41 ++-
> tests/fate/mov.mak| 6 +++
> .../fate/mov-heic-demux-still-image-1-item| 11 +
> .../mov-heic-demux-still-image-multiple-items | 11 +
> 5 files changed, 70 insertions(+), 1 deletion(-)
> create mode 100644 tests/ref/fate/mov-heic-demux-still-image-1-item
> create mode 100644
> tests/ref/fate/mov-heic-demux-still-image-multiple-items
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 3d375d7a46..b30b9da65e 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -327,6 +327,8 @@ typedef struct MOVContext {
> int64_t extent_offset;
> } *avif_info;
> int avif_info_size;
> +int64_t hvcC_offset;
> +int hvcC_size;
> int interleaved_read;
> } MOVContext;
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 294c864fbd..d3747022bd 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1218,7 +1218,8 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> c->isom = 1;
> av_log(c->fc, AV_LOG_DEBUG, "ISO: File Type Major Brand:
> %.4s\n",(char *)&type);
> av_dict_set(&c->fc->metadata, "major_brand", type, 0);
> -c->is_still_picture_avif = !strncmp(type, "avif", 4);
> +c->is_still_picture_avif = !strncmp(type, "avif", 4) ||
> + !strncmp(type, "mif1", 4);
> minor_ver = avio_rb32(pb); /* minor version */
> av_dict_set_int(&c->fc->metadata, "minor_version", minor_ver, 0);
>
> @@ -4911,6 +4912,19 @@ static int avif_add_stream(MOVContext *c, int
> item_id)
> st->priv_data = sc;
> st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> st->codecpar->codec_id = AV_CODEC_ID_AV1;
> +if (c->hvcC_offset >= 0) {
> +int ret;
> +int64_t pos = avio_tell(c->fc->pb);
> +st->codecpar->codec_id = AV_CODEC_ID_HEVC;
> +if (avio_seek(c->fc->pb, c->hvcC_offset, SEEK_SET) !=
> c->hvcC_offset) {
> +av_log(c->fc, AV_LOG_ERROR, "Failed to seek to hvcC data.\n");
> +return AVERROR_UNKNOWN;
> +}
> +ret = ff_get_extradata(c->fc, st->codecpar, c->fc->pb,
> c->hvcC_size);
> +if (ret < 0)
> +return ret;
> +avio_seek(c->fc->pb, pos, SEEK_SET);
> +}
> sc->ffindex = st->index;
> c->trak_index = st->index;
> st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
> @@ -4953,6 +4967,8 @@ static int avif_add_stream(MOVContext *c, int
> item_id)
>
> static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> {
> +c->hvcC_offset = -1;
> +c->hvcC_size = 0;
> while (atom.size > 8) {
> uint32_t tag;
> if (avio_feof(pb))
> @@ -7827,6 +7843,28 @@ static int mov_read_iloc(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return atom.size;
> }
>
> +static int mov_read_iprp(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +int size = avio_rb32(pb);
> +if (avio_rl32(pb) != MKTAG('i','p','c','o'))
> +return AVERROR_INVALIDDATA;
> +size -= 8;
> +while (size > 0) {
> +int sub_size, sub_type;
> +sub_size = avio_rb32(pb);
> +sub_type = avio_rl32(pb);
> +sub_size -= 8;
> +size -= sub_size + 8;
> +if (sub_type == MKTAG('h','v','c','C')) {
> +c->hvcC_offset = avio_tell(pb);
> +c->hvcC_size = sub_size;
> +break;
> +}
> +avio_skip(pb, sub_size);
> +}
> +return atom.size;
> +}
> +
> static const MOVParseTableEntry mov_default_parse_table[] = {
> { MKTAG('A','C','L','R'), mov_read_aclr },
> { MKTAG('A','P','R','G'), mov_read_avid },
> @@ -7934,6 +7972,7 @@ static const MOVParseTableEntry
> mov_default_parse_table[] = {
> { MKTAG('p','c','m','C'), mov_read_pcmc }, /* PCM configuration box */
> { MKTAG('p','i','t','m'), mov_read_pitm },
> { MKTAG('e','v','c','C'), mov_read_glbl },
> +{ MKTAG('i','p','r','p'), mov_read_iprp },
> { 0, NULL }
> };
>
> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> index 6cb493ceab..a2d3cc8013 100644
> --- a/tests/fate/mov.mak
> +++ b/tests/fate/mov.mak
> @@ -18,6 +18,8 @@ FATE_MOV = fate-mov-3elist \
> fate-mov-neg-firstpts-discard-frames \
> fate
Re: [FFmpeg-devel] [PATCH] avformat/mov: Add support for demuxing still HEIC images
Vignesh Venkat via ffmpeg-devel: > On Tue, Oct 3, 2023 at 9:40 PM Vittorio Giovara > wrote: >> >> >> >> On Wed, Oct 4, 2023 at 12:02 AM Vignesh Venkat via ffmpeg-devel >> wrote: >>> >>> On Tue, Oct 3, 2023 at 6:32 PM Vittorio Giovara >>> wrote: On Tue, Oct 3, 2023 at 8:30 PM Steven Liu wrote: >>> 2.42.0.515.g380fc7ccd1-goog >>> >> >> Any comments/objections on merging this? > > > Can this patch support tiled hevc coded or sequence heif？= > I believe that will be possible only after AVStreamGroup is implemented. >>> >>> Yes, this patch only supports still HEIC images that don't have alpha >>> and grids (tiles). >>> >>> Tiles and Alpha support will be possible only after AVStreamGroup is >>> implemented. I will look into HEIC sequences in a follow-up. >>> Vignesh is there a sample available? Could we add a test? >>> >>> I tested it from the files in >>> https://github.com/nokiatech/heif/tree/gh-pages/content/images. I am >>> not sure about HEVC licensing and if we are allowed to copy some of >>> those files in the ffmpeg fate server. Would generating a random image >>> with ffmpeg and encoding it as HEIC be good enough? >> >> >> I would prefer a real world example and FATE has a bunch of conformance >> samples already. >> Adding the ones from https://github.com/nokiatech/heif_conformance shouldn't >> be a problem. >> Ideally the sample test should be added to this same patch. > > Great, i have added two samples. Can you please upload C002.heic and > C003.heic from the heif_conformance repository to the fate server > under the "heif-conformance" sub-directory. I have also attached those > two files in this email for reference. I will update the patch with > the fate tests. > Why are you intend to add so big files when the linked repo contains smaller files? All five multilayer files are below 20KB each; multilayer005.heic is even only 4.5KB. MIAF002.heic (8.6KB) and MIAF003.heic (13.5KB) are also quite small. C025.heic (19.4KB) and C053.heic (14.2KB) are also quite small and there are also other samples in the 50KB-60KB range (C017.heic, C018.heic, C019.heic, C020.heic, C041.heic). Besides taking up less diskspace, smaller files will likely be faster to decode (which is particularly advantageous for people like me who run FATE a lot). - Andreas ___ 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".
Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Hi Vittorio On Thu, Oct 05, 2023 at 01:32:11PM -0400, Vittorio Giovara wrote: > On Thu, Oct 5, 2023 at 8:55 AM Nicolas George wrote: > > > Anton Khirnov (12023-10-04): > > > It is IMO perfectly reasonable to wonder why does someone who does not > > > agree with the basic rules participate in the project. > > > > Or you could have given the issue just two more seconds of thought and > > realized that FFmpeg is a software project rather than a Nomic game, and > > therefore where the code goes matters more than how it is decided. > > > Code never matters more than people. It's people who make the community and > it's the community who writes the code or who decides what belongs to the > project -- never a single individual. > > There is a lot of content on the web that exemplifies that in professional > environments: > - > https://hackernoon.com/thoughts-on-software-development-heroes-5ec656c2e31a > How To Prevent Coding "Heroes" From Destroying The Team > - > https://leaddev.com/culture-engagement-motivation/eliminating-hero-culture-software-engineering-teams > Eliminating hero culture in software engineering teams > - > https://medium.com/@LuiscaGuerrero/the-myth-of-the-hero-developer-70870e76c00b > The myth of the Hero developer > > I am as puzzled as you are why we let this kind of abuse happen in this > community, so claiming a CoC violation for a legitimate question seems a > bit ridiculous in my opinion. If people in a team start asking each other "why are you part of the team" no matter in what form or in what context or under what argumentation. Thats not a good thing. A well working team doesnt do that except maybe as a joke If that is technically a CoC violation is really not the point. I could elaboarte more here, I mean lets assume someone has an actual reason or contradiction to his membership in the project. Maybe ones employer doesnt allow it, or some other arbitraray reason The question "why are you here if X" surely is legitimate from a logic point of view but it none the less is a question that has no place to be asked. logic legitimacy != moral legitimacy as in "Ohh i know skynet doesnt allow you to work on FFmpeg, why are you here?" Thats not a question thats in the interrest of the FFmpeg team. or another example, "Ohh you just said you hate multimedia, why do you continue to work on FFmpeg?" So I stand by my oppinion that such questions are inappropriate. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Vittorio Giovara (12023-10-05): > There is a lot of content on the web that exemplifies that in professional > environments: Well, good thing FFmpeg is not a professional environment. -- Nicolas George signature.asc Description: PGP signature ___ 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".
[FFmpeg-devel] [PATCH 1/5] avcodec/bonk: Fix undefined overflow in predictor_calc_error()
Fixes: signed integer overflow: -2146469728 - 1488954 cannot be represented in
type 'int'
Fixes:
62490/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BONK_fuzzer-5612782399389696
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/bonk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/bonk.c b/libavcodec/bonk.c
index 6cd6a0af619..65679e5fb65 100644
--- a/libavcodec/bonk.c
+++ b/libavcodec/bonk.c
@@ -270,7 +270,7 @@ static inline int shift(int a, int b)
static int predictor_calc_error(int *k, int *state, int order, int error)
{
-int i, x = error - shift_down(k[order-1] * (unsigned)state[order-1],
LATTICE_SHIFT);
+int i, x = error - (unsigned)shift_down(k[order-1] *
(unsigned)state[order-1], LATTICE_SHIFT);
int *k_ptr = &(k[order-2]),
*state_ptr = &(state[order-2]);
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 2/5] avformat/usmdec: do not return 0 when no packet was produced
Fixes: Assertion pkt->stream_index < (unsigned)s->nb_streams && "Invalid stream index.\n" failed at libavformat/demux.c:617 Fixes: 62498/clusterfuzz-testcase-minimized-ffmpeg_dem_USM_fuzzer-4734740995112960 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/usmdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/usmdec.c b/libavformat/usmdec.c index 1665eb8e551..b0079a1230c 100644 --- a/libavformat/usmdec.c +++ b/libavformat/usmdec.c @@ -361,7 +361,7 @@ static int64_t parse_chunk(AVFormatContext *s, AVIOContext *pb, ret = avio_skip(pb, FFMAX(0, chunk_size - (ret - chunk_start))); if (ret < 0) return ret; -return 0; +return AVERROR(EAGAIN); } static int usm_read_packet(AVFormatContext *s, AVPacket *pkt) -- 2.17.1 ___ 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".
[FFmpeg-devel] [PATCH 3/5] avcodec/cbs_h2645: Fix showing bits at the end in cbs_read_ue_golomb()
Fixes: Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:375
Fixes:
62617/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5156555663998976
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_h2645.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 0a1c8ea4266..fbfd671efea 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -43,7 +43,7 @@ static int cbs_read_ue_golomb(CodedBitstreamContext *ctx,
GetBitContext *gbc,
max_length = FFMIN(get_bits_left(gbc), 32);
-leading_bits = show_bits_long(gbc, max_length);
+leading_bits = max_length ? show_bits_long(gbc, max_length) : 0;
if (leading_bits == 0) {
if (max_length >= 32) {
av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid ue-golomb code at "
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 4/5] avcodec/cbs_h2645: Fix showing bits at the end in cbs_read_se_golomb()
Fixes: Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:375
Fixes:
62618/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5145745046765568
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_h2645.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index fbfd671efea..a7b9f3cef33 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -93,7 +93,7 @@ static int cbs_read_se_golomb(CodedBitstreamContext *ctx,
GetBitContext *gbc,
max_length = FFMIN(get_bits_left(gbc), 32);
-leading_bits = show_bits_long(gbc, max_length);
+leading_bits = max_length ? show_bits_long(gbc, max_length) : 0;
if (leading_bits == 0) {
if (max_length >= 32) {
av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid se-golomb code at "
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 5/5] avcodec/xvididct: Make c* unsigned to avoid undefined overflows
Fixes: signed integer overflow: 1496950099 + 728014168 cannot be represented in
type 'int'
Fixes:
62667/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-6511785170305024
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/xvididct.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/xvididct.c b/libavcodec/xvididct.c
index dcea32210a2..01072d80ab7 100644
--- a/libavcodec/xvididct.c
+++ b/libavcodec/xvididct.c
@@ -56,13 +56,13 @@ static const int TAB35[] = { 26722, 25172, 22654, 19266,
15137, 10426, 5315 };
static int idct_row(short *in, const int *const tab, int rnd)
{
-const int c1 = tab[0];
-const int c2 = tab[1];
-const int c3 = tab[2];
-const int c4 = tab[3];
-const int c5 = tab[4];
-const int c6 = tab[5];
-const int c7 = tab[6];
+const unsigned c1 = tab[0];
+const unsigned c2 = tab[1];
+const unsigned c3 = tab[2];
+const unsigned c4 = tab[3];
+const unsigned c5 = tab[4];
+const unsigned c6 = tab[5];
+const unsigned c7 = tab[6];
const int right = in[5] | in[6] | in[7];
const int left = in[1] | in[2] | in[3];
@@ -102,8 +102,8 @@ static int idct_row(short *in, const int *const tab, int
rnd)
return 0;
}
} else if (!(left | right)) {
-const int a0 = (rnd + c4 * (in[0] + in[4])) >> ROW_SHIFT;
-const int a1 = (rnd + c4 * (in[0] - in[4])) >> ROW_SHIFT;
+const int a0 = (int)(rnd + c4 * (in[0] + in[4])) >> ROW_SHIFT;
+const int a1 = (int)(rnd + c4 * (in[0] - in[4])) >> ROW_SHIFT;
in[0] = a0;
in[3] = a0;
--
2.17.1
___
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".
Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Le torstaina 5. lokakuuta 2023, 21.33.16 EEST Michael Niedermayer a écrit : > Hi Vittorio > > On Thu, Oct 05, 2023 at 01:32:11PM -0400, Vittorio Giovara wrote: > > On Thu, Oct 5, 2023 at 8:55 AM Nicolas George wrote: > > > Anton Khirnov (12023-10-04): > > > > It is IMO perfectly reasonable to wonder why does someone who does not > > > > agree with the basic rules participate in the project. > > > > > > Or you could have given the issue just two more seconds of thought and > > > realized that FFmpeg is a software project rather than a Nomic game, and > > > therefore where the code goes matters more than how it is decided. > > > > Code never matters more than people. It's people who make the community > > and > > it's the community who writes the code or who decides what belongs to the > > project -- never a single individual. > > > > There is a lot of content on the web that exemplifies that in professional > > environments: > > - > > https://hackernoon.com/thoughts-on-software-development-heroes-5ec656c2e31 > > a > > How To Prevent Coding "Heroes" From Destroying The Team > > - > > https://leaddev.com/culture-engagement-motivation/eliminating-hero-culture > > -software-engineering-teams Eliminating hero culture in software > > engineering teams > > - > > https://medium.com/@LuiscaGuerrero/the-myth-of-the-hero-developer-70870e76 > > c00b The myth of the Hero developer > > > > I am as puzzled as you are why we let this kind of abuse happen in this > > community, so claiming a CoC violation for a legitimate question seems a > > bit ridiculous in my opinion. > > If people in a team start asking each other "why are you part of the team" > no matter in what form or in what context or under what argumentation. He has made no secret that he does not _want_ to be in the same team. A few months ago, he told several people here to (and I quote) "go fork [themselves]". It hardly gets more explicitly than that, does it not? It is also much more offensive than Kieran's question. Surely, you have noticed that it reads very much like a major insult. In a way, I suppose that I get your point: *you* do want everybody in the same team. And he ostensibly wants to be in your "team". But that is not transitive: he does not want Anton, Kieran, Vittorio, Tomas, and a whole lot more in that hypothetical team, or at least not on the terms that Anton refereed to as the "fundamental rules" from some years ago. If you do not agree with Nicolas on this point, then admonishing Kieran and Vittorio about alleged CoC violations is not conducive to resolving your disagreement, nor is preaching to them about an united FFmpeg team. I understand that you do not like this situation. Nobody does. But you are addressing the wrong people, and ultimately adding fuel to the fire, even if you do not mean to. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Rémi Denis-Courmont (12023-10-05): > He has made no secret that he does not _want_ to be in the same team. A few > months ago, he told several people here to (and I quote) "go fork > [themselves]". Honesty would have involved quoting the “if” before that. -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/svt-av1: Set force_key_frames only when gop_size == 1
Hi,
On Wed, Oct 4, 2023 at 5:05 PM Vignesh Venkat wrote:
> On Wed, Oct 4, 2023 at 10:23 AM Ronald S. Bultje
> wrote:
> >
> > Hi,
> >
> > On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via
> ffmpeg-devel wrote:
> >>
> >> SVT-AV1 does not support requesting keyframes at arbitrary points
> >> by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
> >> to 1 only when gop_size == 1.
> >>
> >> Please see the comments in
> >> https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more
> >> details.
> >>
> >> Signed-off-by: Vignesh Venkatasubramanian
> >> ---
> >> libavcodec/libsvtav1.c | 9 +++--
> >> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> >> index 5015169244..8d2c7f3be4 100644
> >> --- a/libavcodec/libsvtav1.c
> >> +++ b/libavcodec/libsvtav1.c
> >> @@ -253,8 +253,13 @@ static int
> config_enc_params(EbSvtAv1EncConfiguration *param,
> >> // In order for SVT-AV1 to force keyframes by setting pic_type to
> >> // EB_AV1_KEY_PICTURE on any frame, force_key_frames has to be
> set. Note
> >> // that this does not force all frames to be keyframes (it only
> forces a
> >> -// keyframe with pic_type is set to EB_AV1_KEY_PICTURE).
> >> -param->force_key_frames = 1;
> >> +// keyframe with pic_type is set to EB_AV1_KEY_PICTURE). As of
> now, SVT-AV1
> >> +// does not support arbitrary keyframe requests by setting
> pic_type to
> >> +// EB_AV1_KEY_PICTURE, so it is done only when gop_size == 1.
> >> +// FIXME: When SVT-AV1 supports arbitrary keyframe requests, this
> code needs
> >> +// to be updated to set force_key_frames accordingly.
> >> +if (avctx->gop_size == 1)
> >> +param->force_key_frames = 1;
> >>
> >> if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> >> param->frame_rate_numerator = avctx->framerate.num;
> >> --
> >> 2.42.0.582.g8ccd20d70d-goog
> >
> >
> > Seems reasonable to me.
> >
> > Can you merge, or should I merge for you?
> >
>
> Thanks Ronald. I don't have commit access. Can you please merge it?
>
Done.
Ronald
___
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".
[FFmpeg-devel] [PATCH] avfilter/libvmaf: remove deprecated options
Hi, Removal of deprecated libvmaf filter options. These options have been deprecated since 3d29724c008d8f27fecf85757152789b074e8ef9 (Jan 23, 2022). Patch attached. Thanks, Kyle 0001-avfilter-libvmaf-remove-deprecated-options.patch Description: Binary data ___ 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".
[FFmpeg-devel] [PATCH] hwcontext_vulkan: add the VK_IMAGE_USAGE_SAMPLED_BIT bit to new images
This fixes filtering on Nvidia.
Patch attached.
>From 2ea0d50049bae792477c53780b3cfd0e3863d914 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Thu, 5 Oct 2023 20:25:33 +0200
Subject: [PATCH] hwcontext_vulkan: properly support STORAGE usage for
mutliplane images
Fixes multiplane support on Nvidia.
Also, remove the ENCODE usage, even if the driver signals it as supported.
Currently, it's not used, and when it is used, it'll be gated behind
two extension checks.
---
libavfilter/vulkan_filter.c | 24 +++-
libavutil/hwcontext_vulkan.c | 36
2 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/libavfilter/vulkan_filter.c b/libavfilter/vulkan_filter.c
index b4d8f952b5..f3f40465be 100644
--- a/libavfilter/vulkan_filter.c
+++ b/libavfilter/vulkan_filter.c
@@ -42,18 +42,23 @@ int ff_vk_filter_init_context(AVFilterContext *avctx, FFVulkanContext *s,
vk_frames = frames_ctx->hwctx;
vk_dev = device_ctx->hwctx;
-/* Basic format validation */
+/* Width and height mismatch */
if (width != frames_ctx->width ||
-height != frames_ctx->height ||
-sw_format != frames_ctx->sw_format ||
-(vk_frames->tiling != VK_IMAGE_TILING_LINEAR &&
- vk_frames->tiling != VK_IMAGE_TILING_OPTIMAL) ||
-!(vk_frames->usage & VK_IMAGE_USAGE_SAMPLED_BIT)) {
+height != frames_ctx->height)
+goto skip;
+
+/* Format mismatch */
+if (sw_format != frames_ctx->sw_format)
goto skip;
-}
-if (vk_frames->usage & VK_IMAGE_USAGE_STORAGE_BIT)
-goto accept;
+/* Unusual tiling mismatch. Don't let linear through either. */
+if (vk_frames->tiling != VK_IMAGE_TILING_OPTIMAL)
+goto skip;
+
+/* Usage mismatch */
+if ((vk_frames->usage & (VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_STORAGE_BIT)) !=
+(VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_STORAGE_BIT))
+goto skip;
s->extensions = ff_vk_extensions_to_mask(vk_dev->enabled_dev_extensions,
vk_dev->nb_enabled_dev_extensions);
@@ -110,6 +115,7 @@ accept:
vk_frames = frames_ctx->hwctx;
vk_frames->tiling = VK_IMAGE_TILING_OPTIMAL;
vk_frames->usage = VK_IMAGE_USAGE_SAMPLED_BIT |
+VK_IMAGE_USAGE_STORAGE_BIT |
VK_IMAGE_USAGE_TRANSFER_SRC_BIT |
VK_IMAGE_USAGE_TRANSFER_DST_BIT;
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index c676f4fc57..b955ec483e 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -282,9 +282,11 @@ FN_MAP_TO(VkImageUsageFlags, usage, VkFormatFeatureFlagBits2, feats)
static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, enum AVPixelFormat p,
VkImageTiling tiling,
- VkFormat fmts[AV_NUM_DATA_POINTERS],
- int *nb_images, VkImageAspectFlags *aspect,
- VkImageUsageFlags *supported_usage, int disable_multiplane)
+ VkFormat fmts[AV_NUM_DATA_POINTERS], /* Output format list */
+ int *nb_images, /* Output number of images */
+ VkImageAspectFlags *aspect, /* Output aspect */
+ VkImageUsageFlags *supported_usage, /* Output supported usage */
+ int disable_multiplane, int need_storage)
{
AVVulkanDeviceContext *hwctx = dev_ctx->hwctx;
VulkanDevicePriv *priv = dev_ctx->internal->priv;
@@ -301,6 +303,7 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, enum AVPixelFormat p,
};
VkFormatFeatureFlagBits2 feats_primary, feats_secondary;
int basics_primary = 0, basics_secondary = 0;
+int storage_primary = 0, storage_secondary = 0;
vk->GetPhysicalDeviceFormatProperties2(hwctx->phys_dev,
vk_formats_list[i].vkf,
@@ -310,6 +313,7 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, enum AVPixelFormat p,
prop.formatProperties.linearTilingFeatures :
prop.formatProperties.optimalTilingFeatures;
basics_primary = (feats_primary & basic_flags) == basic_flags;
+storage_primary = !!(feats_primary & VK_FORMAT_FEATURE_2_STORAGE_IMAGE_BIT);
if (vk_formats_list[i].vkf != vk_formats_list[i].fallback[0]) {
vk->GetPhysicalDeviceFormatProperties2(hwctx->phys_dev,
@@ -319,11 +323,15 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, enum AVPixelFormat p,
prop.formatProperties.linea
Re: [FFmpeg-devel] [PATCH] hwcontext_vulkan: add the VK_IMAGE_USAGE_SAMPLED_BIT bit to new images
On Thu, 5 Oct 2023 23:26:38 +0200 (CEST) Lynne wrote: > This fixes filtering on Nvidia. > > Patch attached. > Tested locally. Filtering works and vulkan validation passes. Ship it! --phil ___ 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".
Re: [FFmpeg-devel] [PATCH] hwcontext_vulkan: add the VK_IMAGE_USAGE_SAMPLED_BIT bit to new images
Oct 5, 2023, 23:28 by ffmpeg-devel@ffmpeg.org: > On Thu, 5 Oct 2023 23:26:38 +0200 (CEST) > Lynne wrote: > >> This fixes filtering on Nvidia. >> >> Patch attached. >> > > Tested locally. Filtering works and vulkan validation passes. > > Ship it! > Thanks, tested everywhere I could think of. Works, so pushed. Now Nvidia users can enjoy filtering! ___ 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".
Re: [FFmpeg-devel] [PATCH v2] vulkan_hevc: handle non-contiguous SPS/PPS/VPS ids
Sep 30, 2023, 18:57 by ffmpeg-devel@ffmpeg.org:
> Some clips (i.e. SLIST_B_Sony_9) will use PPS 0 and 8, before PPS 1-7.
> vulkan_hevc expects {sps,pps,vps}_list to be filled in order, which
> causes PPS 8 to not be added to the Vulkan session params when it is
> being used by a picture.
>
> This removes the expectation that these lists are filled in order. The
> indicies into vps_list are saved since there are multiple usages of it.
>
> This also fixes a bug with some clips (i.e. PPS_A_qualcomm_7) which use
> all 64 available PPS slots, causing the old loop to think there are more
> than 64 PPS-es.
> ---
> libavcodec/vulkan_hevc.c | 46 +++-
> 1 file changed, 27 insertions(+), 19 deletions(-)
>
> diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
> index 52f223ceb2..9685ec14c8 100644
> --- a/libavcodec/vulkan_hevc.c
> +++ b/libavcodec/vulkan_hevc.c
> @@ -70,6 +70,7 @@ typedef struct HEVCHeaderSet {
>
> static int alloc_hevc_header_structs(FFVulkanDecodeContext *s,
> int nb_vps,
> + const int
> vps_list_idx[HEVC_MAX_VPS_COUNT],
> AVBufferRef * const vps_list[HEVC_MAX_VPS_COUNT])
> {
> uint8_t *data_ptr;
> @@ -77,7 +78,7 @@ static int alloc_hevc_header_structs(FFVulkanDecodeContext
> *s,
>
> size_t buf_size = sizeof(HEVCHeaderSet) + nb_vps*sizeof(HEVCHeaderVPS);
> for (int i = 0; i < nb_vps; i++) {
> -const HEVCVPS *vps = (const HEVCVPS *)vps_list[i]->data;
> +const HEVCVPS *vps = (const HEVCVPS
> *)vps_list[vps_list_idx[i]]->data;
> buf_size += sizeof(HEVCHeaderVPSSet)*vps->vps_num_hrd_parameters;
> }
>
> @@ -96,7 +97,7 @@ static int alloc_hevc_header_structs(FFVulkanDecodeContext
> *s,
> hdr->hvps = (HEVCHeaderVPS *)(data_ptr + sizeof(HEVCHeaderSet));
> data_ptr += sizeof(HEVCHeaderSet) + nb_vps*sizeof(HEVCHeaderVPS);
> for (int i = 0; i < nb_vps; i++) {
> -const HEVCVPS *vps = (const HEVCVPS *)vps_list[i]->data;
> +const HEVCVPS *vps = (const HEVCVPS
> *)vps_list[vps_list_idx[i]]->data;
> hdr->hvps[i].sls = (HEVCHeaderVPSSet *)data_ptr;
> data_ptr += sizeof(HEVCHeaderVPSSet)*vps->vps_num_hrd_parameters;
> }
> @@ -655,13 +656,15 @@ static int vk_hevc_create_params(AVCodecContext *avctx,
> AVBufferRef **buf)
> .videoSessionParametersTemplate = NULL,
> };
>
> -int nb_vps = 0;
> HEVCHeaderSet *hdr;
> +int nb_vps = 0;
> +int vps_list_idx[HEVC_MAX_VPS_COUNT];
>
> -for (int i = 0; h->ps.vps_list[i]; i++)
> -nb_vps++;
> +for (int i = 0; i < HEVC_MAX_VPS_COUNT; i++)
> +if (h->ps.vps_list[i])
> +vps_list_idx[nb_vps++] = i;
>
> -err = alloc_hevc_header_structs(dec, nb_vps, h->ps.vps_list);
> +err = alloc_hevc_header_structs(dec, nb_vps, vps_list_idx,
> h->ps.vps_list);
> if (err < 0)
> return err;
>
> @@ -672,26 +675,31 @@ static int vk_hevc_create_params(AVCodecContext *avctx,
> AVBufferRef **buf)
> h265_params_info.pStdVPSs = hdr->vps;
>
> /* SPS list */
> -for (int i = 0; h->ps.sps_list[i]; i++) {
> -const HEVCSPS *sps_l = (const HEVCSPS *)h->ps.sps_list[i]->data;
> -set_sps(sps_l, i, &hdr->hsps[i].scaling, &hdr->hsps[i].vui_header,
> -&hdr->hsps[i].vui, &hdr->sps[i], hdr->hsps[i].nal_hdr,
> -hdr->hsps[i].vcl_hdr, &hdr->hsps[i].ptl, &hdr->hsps[i].dpbm,
> -&hdr->hsps[i].pal, hdr->hsps[i].str, &hdr->hsps[i].ltr);
> -h265_params_info.stdSPSCount++;
> +for (int i = 0; i < HEVC_MAX_SPS_COUNT; i++) {
> +if (h->ps.sps_list[i]) {
> +const HEVCSPS *sps_l = (const HEVCSPS *)h->ps.sps_list[i]->data;
> +int idx = h265_params_info.stdSPSCount++;
> +set_sps(sps_l, i, &hdr->hsps[idx].scaling,
> &hdr->hsps[idx].vui_header,
> +&hdr->hsps[idx].vui, &hdr->sps[idx],
> hdr->hsps[idx].nal_hdr,
> +hdr->hsps[idx].vcl_hdr, &hdr->hsps[idx].ptl,
> &hdr->hsps[idx].dpbm,
> +&hdr->hsps[idx].pal, hdr->hsps[idx].str,
> &hdr->hsps[idx].ltr);
> +}
> }
>
> /* PPS list */
> -for (int i = 0; h->ps.pps_list[i]; i++) {
> -const HEVCPPS *pps_l = (const HEVCPPS *)h->ps.pps_list[i]->data;
> -const HEVCSPS *sps_l = (const HEVCSPS
> *)h->ps.sps_list[pps_l->sps_id]->data;
> -set_pps(pps_l, sps_l, &hdr->hpps[i].scaling, &hdr->pps[i],
> &hdr->hpps[i].pal);
> -h265_params_info.stdPPSCount++;
> +for (int i = 0; i < HEVC_MAX_PPS_COUNT; i++) {
> +if (h->ps.pps_list[i]) {
> +const HEVCPPS *pps_l = (const HEVCPPS *)h->ps.pps_list[i]->data;
> +const HEVCSPS *sps_l = (const HEVCSPS
> *)h->ps.sps_list[pps_l->sps_id]->data;
> +int idx = h265_params_info.stdPPSCount++;
> +set_pps(pps_l, sps_l, &hdr->hpps[idx].scaling,
> +&hdr->pps[idx], &hdr->hpps[idx].pal);
> +}
> }
>
> /* VPS list */
> for (int i = 0; i < nb_vps; i++) {
> -
Re: [FFmpeg-devel] [PATCH] avformat/mov: Add support for demuxing still HEIC images
On Thu, Oct 5, 2023 at 10:58 AM Andreas Rheinhardt wrote: > > Vignesh Venkat via ffmpeg-devel: > > On Tue, Oct 3, 2023 at 9:40 PM Vittorio Giovara > > wrote: > >> > >> > >> > >> On Wed, Oct 4, 2023 at 12:02 AM Vignesh Venkat via ffmpeg-devel > >> wrote: > >>> > >>> On Tue, Oct 3, 2023 at 6:32 PM Vittorio Giovara > >>> wrote: > > On Tue, Oct 3, 2023 at 8:30 PM Steven Liu > wrote: > > >>> 2.42.0.515.g380fc7ccd1-goog > >>> > >> > >> Any comments/objections on merging this? > > > > > > Can this patch support tiled hevc coded or sequence heif？= > > > > I believe that will be possible only after AVStreamGroup is implemented. > > >>> > >>> Yes, this patch only supports still HEIC images that don't have alpha > >>> and grids (tiles). > >>> > >>> Tiles and Alpha support will be possible only after AVStreamGroup is > >>> implemented. I will look into HEIC sequences in a follow-up. > >>> > Vignesh is there a sample available? Could we add a test? > >>> > >>> I tested it from the files in > >>> https://github.com/nokiatech/heif/tree/gh-pages/content/images. I am > >>> not sure about HEVC licensing and if we are allowed to copy some of > >>> those files in the ffmpeg fate server. Would generating a random image > >>> with ffmpeg and encoding it as HEIC be good enough? > >> > >> > >> I would prefer a real world example and FATE has a bunch of conformance > >> samples already. > >> Adding the ones from https://github.com/nokiatech/heif_conformance > >> shouldn't be a problem. > >> Ideally the sample test should be added to this same patch. > > > > Great, i have added two samples. Can you please upload C002.heic and > > C003.heic from the heif_conformance repository to the fate server > > under the "heif-conformance" sub-directory. I have also attached those > > two files in this email for reference. I will update the patch with > > the fate tests. > > > > Why are you intend to add so big files when the linked repo contains > smaller files? All five multilayer files are below 20KB each; > multilayer005.heic is even only 4.5KB. MIAF002.heic (8.6KB) and > MIAF003.heic (13.5KB) are also quite small. C025.heic (19.4KB) and > C053.heic (14.2KB) are also quite small and there are also other samples > in the 50KB-60KB range (C017.heic, C018.heic, C019.heic, C020.heic, > C041.heic). Besides taking up less diskspace, smaller files will likely > be faster to decode (which is particularly advantageous for people like > me who run FATE a lot). > There is an excel sheet in the samples github repository that explains the features of each of those files. I picked the files with the simplest features (single item and multi-item) since those are the only two files that I know for certain the current ffmpeg parser can parse as-is. The multi-layer files that you mention may work, but i am not sure if we are handling those layers the right way. So adding something that I am not sure if it has the right behavior or not to a fate test didn't seem right. Also, the fate test only demuxes the files (using -c copy) and does not do any decoding since it tests the parser and not the hevc decoder. So decoding time is not a concern. I do understand the concern about disk-space though. I can probably make a random file that is smaller, but I also thought it was better to use files from an existing conformance repository. Please let me know if that is reasonable. > - Andreas > > ___ > 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". -- Vignesh ___ 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".
Re: [FFmpeg-devel] [PATCH v3] avformat/mov: Add support for demuxing still HEIC images
On Thu, Oct 5, 2023 at 10:36 AM Vittorio Giovara
wrote:
>
>
> On Wed, Oct 4, 2023 at 12:40 PM Vignesh Venkatasubramanian via
> ffmpeg-devel wrote:
>
>> They are similar to AVIF images (both use the HEIF container).
>> The only additional work needed is to parse the hvcC box and put
>> it in the extradata.
>>
>> With this patch applied, ffmpeg (when built with an HEVC decoder)
>> is able to decode the files in
>> https://github.com/nokiatech/heif/tree/gh-pages/content/images
>>
>> Also add a couple of fate tests with samples from
>>
>> https://github.com/nokiatech/heif_conformance/tree/master/conformance_files
>>
>> Partially fixes trac ticket #6521.
>>
>> Signed-off-by: Vignesh Venkatasubramanian
>> ---
>> libavformat/isom.h| 2 +
>> libavformat/mov.c | 41 ++-
>> tests/fate/mov.mak| 6 +++
>> .../fate/mov-heic-demux-still-image-1-item| 11 +
>> .../mov-heic-demux-still-image-multiple-items | 11 +
>> 5 files changed, 70 insertions(+), 1 deletion(-)
>> create mode 100644 tests/ref/fate/mov-heic-demux-still-image-1-item
>> create mode 100644
>> tests/ref/fate/mov-heic-demux-still-image-multiple-items
>>
>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>> index 3d375d7a46..b30b9da65e 100644
>> --- a/libavformat/isom.h
>> +++ b/libavformat/isom.h
>> @@ -327,6 +327,8 @@ typedef struct MOVContext {
>> int64_t extent_offset;
>> } *avif_info;
>> int avif_info_size;
>> +int64_t hvcC_offset;
>> +int hvcC_size;
>> int interleaved_read;
>> } MOVContext;
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 294c864fbd..d3747022bd 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -1218,7 +1218,8 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext
>> *pb, MOVAtom atom)
>> c->isom = 1;
>> av_log(c->fc, AV_LOG_DEBUG, "ISO: File Type Major Brand:
>> %.4s\n",(char *)&type);
>> av_dict_set(&c->fc->metadata, "major_brand", type, 0);
>> -c->is_still_picture_avif = !strncmp(type, "avif", 4);
>> +c->is_still_picture_avif = !strncmp(type, "avif", 4) ||
>> + !strncmp(type, "mif1", 4);
>> minor_ver = avio_rb32(pb); /* minor version */
>> av_dict_set_int(&c->fc->metadata, "minor_version", minor_ver, 0);
>>
>> @@ -4911,6 +4912,19 @@ static int avif_add_stream(MOVContext *c, int
>> item_id)
>> st->priv_data = sc;
>> st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
>> st->codecpar->codec_id = AV_CODEC_ID_AV1;
>> +if (c->hvcC_offset >= 0) {
>> +int ret;
>> +int64_t pos = avio_tell(c->fc->pb);
>> +st->codecpar->codec_id = AV_CODEC_ID_HEVC;
>> +if (avio_seek(c->fc->pb, c->hvcC_offset, SEEK_SET) !=
>> c->hvcC_offset) {
>> +av_log(c->fc, AV_LOG_ERROR, "Failed to seek to hvcC
>> data.\n");
>> +return AVERROR_UNKNOWN;
>> +}
>> +ret = ff_get_extradata(c->fc, st->codecpar, c->fc->pb,
>> c->hvcC_size);
>> +if (ret < 0)
>> +return ret;
>> +avio_seek(c->fc->pb, pos, SEEK_SET);
>> +}
>> sc->ffindex = st->index;
>> c->trak_index = st->index;
>> st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
>> @@ -4953,6 +4967,8 @@ static int avif_add_stream(MOVContext *c, int
>> item_id)
>>
>> static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>> {
>> +c->hvcC_offset = -1;
>> +c->hvcC_size = 0;
>> while (atom.size > 8) {
>> uint32_t tag;
>> if (avio_feof(pb))
>> @@ -7827,6 +7843,28 @@ static int mov_read_iloc(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>> return atom.size;
>> }
>>
>> +static int mov_read_iprp(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>> +{
>> +int size = avio_rb32(pb);
>> +if (avio_rl32(pb) != MKTAG('i','p','c','o'))
>> +return AVERROR_INVALIDDATA;
>> +size -= 8;
>> +while (size > 0) {
>> +int sub_size, sub_type;
>> +sub_size = avio_rb32(pb);
>> +sub_type = avio_rl32(pb);
>> +sub_size -= 8;
>> +size -= sub_size + 8;
>> +if (sub_type == MKTAG('h','v','c','C')) {
>> +c->hvcC_offset = avio_tell(pb);
>> +c->hvcC_size = sub_size;
>> +break;
>> +}
>> +avio_skip(pb, sub_size);
>> +}
>> +return atom.size;
>> +}
>> +
>> static const MOVParseTableEntry mov_default_parse_table[] = {
>> { MKTAG('A','C','L','R'), mov_read_aclr },
>> { MKTAG('A','P','R','G'), mov_read_avid },
>> @@ -7934,6 +7972,7 @@ static const MOVParseTableEntry
>> mov_default_parse_table[] = {
>> { MKTAG('p','c','m','C'), mov_read_pcmc }, /* PCM configuration box */
>> { MKTAG('p','i','t','m'), mov_read_pitm },
>> { MKTAG('e','v','c','C'), mov_read_glbl },
>> +{ MKTAG('i','p','r','p'), mov_read_iprp },
>> { 0, NULL }
>> };
>>
>> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
>> index 6cb
Re: [FFmpeg-devel] [REFUND-REQUEST] VDD23 Travel
In data Sunday 2023-10-01 14:18:22 +0100, Derek Buitenhuis ha scritto: > On 9/29/2023 7:18 AM, Stefano Sabatini wrote: > > Once this is approved, follow instructions here to generate a refund > > request: > > https://www.spi-inc.org/treasurer/reimbursement-form/ > > One note: One step says to use the xe.com expensed calculator - however the > link provided is broken. Indeed the link on xe's own page > (https://www.xe.com/tools/#convertertools) > is broke. Google yeilds > https://www.xe.com/travel-expenses-calculator/table.shtml but > it is *also* broken - it cannot generate reports. So how am I suppose to do > this? I confirm it looks broken, sorry for that. I'll reach out SPI officials to get directions. > This really highlights how depending on a third party service (Xe) can be > problematic. Indeed. ___ 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".
Re: [FFmpeg-devel] [PATCH 3/3] ffprobe: introduce section type, use for the compact output
On date Wednesday 2023-09-06 01:15:22 +0200, Stefano Sabatini wrote: > On date Friday 2023-09-01 15:43:36 +0200, Stefano Sabatini wrote: > > Also, avoid spurious end-of-line after side data entries, and improve > > rendering of compact output, by adding an indication of the side data > > type for each entry. > > > > Also fixes issue: > > http://trac.ffmpeg.org/ticket/9266 > > --- > > fftools/ffprobe.c | 163 +- > > tests/ref/fate/concat-demuxer-simple2-lavf-ts | 64 - > > tests/ref/fate/filter-metadata-cropdetect |1 - > > tests/ref/fate/filter-metadata-cropdetect1|2 - > > tests/ref/fate/filter-metadata-cropdetect2|3 - > > tests/ref/fate/flv-demux |6 +- > > tests/ref/fate/gapless-mp3-side-data |9 +- > > tests/ref/fate/gaplessenc-itunes-to-ipod-aac |4 +- > > tests/ref/fate/gaplessenc-pcm-to-mov-aac |4 +- > > tests/ref/fate/gaplessinfo-itunes1|4 +- > > tests/ref/fate/gaplessinfo-itunes2|4 +- > > tests/ref/fate/mov-aac-2048-priming |3 +- > > tests/ref/fate/mov-zombie | 197 +-- > > tests/ref/fate/oggopus-demux |6 +- > > tests/ref/fate/ts-demux | 56 +- > > tests/ref/fate/ts-opus-demux | 1536 ++--- > > tests/ref/fate/ts-small-demux | 219 +-- > > tests/ref/fate/ts-timed-id3-demux |6 +- > > 18 files changed, 788 insertions(+), 1499 deletions(-) > > Will apply in a few days if I see no comments. Applied. ___ 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".
Re: [FFmpeg-devel] [PATCH 10/12] avcodec/rv10: Replace switch by LUT
On Tue, Oct 3, 2023 at 12:03 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/rv10.c | 21 +
> 1 file changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
> index 3f9d5ff242..216328ffe7 100644
> --- a/libavcodec/rv10.c
> +++ b/libavcodec/rv10.c
> @@ -158,25 +158,14 @@ static int rv10_decode_picture_header(MpegEncContext
> *s)
>
> static int rv20_decode_picture_header(RVDecContext *rv, int whole_size)
> {
> +static const enum AVPictureType pict_types[] =
> +{ AV_PICTURE_TYPE_I, AV_PICTURE_TYPE_I /* hmm ... */,
>
Any chance we could replace this comment with something more detailed (or
remove it if not needed)?
--
Vittorio
___
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".
[FFmpeg-devel] [PATCH] avformat/webpenc: Check seeks
Addresses the issue reported in ticket #4609.
Signed-off-by: Andreas Rheinhardt
---
libavformat/webpenc.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavformat/webpenc.c b/libavformat/webpenc.c
index b3f5bdc9b5..fb0cca3922 100644
--- a/libavformat/webpenc.c
+++ b/libavformat/webpenc.c
@@ -177,8 +177,8 @@ static int webp_write_trailer(AVFormatContext *s)
if (w->using_webp_anim_encoder) {
if (w->loop) { // Write loop count.
-avio_seek(s->pb, 42, SEEK_SET);
-avio_wl16(s->pb, w->loop);
+if (avio_seek(s->pb, 42, SEEK_SET) == 42)
+avio_wl16(s->pb, w->loop);
}
} else {
int ret;
@@ -186,10 +186,11 @@ static int webp_write_trailer(AVFormatContext *s)
return ret;
filesize = avio_tell(s->pb);
-avio_seek(s->pb, 4, SEEK_SET);
-avio_wl32(s->pb, filesize - 8);
-// Note: without the following, avio only writes 8 bytes to the file.
-avio_seek(s->pb, filesize, SEEK_SET);
+if (avio_seek(s->pb, 4, SEEK_SET) == 4) {
+avio_wl32(s->pb, filesize - 8);
+// Note: without the following, avio only writes 8 bytes to the
file.
+avio_seek(s->pb, filesize, SEEK_SET);
+}
}
return 0;
--
2.34.1
___
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".
Re: [FFmpeg-devel] [PATCH 10/12] avcodec/rv10: Replace switch by LUT
Vittorio Giovara:
> On Tue, Oct 3, 2023 at 12:03 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/rv10.c | 21 +
>> 1 file changed, 5 insertions(+), 16 deletions(-)
>>
>> diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
>> index 3f9d5ff242..216328ffe7 100644
>> --- a/libavcodec/rv10.c
>> +++ b/libavcodec/rv10.c
>> @@ -158,25 +158,14 @@ static int rv10_decode_picture_header(MpegEncContext
>> *s)
>>
>> static int rv20_decode_picture_header(RVDecContext *rv, int whole_size)
>> {
>> +static const enum AVPictureType pict_types[] =
>> +{ AV_PICTURE_TYPE_I, AV_PICTURE_TYPE_I /* hmm ... */,
>>
>
> Any chance we could replace this comment with something more detailed (or
> remove it if not needed)?
The comment has been added when the mapping for 1 was added in
248a1aa54c0 (which made the default case dead code). I simply preserved
it, Michael probably added it to show that he was not completely sure. I
don't know whether there are different semantics for the two values.
I do not object to the removal of this comment.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 12/12] avcodec/mpegvideo: Move allocating new_picture to the encoder
Andreas Rheinhardt: > It is only used by encoders; this unfortunately necessitated > to add separate allocations to the SVQ1 encoder which uses > motion estimation without being a full member of mpegvideo. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/mpegvideo.c | 5 + > libavcodec/mpegvideo_enc.c | 3 ++- > libavcodec/svq1enc.c | 6 -- > 3 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c > index fc73abab9c..9ed158ac57 100644 > --- a/libavcodec/mpegvideo.c > +++ b/libavcodec/mpegvideo.c > @@ -632,7 +632,6 @@ static void clear_context(MpegEncContext *s) > memset(&s->next_picture, 0, sizeof(s->next_picture)); > memset(&s->last_picture, 0, sizeof(s->last_picture)); > memset(&s->current_picture, 0, sizeof(s->current_picture)); > -memset(&s->new_picture, 0, sizeof(s->new_picture)); > > memset(s->thread_context, 0, sizeof(s->thread_context)); > > @@ -720,8 +719,7 @@ av_cold int ff_mpv_common_init(MpegEncContext *s) > > if (!(s->next_picture.f= av_frame_alloc()) || > !(s->last_picture.f= av_frame_alloc()) || > -!(s->current_picture.f = av_frame_alloc()) || > -!(s->new_picture = av_frame_alloc())) > +!(s->current_picture.f = av_frame_alloc())) > goto fail_nomem; > > if ((ret = ff_mpv_init_context_frame(s))) > @@ -801,7 +799,6 @@ void ff_mpv_common_end(MpegEncContext *s) > ff_mpv_picture_free(s->avctx, &s->last_picture); > ff_mpv_picture_free(s->avctx, &s->current_picture); > ff_mpv_picture_free(s->avctx, &s->next_picture); > -av_frame_free(&s->new_picture); > > s->context_initialized = 0; > s->context_reinit = 0; > diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c > index 5bf4b06a11..f669658127 100644 > --- a/libavcodec/mpegvideo_enc.c > +++ b/libavcodec/mpegvideo_enc.c > @@ -821,7 +821,8 @@ av_cold int ff_mpv_encode_init(AVCodecContext *avctx) > !FF_ALLOCZ_TYPED_ARRAY(s->q_chroma_intra_matrix16, 32) || > !FF_ALLOCZ_TYPED_ARRAY(s->q_inter_matrix16,32) || > !FF_ALLOCZ_TYPED_ARRAY(s->input_picture, > MAX_PICTURE_COUNT) || > -!FF_ALLOCZ_TYPED_ARRAY(s->reordered_input_picture, > MAX_PICTURE_COUNT)) > +!FF_ALLOCZ_TYPED_ARRAY(s->reordered_input_picture, > MAX_PICTURE_COUNT) || > +!(s->new_picture = av_frame_alloc())) > return AVERROR(ENOMEM); > > /* Allocate MV tables; the MV and MB tables will be copied > diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c > index 46a484e15f..894ae552bb 100644 > --- a/libavcodec/svq1enc.c > +++ b/libavcodec/svq1enc.c > @@ -570,6 +570,7 @@ static av_cold int svq1_encode_end(AVCodecContext *avctx) > > av_frame_free(&s->current_picture); > av_frame_free(&s->last_picture); > +av_frame_free(&s->m.new_picture); > > return 0; > } > @@ -632,10 +633,11 @@ static av_cold int svq1_encode_init(AVCodecContext > *avctx) > s->dummy = av_mallocz((s->y_block_width + 1) * > s->y_block_height * sizeof(int32_t)); > s->m.me.map= av_mallocz(2 * ME_MAP_SIZE * > sizeof(*s->m.me.map)); > +s->m.new_picture = av_frame_alloc(); > s->svq1encdsp.ssd_int8_vs_int16 = ssd_int8_vs_int16_c; > > -if (!s->m.me.temp || !s->m.me.scratchpad || !s->m.me.map || > -!s->mb_type || !s->dummy) > +if (!s->m.me.scratchpad || !s->m.me.map || > +!s->mb_type || !s->dummy || !s->m.new_picture) > return AVERROR(ENOMEM); > s->m.me.score_map = s->m.me.map + ME_MAP_SIZE; > Will apply this patch tonight unless there are objections. - Andreas ___ 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".
[FFmpeg-devel] [PATCH 01/13] avcodec/mpegvideo_enc: Fix abort on allocation errors
mpegvideo_enc uses a fixed-size array of Pictures; a slot is
considered taken if the Picture's AVFrame is set.
When an error happens after a slot has been taken, this Picture
has typically not been reset and is therefore not usable for
future requests. The code aborts when one runs out of slots
and this can happen in case of allocation failures.
Fix this by always unreferencing a Picture in case of errors.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 5bf4b06a11..6cd9d89e1b 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1223,8 +1223,10 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
}
}
ret = av_frame_copy_props(pic->f, pic_arg);
-if (ret < 0)
+if (ret < 0) {
+ff_mpeg_unref_picture(s->avctx, pic);
return ret;
+}
pic->display_picture_number = display_picture_number;
pic->f->pts = pts; // we set this here to avoid modifying pic_arg
@@ -1535,8 +1537,10 @@ static int select_input_picture(MpegEncContext *s)
}
} else if (s->b_frame_strategy == 2) {
b_frames = estimate_best_b_count(s);
-if (b_frames < 0)
+if (b_frames < 0) {
+ff_mpeg_unref_picture(s->avctx, s->input_picture[0]);
return b_frames;
+}
}
emms_c();
@@ -1591,7 +1595,7 @@ no_output_pic:
if ((ret = av_frame_ref(s->new_picture,
s->reordered_input_picture[0]->f)))
-return ret;
+goto fail;
if (s->reordered_input_picture[0]->shared || s->avctx->rc_buffer_size)
{
// input is a shared pix, so we can't modify it -> allocate a new
@@ -1604,13 +1608,15 @@ no_output_pic:
pic = &s->picture[i];
pic->reference = s->reordered_input_picture[0]->reference;
-if (alloc_picture(s, pic, 0) < 0) {
-return -1;
-}
+ret = alloc_picture(s, pic, 0);
+if (ret < 0)
+goto fail;
ret = av_frame_copy_props(pic->f,
s->reordered_input_picture[0]->f);
-if (ret < 0)
-return ret;
+if (ret < 0) {
+ff_mpeg_unref_picture(s->avctx, pic);
+goto fail;
+}
pic->coded_picture_number =
s->reordered_input_picture[0]->coded_picture_number;
pic->display_picture_number =
s->reordered_input_picture[0]->display_picture_number;
@@ -1631,6 +1637,9 @@ no_output_pic:
}
return 0;
+fail:
+ff_mpeg_unref_picture(s->avctx, s->reordered_input_picture[0]);
+return ret;
}
static void frame_end(MpegEncContext *s)
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 02/13] avcodec/mpegvideo_enc: Remove always-false checks
In case "!direct" we are not reusing the input buffers
(due to e.g. insufficient alignment), but allocating
new ones. These of course do not alias with the ones
provided by the user, so these checks are always-false.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 6cd9d89e1b..3be6c1f928 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1171,11 +1171,6 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
return ret;
if (!direct) {
-if (pic->f->data[0] + INPLACE_OFFSET == pic_arg->data[0] &&
-pic->f->data[1] + INPLACE_OFFSET == pic_arg->data[1] &&
-pic->f->data[2] + INPLACE_OFFSET == pic_arg->data[2]) {
-// empty
-} else {
int h_chroma_shift, v_chroma_shift;
av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt,
&h_chroma_shift,
@@ -1220,7 +1215,6 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
}
}
emms_c();
-}
}
ret = av_frame_copy_props(pic->f, pic_arg);
if (ret < 0) {
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 03/13] avcodec/mpegvideo_enc: Reindentation
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 84 +++---
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 3be6c1f928..09b8348ae7 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1171,50 +1171,50 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
return ret;
if (!direct) {
-int h_chroma_shift, v_chroma_shift;
-av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt,
- &h_chroma_shift,
- &v_chroma_shift);
-
-for (i = 0; i < 3; i++) {
-int src_stride = pic_arg->linesize[i];
-int dst_stride = i ? s->uvlinesize : s->linesize;
-int h_shift = i ? h_chroma_shift : 0;
-int v_shift = i ? v_chroma_shift : 0;
-int w = s->width >> h_shift;
-int h = s->height >> v_shift;
-const uint8_t *src = pic_arg->data[i];
-uint8_t *dst = pic->f->data[i];
-int vpad = 16;
-
-if ( s->codec_id == AV_CODEC_ID_MPEG2VIDEO
-&& !s->progressive_sequence
-&& FFALIGN(s->height, 32) - s->height > 16)
-vpad = 32;
-
-if (!s->avctx->rc_buffer_size)
-dst += INPLACE_OFFSET;
-
-if (src_stride == dst_stride)
-memcpy(dst, src, src_stride * h);
-else {
-int h2 = h;
-uint8_t *dst2 = dst;
-while (h2--) {
-memcpy(dst2, src, w);
-dst2 += dst_stride;
-src += src_stride;
-}
-}
-if ((s->width & 15) || (s->height & (vpad-1))) {
-s->mpvencdsp.draw_edges(dst, dst_stride,
-w, h,
-16 >> h_shift,
-vpad >> v_shift,
-EDGE_BOTTOM);
+int h_chroma_shift, v_chroma_shift;
+av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt,
+ &h_chroma_shift,
+ &v_chroma_shift);
+
+for (int i = 0; i < 3; i++) {
+int src_stride = pic_arg->linesize[i];
+int dst_stride = i ? s->uvlinesize : s->linesize;
+int h_shift = i ? h_chroma_shift : 0;
+int v_shift = i ? v_chroma_shift : 0;
+int w = s->width >> h_shift;
+int h = s->height >> v_shift;
+const uint8_t *src = pic_arg->data[i];
+uint8_t *dst = pic->f->data[i];
+int vpad = 16;
+
+if ( s->codec_id == AV_CODEC_ID_MPEG2VIDEO
+&& !s->progressive_sequence
+&& FFALIGN(s->height, 32) - s->height > 16)
+vpad = 32;
+
+if (!s->avctx->rc_buffer_size)
+dst += INPLACE_OFFSET;
+
+if (src_stride == dst_stride)
+memcpy(dst, src, src_stride * h);
+else {
+int h2 = h;
+uint8_t *dst2 = dst;
+while (h2--) {
+memcpy(dst2, src, w);
+dst2 += dst_stride;
+src += src_stride;
}
}
-emms_c();
+if ((s->width & 15) || (s->height & (vpad-1))) {
+s->mpvencdsp.draw_edges(dst, dst_stride,
+w, h,
+16 >> h_shift,
+vpad >> v_shift,
+EDGE_BOTTOM);
+}
+}
+emms_c();
}
ret = av_frame_copy_props(pic->f, pic_arg);
if (ret < 0) {
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 04/13] avcodec/mpegvideo_enc: Don't pretend input to be non-refcounted
Signed-off-by: Andreas Rheinhardt --- libavcodec/mpegvideo_enc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c index 09b8348ae7..3b6386e144 100644 --- a/libavcodec/mpegvideo_enc.c +++ b/libavcodec/mpegvideo_enc.c @@ -1140,8 +1140,7 @@ static int load_input_picture(MpegEncContext *s, const AVFrame *pic_arg) } } -if (!pic_arg->buf[0] || -pic_arg->linesize[0] != s->linesize || +if (pic_arg->linesize[0] != s->linesize || pic_arg->linesize[1] != s->uvlinesize || pic_arg->linesize[2] != s->uvlinesize) direct = 0; -- 2.34.1 ___ 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".
[FFmpeg-devel] [PATCH 05/13] avcodec/mpegvideo_enc: Don't reget known values
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 3b6386e144..1e0aed8db9 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -40,7 +40,6 @@
#include "libavutil/intmath.h"
#include "libavutil/mathematics.h"
#include "libavutil/mem_internal.h"
-#include "libavutil/pixdesc.h"
#include "libavutil/opt.h"
#include "libavutil/thread.h"
#include "avcodec.h"
@@ -1170,16 +1169,11 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
return ret;
if (!direct) {
-int h_chroma_shift, v_chroma_shift;
-av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt,
- &h_chroma_shift,
- &v_chroma_shift);
-
for (int i = 0; i < 3; i++) {
int src_stride = pic_arg->linesize[i];
int dst_stride = i ? s->uvlinesize : s->linesize;
-int h_shift = i ? h_chroma_shift : 0;
-int v_shift = i ? v_chroma_shift : 0;
+int h_shift = i ? s->chroma_x_shift : 0;
+int v_shift = i ? s->chroma_y_shift : 0;
int w = s->width >> h_shift;
int h = s->height >> v_shift;
const uint8_t *src = pic_arg->data[i];
@@ -1640,9 +1634,8 @@ static void frame_end(MpegEncContext *s)
if (s->unrestricted_mv &&
s->current_picture.reference &&
!s->intra_only) {
-const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(s->avctx->pix_fmt);
-int hshift = desc->log2_chroma_w;
-int vshift = desc->log2_chroma_h;
+int hshift = s->chroma_x_shift;
+int vshift = s->chroma_y_shift;
s->mpvencdsp.draw_edges(s->current_picture.f->data[0],
s->current_picture.f->linesize[0],
s->h_edge_pos, s->v_edge_pos,
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 06/13] avcodec/mpegvideo_enc: Don't overallocate arrays
Only entries 0..max_b_frames are ever used.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 1e0aed8db9..c06fdd08fe 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -819,8 +819,8 @@ av_cold int ff_mpv_encode_init(AVCodecContext *avctx)
!FF_ALLOCZ_TYPED_ARRAY(s->q_intra_matrix16,32) ||
!FF_ALLOCZ_TYPED_ARRAY(s->q_chroma_intra_matrix16, 32) ||
!FF_ALLOCZ_TYPED_ARRAY(s->q_inter_matrix16,32) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->input_picture, MAX_PICTURE_COUNT)
||
-!FF_ALLOCZ_TYPED_ARRAY(s->reordered_input_picture, MAX_PICTURE_COUNT))
+!FF_ALLOCZ_TYPED_ARRAY(s->input_picture, MAX_B_FRAMES + 1) ||
+!FF_ALLOCZ_TYPED_ARRAY(s->reordered_input_picture, MAX_B_FRAMES + 1))
return AVERROR(ENOMEM);
/* Allocate MV tables; the MV and MB tables will be copied
@@ -1231,7 +1231,7 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
}
/* shift buffer entries */
-for (i = flush_offset; i < MAX_PICTURE_COUNT /*s->encoding_delay + 1*/;
i++)
+for (int i = flush_offset; i <= MAX_B_FRAMES; i++)
s->input_picture[i - flush_offset] = s->input_picture[i];
s->input_picture[encoding_delay] = pic;
@@ -1450,9 +1450,9 @@ static int select_input_picture(MpegEncContext *s)
{
int i, ret;
-for (i = 1; i < MAX_PICTURE_COUNT; i++)
+for (int i = 1; i <= MAX_B_FRAMES; i++)
s->reordered_input_picture[i - 1] = s->reordered_input_picture[i];
-s->reordered_input_picture[MAX_PICTURE_COUNT - 1] = NULL;
+s->reordered_input_picture[MAX_B_FRAMES] = NULL;
/* set next picture type & ordering */
if (!s->reordered_input_picture[0] && s->input_picture[0]) {
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 07/13] avcodec/mpegvideo_enc: Don't set write-only properties
The frame is immediately reset in the ff_mpeg_unref_picture() call below. Signed-off-by: Andreas Rheinhardt --- libavcodec/mpegvideo_enc.c | 4 1 file changed, 4 deletions(-) diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c index c06fdd08fe..9e28304554 100644 --- a/libavcodec/mpegvideo_enc.c +++ b/libavcodec/mpegvideo_enc.c @@ -1698,10 +1698,6 @@ static int frame_start(MpegEncContext *s) } s->current_picture_ptr->f->pict_type = s->pict_type; -if (s->pict_type == AV_PICTURE_TYPE_I) -s->current_picture.f->flags |= AV_FRAME_FLAG_KEY; -else -s->current_picture.f->flags &= ~AV_FRAME_FLAG_KEY; ff_mpeg_unref_picture(s->avctx, &s->current_picture); if ((ret = ff_mpeg_ref_picture(s->avctx, &s->current_picture, -- 2.34.1 ___ 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".
[FFmpeg-devel] [PATCH 08/13] avcodec/mpegvideo_enc: Remove dead block
None of the mpegvideo encoders support anything but coded frames;
and if this were to change, it is unclear whether they would need
the adjustment here. So remove it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 9e28304554..5dc95ef309 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1724,19 +1724,6 @@ static int frame_start(MpegEncContext *s)
return ret;
}
-if (s->picture_structure!= PICT_FRAME) {
-int i;
-for (i = 0; i < 4; i++) {
-if (s->picture_structure == PICT_BOTTOM_FIELD) {
-s->current_picture.f->data[i] +=
-s->current_picture.f->linesize[i];
-}
-s->current_picture.f->linesize[i] *= 2;
-s->last_picture.f->linesize[i]*= 2;
-s->next_picture.f->linesize[i]*= 2;
-}
-}
-
if (s->dct_error_sum) {
av_assert2(s->noise_reduction && s->encoding);
update_noise_reduction(s);
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 09/13] avcodec/mpegvideo_enc: Don't allocate buffers unnecessarily
ff_alloc_picture() performs two tasks: a) In most instances,
it allocates frame buffers and b) it allocates certain
auxiliary buffers.
The exception to a) is the case when the encoder can reuse
user-supplied frames. And for these frames the auxiliary buffers
are unused, because this frame will never be used as current_picture
(and therefore also not as next_picture or last_picture);
see select_input_picture().
This means that we can simply avoid calling ff_alloc_picture()
with user-supplied frames at all.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegpicture.c | 7 +--
libavcodec/mpegpicture.h | 2 +-
libavcodec/mpegvideo_dec.c | 2 +-
libavcodec/mpegvideo_enc.c | 16
4 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index b7c804c8ec..a0f5181325 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -247,7 +247,7 @@ static int alloc_picture_tables(AVCodecContext *avctx,
Picture *pic, int encodin
* The pixels are allocated/set by calling get_buffer() if shared = 0
*/
int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, MotionEstContext *me,
- ScratchpadContext *sc, int shared, int encoding,
+ ScratchpadContext *sc, int encoding,
int chroma_x_shift, int chroma_y_shift, int out_format,
int mb_stride, int mb_width, int mb_height, int b8_stride,
ptrdiff_t *linesize, ptrdiff_t *uvlinesize)
@@ -259,10 +259,6 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic,
MotionEstContext *me,
|| pic->alloc_mb_height != mb_height)
free_picture_tables(pic);
-if (shared) {
-av_assert0(pic->f->data[0]);
-pic->shared = 1;
-} else {
av_assert0(!pic->f->buf[0]);
if (alloc_frame_buffer(avctx, pic, me, sc,
chroma_x_shift, chroma_y_shift,
@@ -271,7 +267,6 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic,
MotionEstContext *me,
*linesize = pic->f->linesize[0];
*uvlinesize = pic->f->linesize[1];
-}
if (!pic->qscale_table_buf)
ret = alloc_picture_tables(avctx, pic, encoding, out_format,
diff --git a/libavcodec/mpegpicture.h b/libavcodec/mpegpicture.h
index 7919aa402c..a04820237a 100644
--- a/libavcodec/mpegpicture.h
+++ b/libavcodec/mpegpicture.h
@@ -86,7 +86,7 @@ typedef struct Picture {
* The pixels are allocated/set by calling get_buffer() if shared = 0.
*/
int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, MotionEstContext *me,
- ScratchpadContext *sc, int shared, int encoding,
+ ScratchpadContext *sc, int encoding,
int chroma_x_shift, int chroma_y_shift, int out_format,
int mb_stride, int mb_width, int mb_height, int b8_stride,
ptrdiff_t *linesize, ptrdiff_t *uvlinesize);
diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index b4ecb56987..07febcfe55 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -236,7 +236,7 @@ int ff_mpv_common_frame_size_change(MpegEncContext *s)
static int alloc_picture(MpegEncContext *s, Picture *pic)
{
-return ff_alloc_picture(s->avctx, pic, &s->me, &s->sc, 0, 0,
+return ff_alloc_picture(s->avctx, pic, &s->me, &s->sc, 0,
s->chroma_x_shift, s->chroma_y_shift,
s->out_format,
s->mb_stride, s->mb_width, s->mb_height,
s->b8_stride,
&s->linesize, &s->uvlinesize);
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 5dc95ef309..26a596430d 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1090,9 +1090,9 @@ static int get_intra_count(MpegEncContext *s, const
uint8_t *src,
return acc;
}
-static int alloc_picture(MpegEncContext *s, Picture *pic, int shared)
+static int alloc_picture(MpegEncContext *s, Picture *pic)
{
-return ff_alloc_picture(s->avctx, pic, &s->me, &s->sc, shared, 1,
+return ff_alloc_picture(s->avctx, pic, &s->me, &s->sc, 1,
s->chroma_x_shift, s->chroma_y_shift,
s->out_format,
s->mb_stride, s->mb_width, s->mb_height,
s->b8_stride,
&s->linesize, &s->uvlinesize);
@@ -1163,12 +1163,12 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
if (direct) {
if ((ret = av_frame_ref(pic->f, pic_arg)) < 0)
return ret;
-}
-ret = alloc_picture(s, pic, direct);
-if (ret < 0)
-return ret;
+pic->shared = 1;
+} else {
+ret = alloc_picture(s, pic);
+if (ret < 0)
+return ret;
-if (!direct) {
for (int i = 0; i < 3; i++) {
[FFmpeg-devel] [PATCH 10/13] avcodec/mpegvideo_enc: Don't call av_frame_copy_props() unnecessarily
It is unnecessary in case of user-supplied frames, because
it happens directly after a av_frame_ref() with the same
src and dst.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 26a596430d..cb6b801b2a 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1168,6 +1168,11 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
ret = alloc_picture(s, pic);
if (ret < 0)
return ret;
+ret = av_frame_copy_props(pic->f, pic_arg);
+if (ret < 0) {
+ff_mpeg_unref_picture(s->avctx, pic);
+return ret;
+}
for (int i = 0; i < 3; i++) {
int src_stride = pic_arg->linesize[i];
@@ -1209,11 +1214,6 @@ static int load_input_picture(MpegEncContext *s, const
AVFrame *pic_arg)
}
emms_c();
}
-ret = av_frame_copy_props(pic->f, pic_arg);
-if (ret < 0) {
-ff_mpeg_unref_picture(s->avctx, pic);
-return ret;
-}
pic->display_picture_number = display_picture_number;
pic->f->pts = pts; // we set this here to avoid modifying pic_arg
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 11/13] avcodec/mpegpicture: Move caller-specific parts of function to callers
Since at least commit c954cf1e1b766a0d1992d5be0a8be0055a8e1a6a
(adding ff_encode_alloc_frame()), a large part of ff_alloc_picture()
is completely separate for the two callers. Move the caller-specific
parts out to the callers.
Signed-off-by: Andreas Rheinhardt
---
I know that the name ff_alloc_picture() (like lots of names in
mpegpicture) is no longer appropriate; I will fix this later
in rewrite of mpegpicture (soon...).
libavcodec/mpegpicture.c | 72 ++
libavcodec/mpegpicture.h | 6 ++--
libavcodec/mpegvideo_dec.c | 31 ++--
libavcodec/mpegvideo_enc.c | 22 ++--
4 files changed, 62 insertions(+), 69 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index a0f5181325..44c4c8fe93 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -26,9 +26,6 @@
#include "libavutil/imgutils.h"
#include "avcodec.h"
-#include "encode.h"
-#include "internal.h"
-#include "decode.h"
#include "motion_est.h"
#include "mpegpicture.h"
#include "mpegutils.h"
@@ -124,57 +121,13 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx,
MotionEstContext *me,
}
/**
- * Allocate a frame buffer
+ * Check the pic's linesize and allocate linesize dependent scratch buffers
*/
-static int alloc_frame_buffer(AVCodecContext *avctx, Picture *pic,
- MotionEstContext *me, ScratchpadContext *sc,
- int chroma_x_shift, int chroma_y_shift,
- int linesize, int uvlinesize)
+static int handle_pic_linesizes(AVCodecContext *avctx, Picture *pic,
+MotionEstContext *me, ScratchpadContext *sc,
+int linesize, int uvlinesize)
{
-int edges_needed = av_codec_is_encoder(avctx->codec);
-int r, ret;
-
-pic->tf.f = pic->f;
-
-if (edges_needed) {
-pic->f->width = avctx->width + 2 * EDGE_WIDTH;
-pic->f->height = avctx->height + 2 * EDGE_WIDTH;
-
-r = ff_encode_alloc_frame(avctx, pic->f);
-} else if (avctx->codec_id != AV_CODEC_ID_WMV3IMAGE &&
- avctx->codec_id != AV_CODEC_ID_VC1IMAGE &&
- avctx->codec_id != AV_CODEC_ID_MSS2) {
-r = ff_thread_get_ext_buffer(avctx, &pic->tf,
- pic->reference ? AV_GET_BUFFER_FLAG_REF :
0);
-} else {
-pic->f->width = avctx->width;
-pic->f->height = avctx->height;
-pic->f->format = avctx->pix_fmt;
-r = avcodec_default_get_buffer2(avctx, pic->f, 0);
-}
-
-if (r < 0 || !pic->f->buf[0]) {
-av_log(avctx, AV_LOG_ERROR, "get_buffer() failed (%d %p)\n",
- r, pic->f->data[0]);
-return -1;
-}
-
-if (edges_needed) {
-int i;
-for (i = 0; pic->f->data[i]; i++) {
-int offset = (EDGE_WIDTH >> (i ? chroma_y_shift : 0)) *
- pic->f->linesize[i] +
- (EDGE_WIDTH >> (i ? chroma_x_shift : 0));
-pic->f->data[i] += offset;
-}
-pic->f->width = avctx->width;
-pic->f->height = avctx->height;
-}
-
-ret = ff_hwaccel_frame_priv_alloc(avctx, &pic->hwaccel_picture_private,
- &pic->hwaccel_priv_buf);
-if (ret < 0)
-return ret;
+int ret;
if ((linesize && linesize != pic->f->linesize[0]) ||
(uvlinesize && uvlinesize != pic->f->linesize[1])) {
@@ -247,8 +200,7 @@ static int alloc_picture_tables(AVCodecContext *avctx,
Picture *pic, int encodin
* The pixels are allocated/set by calling get_buffer() if shared = 0
*/
int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, MotionEstContext *me,
- ScratchpadContext *sc, int encoding,
- int chroma_x_shift, int chroma_y_shift, int out_format,
+ ScratchpadContext *sc, int encoding, int out_format,
int mb_stride, int mb_width, int mb_height, int b8_stride,
ptrdiff_t *linesize, ptrdiff_t *uvlinesize)
{
@@ -259,14 +211,12 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic,
MotionEstContext *me,
|| pic->alloc_mb_height != mb_height)
free_picture_tables(pic);
-av_assert0(!pic->f->buf[0]);
-if (alloc_frame_buffer(avctx, pic, me, sc,
- chroma_x_shift, chroma_y_shift,
- *linesize, *uvlinesize) < 0)
-return -1;
+if (handle_pic_linesizes(avctx, pic, me, sc,
+ *linesize, *uvlinesize) < 0)
+return -1;
-*linesize = pic->f->linesize[0];
-*uvlinesize = pic->f->linesize[1];
+*linesize = pic->f->linesize[0];
+*uvlinesize = pic->f->linesize[1];
if (!pic->qscale_table_buf)
ret = alloc_picture_tables(avctx, pic, encoding, out_format,
diff --git a/libavcodec/mpegpicture.h b/li
[FFmpeg-devel] [PATCH 12/13] avcodec/mpeg(picture|video_dec): Move comment to more appropriate place
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegpicture.c | 2 --
libavcodec/mpegvideo_dec.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 44c4c8fe93..f859f163a6 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -252,8 +252,6 @@ fail:
void ff_mpeg_unref_picture(AVCodecContext *avctx, Picture *pic)
{
pic->tf.f = pic->f;
-/* WM Image / Screen codecs allocate internal buffers with different
- * dimensions / colorspaces; ignore user-defined callbacks for these. */
if (avctx->codec_id != AV_CODEC_ID_WMV3IMAGE &&
avctx->codec_id != AV_CODEC_ID_VC1IMAGE &&
avctx->codec_id != AV_CODEC_ID_MSS2)
diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 4e00137cbb..7a9101a781 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -242,6 +242,8 @@ static int alloc_picture(MpegEncContext *s, Picture *pic)
pic->tf.f = pic->f;
+/* WM Image / Screen codecs allocate internal buffers with different
+ * dimensions / colorspaces; ignore user-defined callbacks for these. */
if (avctx->codec_id != AV_CODEC_ID_WMV3IMAGE &&
avctx->codec_id != AV_CODEC_ID_VC1IMAGE &&
avctx->codec_id != AV_CODEC_ID_MSS2) {
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH 13/13] avcodec/vdpau_vc1: Fix indentation
Forgotten after af6e232ccf8db2341361f02852017aac48772950.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vdpau_vc1.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vdpau_vc1.c b/libavcodec/vdpau_vc1.c
index 4e5ee14428..0eacc4477d 100644
--- a/libavcodec/vdpau_vc1.c
+++ b/libavcodec/vdpau_vc1.c
@@ -48,16 +48,16 @@ static int vdpau_vc1_start_frame(AVCodecContext *avctx,
switch (s->pict_type) {
case AV_PICTURE_TYPE_B:
if (s->next_picture_ptr) {
-ref = ff_vdpau_get_surface_id(s->next_picture.f);
-assert(ref != VDP_INVALID_HANDLE);
-info->backward_reference = ref;
+ref = ff_vdpau_get_surface_id(s->next_picture.f);
+assert(ref != VDP_INVALID_HANDLE);
+info->backward_reference = ref;
}
/* fall-through */
case AV_PICTURE_TYPE_P:
if (s->last_picture_ptr) {
-ref = ff_vdpau_get_surface_id(s->last_picture.f);
-assert(ref != VDP_INVALID_HANDLE);
-info->forward_reference = ref;
+ref = ff_vdpau_get_surface_id(s->last_picture.f);
+assert(ref != VDP_INVALID_HANDLE);
+info->forward_reference = ref;
}
}
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH] avfilter/vulkan_filter: Remove unused label
Unused since 81cc0e13455baa5e6547df40dc5961d415d6fcd2.
Signed-off-by: Andreas Rheinhardt
---
Will apply this today.
libavfilter/vulkan_filter.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavfilter/vulkan_filter.c b/libavfilter/vulkan_filter.c
index f3f40465be..c77415d1be 100644
--- a/libavfilter/vulkan_filter.c
+++ b/libavfilter/vulkan_filter.c
@@ -90,7 +90,6 @@ skip:
device_ref = frames_ctx->device_ref;
frames_ref = NULL;
} else {
-accept:
frames_ref = av_buffer_ref(frames_ref);
if (!frames_ref)
return AVERROR(ENOMEM);
--
2.34.1
___
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".
Re: [FFmpeg-devel] [PATCH 03/11] avformat/avformat: use the side data from AVStream.codecpar
James Almer:
> Deprecate AVStream.side_data and its helpers in favor of the AVStream's
> codecpar.side_data.
>
> This will considerably simplify the propagation of global side data to
> decoders
> and from encoders. Instead of having to do it inside packets, it will be
> available during init().
> Global and frame specific side data will therefore be distinct.
>
> Signed-off-by: James Almer
> ---
...
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index a8e245000f..8a3fe137fa 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -940,6 +940,7 @@ typedef struct AVStream {
> */
> AVPacket attached_pic;
>
> +#if FF_API_AVSTREAM_SIDE_DATA
> /**
> * An array of side data that applies to the whole stream (i.e. the
> * container does not allow it to change between packets).
> @@ -956,13 +957,20 @@ typedef struct AVStream {
> *
> * Freed by libavformat in avformat_free_context().
> *
> - * @see av_format_inject_global_side_data()
> + * @deprecated use AVStream's @ref AVCodecParameters.side_data
> + * "codecpar side data".
> */
> +attribute_deprecated
> AVPacketSideData *side_data;
> /**
> * The number of elements in the AVStream.side_data array.
> + *
> + * @deprecated use AVStream's @ref AVCodecParameters.side_data
> + * "codecpar side data".
> */
> +attribute_deprecated
> intnb_side_data;
> +#endif
>
> /**
> * Flags indicating events happening on the stream, a combination of
> @@ -1720,11 +1728,18 @@ typedef struct AVFormatContext {
> int (*io_close2)(struct AVFormatContext *s, AVIOContext *pb);
> } AVFormatContext;
>
> +#if FF_API_AVSTREAM_SIDE_DATA
> /**
> * This function will cause global side data to be injected in the next
> packet
> * of each stream as well as after any subsequent seek.
> + *
> + * @deprecated global side data is always available in every AVStream's
> + * @ref AVCodecParameters.side_data "codecpar side data" array.
> + * @see av_packet_side_data_get()
> */
> +attribute_deprecated
> void av_format_inject_global_side_data(AVFormatContext *s);
> +#endif
This is not a "helper" of AVStream.side_data at all. Whereas porting
code to the new API is straightforward for the other deprecated
functions, this one is not. In fact, removing it adds complications for
users, because a user could simply inject global side data via this
function and then only look at packets, the user now has to add special
code to also inspect the global side data.
One example affected by this is my current patch for the Matroska
demuxer to output the palette as stream side data and not as packet side
data as the other demuxers do. Without
av_format_inject_global_side_data(), this will break every user
searching for palette data only in packet side data and not in stream
side data. In fact, one such user is libavformat itself, because all
muxers (nut and avi and mov (the latter two via rawutils)) only search
for this type of side data in packets.
As you can see in that patch, it fixes an issue with seeking where the
palette is attached to a packet read during avformat_find_stream_info()
that is discarded afterwards due to a seek. The same issue also exists
in avi, yet the solution is not so simple there because avi has a second
way to export palettes and due to the requirement that global and
packet-specific side data is supposed to be distinct one can't simply
attach the palette extracted from extradata as stream side-data. Which
makes me think that this requirement is not really reasonable.
- Andreas
___
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".
