Re: [FFmpeg-devel] [PATCH] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 decoding

Oct 14, 2022, 14:32 by toq...@outlook.com: > Lynne wrote: > >> Sent: 2022年10月14日 6:28 >> To: FFmpeg development discussions and >> patches >> Subject: Re: [FFmpeg-devel] [PATCH] avcodec: add D3D12VA hardware >> accelerated H264, HEVC, VP9, an

[FFmpeg-devel] [PATCHv2] avcodec/jpegtables: remove duplicate luma and chroma quantization tables

Duplicates of the standard JPEG quantization tables were found in the AGM, MSS34(dsp), NUV and VP31 codecs. This patch elimates those duplicates, placing a single copy in jpegquanttables.c. --- libavcodec/Makefile | 8 ++--- libavcodec/agm.c | 27 - libavcodec

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/jpegtables: remove duplicate luma and chroma quantization tables

Peter Ross: > On Fri, Oct 14, 2022 at 05:19:44PM +0200, Andreas Rheinhardt wrote: >> Peter Ross: >>> Duplicates of the standard JPEG quantization tables were found in the >>> AGM, MSS34(dsp), NUV and VP31 codecs. This patch elimates those duplicates, >>> placing a single copy in jpegtables. >>> ---

Re: [FFmpeg-devel] [PATCH v2] avcodec/startcode: Avoid unaligned accesses

Andreas Rheinhardt: > Up until now, ff_startcode_find_candidate_c() simply casts > an uint8_t* to uint64_t*/uint32_t* to read 64/32 bits at a time > in case HAVE_FAST_UNALIGNED is true. Yet this ignores the > alignment requirement of these types as well as effective type > rules of the C standard.

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/jpegtables: remove duplicate luma and chroma quantization tables

On Fri, Oct 14, 2022 at 05:19:44PM +0200, Andreas Rheinhardt wrote: > Peter Ross: > > Duplicates of the standard JPEG quantization tables were found in the > > AGM, MSS34(dsp), NUV and VP31 codecs. This patch elimates those duplicates, > > placing a single copy in jpegtables. > > --- > 1. mss34dsp

Re: [FFmpeg-devel] [PATCH v2] avcodec/startcode: Avoid unaligned accesses

Anton Khirnov: > Quoting Andreas Rheinhardt (2022-10-12 00:20:23) >> Up until now, ff_startcode_find_candidate_c() simply casts >> an uint8_t* to uint64_t*/uint32_t* to read 64/32 bits at a time >> in case HAVE_FAST_UNALIGNED is true. Yet this ignores the >> alignment requirement of these types as

Re: [FFmpeg-devel] [PATCH v2] lavc/hevc_ps: fix process failed when SPS before VPS in hvcC

On Fri, Oct 14, 2022 at 06:13:14PM +0800, wangyaqiang wrote: > > > > 2022年9月27日 04:21，Michael Niedermayer 写道： > > > > On Mon, Sep 26, 2022 at 05:38:14PM +0800, 1035567...@qq.com wrote: > >> From: Wang Yaqiang > >> > >> In some videos, SPS will be stored before VPS in hvcC box, > >> parse SPS

[FFmpeg-devel] [PATCH 2/2] avcodec/msmpeg4data: Mark tables as hidden

This e.g. allows compilers to bake the "+ 256" offset used to access ff_v2_dc_(lum|chroma)_table into the general offset; for certain arches this is also necessary in order to avoid building suboptimal code. Signed-off-by: Andreas Rheinhardt --- libavcodec/msmpeg4data.h | 4 1 file changed,

[FFmpeg-devel] [PATCH 1/2] avcodec/jpegtables: Mark jpegtables as hidden

These tables are not exported as avpriv symbols, but instead included into every library using them. Therefore they can be mark with the hidden elf visibility. For certain arches this is necessary in order to avoid building suboptimal code; for other arches it just allows the compiler to simplify a

Re: [FFmpeg-devel] [PATCH] avcodec/motion_est: Remove unused elements

Andreas Rheinhardt: > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/motion_est.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/libavcodec/motion_est.h b/libavcodec/motion_est.h > index 292bdc70e9..b20cda 100644 > --- a/libavcodec/motion_est.h > +++ b/libavcodec/motion_est.

Re: [FFmpeg-devel] [PATCH] avcodec/libdav1d: add an option to set max frame delay

Hi, On Tue, Oct 11, 2022 at 11:34 AM James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/libdav1d.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > LGTM, thanks. (And sorry for review delay, I was offline for a few days.) Ronald __

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libjxl: use RGB32F or RGBA32F for 32-bit float JPEG XL

On 10/2/22 03:58, Leo Izen wrote: Use AV_PIX_FMT_RGB32F or AV_PIX_FMT_RGBA32F for encoding and decoding JPEG XL files when encountered, rather than returning an error and refusing to do anything. Signed-off-by: Leo Izen --- libavcodec/libjxldec.c | 15 +-- libavcodec/libjxlenc.c

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/jpegtables: remove duplicate luma and chroma quantization tables

Peter Ross: > Duplicates of the standard JPEG quantization tables were found in the > AGM, MSS34(dsp), NUV and VP31 codecs. This patch elimates those duplicates, > placing a single copy in jpegtables. > --- > configure | 6 -- > libavcodec/agm.c| 27 +

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix implementation of updated input start time

On 2022-10-14 06:49 pm, Jan Ekström wrote: On Tue, Sep 27, 2022 at 7:41 AM Gyan Doshi wrote: The current adjustment of input start times just adjusts the tsoffset. And it does so, by resetting the tsoffset to nullify the new start time. This leads to breakage of -copyts, ignoring of user_ts_o

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix implementation of updated input start time

On Tue, Sep 27, 2022 at 7:41 AM Gyan Doshi wrote: > > The current adjustment of input start times just adjusts the tsoffset. > And it does so, by resetting the tsoffset to nullify the new start time. > This leads to breakage of -copyts, ignoring of user_ts_offset, breaking > of -isync as well as b

Re: [FFmpeg-devel] [PATCH] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 decoding

Lynne wrote: > Sent: 2022年10月14日 6:28 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avcodec: add D3D12VA hardware accelerated > H264, HEVC, VP9, and AV1 decoding > > Oct 13, 2022, 17:48 by toq...@outlook

[FFmpeg-devel] [PATCH 16/22] fftools/ffmpeg_mux_init: pass Muxer to new_output_stream()

And intermediate functions. Will be useful in the following commit. --- fftools/ffmpeg_mux_init.c | 97 --- 1 file changed, 50 insertions(+), 47 deletions(-) diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c index 3945bbed3a..222519f5ce 100644

[FFmpeg-devel] [PATCH 20/22] fftools/ffmpeg_mux: embed OutputStream in a MuxStream

This is now possible since OutputStream is a child of OutputFile and the code allocating it can access MuxStream. Avoids the overhead and extra complexity of allocating two objects instead of one. Similar to what was previously done for OutputFile/Muxer. --- fftools/ffmpeg_mux.c | 33 +++

[FFmpeg-devel] [PATCH 21/22] fftools/ffmpeg_mux: move bsf_ctx from OutputStream to MuxStream

It is private to the muxer and does not need to be visible outside of it. --- fftools/ffmpeg.h | 2 -- fftools/ffmpeg_mux.c | 17 ++--- fftools/ffmpeg_mux.h | 2 ++ fftools/ffmpeg_mux_init.c | 2 +- 4 files changed, 13 insertions(+), 10 deletions(-) diff --git a/

[FFmpeg-devel] [PATCH 19/22] fftools/ffmpeg: free output streams in of_close()

Output streams are now children of OutputFile, so it makes more sense to free them there. --- fftools/ffmpeg.c | 55 +--- fftools/ffmpeg_mux.c | 51 2 files changed, 52 insertions(+), 54 deletions(-) diff --git a

[FFmpeg-devel] [PATCH 22/22] fftools/ffmpeg_mux: move muxing queue fields from OutputStream to MuxStream

They are private to the muxer and do not need to be visible outside of it. --- fftools/ffmpeg.h | 5 - fftools/ffmpeg_mux.c | 4 ++-- fftools/ffmpeg_mux.h | 5 + fftools/ffmpeg_mux_init.c | 8 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/ffto

[FFmpeg-devel] [PATCH 17/22] fftools/ffmpeg: remove the output_streams global

Replace it with an array of streams in each OutputFile. This is a more accurate reflection of the actual relationship between OutputStream and OutputFile. This is easier to handle and will allow further simplifications in future commits. --- fftools/ffmpeg.c | 121 ++--

[FFmpeg-devel] [PATCH 14/22] fftools/ffmpeg: move freeing an output stream into a separate function

--- fftools/ffmpeg.c | 69 ++-- 1 file changed, 37 insertions(+), 32 deletions(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 46d2912d07..afbfff6ba2 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -504,6 +504,41 @@ static int decode_i

[FFmpeg-devel] [PATCH 18/22] fftools/ffmpeg: remove a cleanup block at the end of transcode()

Some of it is already duplicated in ost_free() - those parts can be just dropped(). The rest is moved to ost_free(), as it properly belongs there. --- fftools/ffmpeg.c | 29 +++-- 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/fftools/ffmpeg.c b/fftools/ffm

[FFmpeg-devel] [PATCH 15/22] fftools/ffmpeg: reindent after previous commit

--- fftools/ffmpeg.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index afbfff6ba2..f426dbc80f 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -511,30 +511,30 @@ static void ost_free(OutputStrea

Re: [FFmpeg-devel] [PATCH v2] lavc/hevc_ps: fix process failed when SPS before VPS in hvcC

> 2022年9月27日 04:21，Michael Niedermayer 写道： > > On Mon, Sep 26, 2022 at 05:38:14PM +0800, 1035567...@qq.com wrote: >> From: Wang Yaqiang >> >> In some videos, SPS will be stored before VPS in hvcC box, >> parse SPS does not depend on VPS, so the video is expected to be processed >> normally.

Re: [FFmpeg-devel] [PATCH] avcodec/dolby_e: Add error recovery when parse_mantissas run out of bits

>Envoyé : mardi 13 septembre 2022 23:31 >Mantissas are the last data in the channel subsegment and it appears it is >sometimes missing a very few bits for the parsing to complete. >This should not be confused with data corruption. >For 5.1+2@25fps, the occurence of this issue is pretty steady and