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

[Lynne]

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, and AV1 decoding
>>
>> Oct 13, 2022, 17:48 by toq...@outlook.com:
>>
 Lynne wrote:

 Oct 12, 2022, 13:09 by toq...@outlook.com:

> [PATCH] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and 
> AV1 decoding
>
> Patch attached.
>
 The Sync locking functions and the queue locking functions should
 be a function pointer in the device/frame context. Vulkan has
 the same issue, and that's how I did it there. This allows for
 API users to plug their own locking primitives in, which they need
 to in case they initialize their own contexts.

>>>
>>> I don’t need to follow your design.
>>>
>>
>> Yes, you do, because it's not my design, it's the design of the entire
>> hwcontext system. If API users cannot initialize a hwcontext with
>> their own, it's breakage. It's not optional.
>> Locking primitives are a part of this.
>> Either fix this or this is simply not getting merged.
>>
>
> As I learn from the docs of Direct3D12, it is a multithreading-friendly API,
> which means that the only mandatory field, device, set by the user can be
> accessed and used without any lock. Why do the API users need locking
> primitives to init the hwcontext_d3d12va? Have you got the initialization
> failed? If so, could you share the runtime error details here?
>
> And I checked the other hwcontexts, they didn't have a locking primitive also.
> The hwcontext_d3d11va has a locking used to protect accesses to device_context
> and video_context calls, which d3d12 doesn't need. So why the API users cannot
> initialize the hwcontext with their own? Is there any real failure case? 
> Please pardon
> I don't quite understand what situation you are talking about, could you 
> elaborate
> further if I get it wrong?
>
 You should also document which fields API users have to set
 themselves if they plan to use their own context.

>>>
>>> Where should I document them? Doesn’t the comments enough?
>>>
>> In the comments. Look at how it's done elsewhere.
>>
> There is already a comment like what d3d11va wrote:
>  /**
>  * Device used for objects creation and access. This can also be
>  * used to set the libavcodec decoding device.
>  *
>  * Can be set by the user. This is the only mandatory field - the other
>  * device context fields are set from this and are available for convenience.
>  *
>  * Deallocating the AVHWDeviceContext will always release this interface,
>  * and it does not matter whether it was user-allocated.
>  */
>  ID3D12Device *device;
>
> Is there anything else missing?
>

What about the frames context? Frame contexts are also user-settable.


 Also, struct names in the public context lack an AV prefix.

>>> Will fix. And which struct? Could you add the reference?
>>>
>>
>> In the main public context.
>>
> I check the codes and found that AVD3D12VASyncContext, AVD3D12VADeviceContext,
> AVD3D12FrameDescriptor and AVD3D12VAFramesContext are the structs in
> the hwcontext_d3d12va. Is there any other struct without AV prefix? Could you
> paste the name here?
>
 D3D12VA_MAX_SURFACES is a terrible hack. Vendors should
 fix their own drivers rather than users running out of memory.

>>>
>>> Not my responsibility as a personal developer. I know nothing
>>> about the drivers. You can ask those vendors to fix them. I don’t
>>> think it’s a `terrible hack`. On my test, The MAX_SURFACES is
>>> enough for the decoder. If there are any docs or the drivers fixed
>>> it, just simply remove it. Why user will run out of memory?
>>>
>>
>> The whole way the hwcontext is designed is sketchy. Why are
>> you keeping all texture information in an array (texture_infos)?Frames are 
>> already pooled (it's called AVFramePool), so you're
>> not doing anything by adding a second layer on top of this other
>> than complexity.
>> The initial_pool_size parameter was a hack added to support
>> hwcontexts which cannot allocate surfaces dynamically, you don't
>> need to support this at all, you can just let users allocate
>> frames as they need to rather than preinitializing.
>>
>
> It’s the same implementation as d3d11va. The static initial_pool_size is
> needed by the decoder heap to initialize and the input stream needs it
> as well The feature that allows the user to allocate frames is not the basic
> functionalities of decoding. I recommend the user who needs the feature
> implement it and contribute the codes.
>

It'll limit the hwcontext to just decoding, but whatever.

Are there any devices that don't support Vulkan but support d3d12?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://

[FFmpeg-devel] [PATCHv2] 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 jpegquanttables.c.
---
 libavcodec/Makefile  |  8 ++---
 libavcodec/agm.c | 27 -
 libavcodec/jpegquanttables.c | 58 
 libavcodec/jpegquanttables.h | 29 ++
 libavcodec/jpegtables.c  | 27 -
 libavcodec/mss34dsp.c| 25 ++--
 libavcodec/nuv.c | 27 ++---
 libavcodec/vp3.c |  3 +-
 libavcodec/vp3data.h | 13 
 9 files changed, 103 insertions(+), 114 deletions(-)
 create mode 100644 libavcodec/jpegquanttables.c
 create mode 100644 libavcodec/jpegquanttables.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 37b63cadc2..f53a8b6209 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -142,7 +142,7 @@ OBJS-$(CONFIG_MPEGVIDEOENC)+= mpegvideo_enc.o 
mpeg12data.o  \
   mpegvideoencdsp.o
 OBJS-$(CONFIG_MSMPEG4DEC)  += msmpeg4dec.o msmpeg4.o msmpeg4data.o
 OBJS-$(CONFIG_MSMPEG4ENC)  += msmpeg4enc.o msmpeg4.o msmpeg4data.o
-OBJS-$(CONFIG_MSS34DSP)+= mss34dsp.o
+OBJS-$(CONFIG_MSS34DSP)+= mss34dsp.o jpegquanttables.o
 OBJS-$(CONFIG_PIXBLOCKDSP) += pixblockdsp.o
 OBJS-$(CONFIG_QPELDSP) += qpeldsp.o
 OBJS-$(CONFIG_QSV) += qsv.o
@@ -196,7 +196,7 @@ OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o 
ac3enc.o ac3tab.o \
 OBJS-$(CONFIG_AC3_FIXED_ENCODER)   += ac3enc_fixed.o ac3enc.o ac3tab.o 
ac3.o kbdwin.o
 OBJS-$(CONFIG_AC3_MF_ENCODER)  += mfenc.o mf_utils.o
 OBJS-$(CONFIG_ACELP_KELVIN_DECODER)+= g729dec.o lsp.o celp_math.o 
celp_filters.o acelp_filters.o acelp_pitch_delay.o acelp_vectors.o 
g729postfilter.o
-OBJS-$(CONFIG_AGM_DECODER) += agm.o
+OBJS-$(CONFIG_AGM_DECODER) += agm.o jpegquanttables.o
 OBJS-$(CONFIG_AIC_DECODER) += aic.o
 OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
 OBJS-$(CONFIG_ALAC_ENCODER)+= alacenc.o alac_data.o
@@ -552,7 +552,7 @@ OBJS-$(CONFIG_MXPEG_DECODER)   += mxpegdec.o
 OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o nellymoser.o
 OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o nellymoser.o
 OBJS-$(CONFIG_NOTCHLC_DECODER) += notchlc.o
-OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
+OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o jpegquanttables.o
 OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
 OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opusdec_celt.o opus_celt.o 
\
   opus_pvq.o opus_silk.o opustab.o 
vorbis_data.o \
@@ -737,7 +737,7 @@ OBJS-$(CONFIG_VORBIS_DECODER)  += vorbisdec.o 
vorbisdsp.o vorbis.o \
   vorbis_data.o
 OBJS-$(CONFIG_VORBIS_ENCODER)  += vorbisenc.o vorbis.o \
   vorbis_data.o
-OBJS-$(CONFIG_VP3_DECODER) += vp3.o
+OBJS-$(CONFIG_VP3_DECODER) += vp3.o jpegquanttables.o
 OBJS-$(CONFIG_VP5_DECODER) += vp5.o vp56.o vp56data.o vpx_rac.o
 OBJS-$(CONFIG_VP6_DECODER) += vp6.o vp56.o vp56data.o \
   vp6dsp.o vpx_rac.o
diff --git a/libavcodec/agm.c b/libavcodec/agm.c
index 017aa0e1fa..760760a403 100644
--- a/libavcodec/agm.c
+++ b/libavcodec/agm.c
@@ -33,24 +33,7 @@
 #include "decode.h"
 #include "get_bits.h"
 #include "idctdsp.h"
-
-static const uint8_t unscaled_luma[64] = {
-16, 11, 10, 16, 24, 40, 51, 61, 12, 12, 14, 19,
-26, 58, 60, 55, 14, 13, 16, 24, 40, 57, 69, 56,
-14, 17, 22, 29, 51, 87, 80, 62, 18, 22, 37, 56,
-68,109,103, 77, 24, 35, 55, 64, 81,104,113, 92,
-49, 64, 78, 87,103,121,120,101, 72, 92, 95, 98,
-112,100,103,99
-};
-
-static const uint8_t unscaled_chroma[64] = {
-17, 18, 24, 47, 99, 99, 99, 99, 18, 21, 26, 66,
-99, 99, 99, 99, 24, 26, 56, 99, 99, 99, 99, 99,
-47, 66, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
-99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
-99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
-99, 99, 99, 99
-};
+#include "jpegquanttables.h"
 
 typedef struct MotionVector {
 int16_t x, y;
@@ -550,13 +533,13 @@ static void compute_quant_matrix(AGMContext *s, double 
qscale)
 } else {
 if (qscale >= 0.0) {
 for (int i = 0; i < 64; i++) {
-luma[i]   = FFMAX(1, unscaled_luma  [(i & 7) * 8 + (i >> 3)] * 
f);
-chroma[i] = FFMAX(1, unscaled_chroma[(i & 7) * 8 + (i >> 3)] * 
f);
+luma[i]   = FFMAX(1, ff_mjpeg_std_luminance_quant_tbl  [(i & 
7) * 8 + (i >> 3)] * f);
+chroma[i] = FFMAX(1, ff_mjpeg_std_chrominance_quant_tbl

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

[Andreas Rheinhardt]

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.
>>> ---
> 
>> 1. mss34dsp now uses jpegtables, yet it does not have a dependency on
>> it. Instead you seem to rely on all the users of mss34dsp to have a
>> dependency on jpegtables, yet this is not true for all of them. You will
>> get linking failures with --disable-everything --enable-decoder=msa1.
> 
> there is a OBJS-$(CONFIG_JPEGTABLES) += line in avcodec/Makefile that
> takes care of this. i tested this patch under few different configurations
> and observed no build errors.
> 

I am sorry, I missed the '+mss34dsp_select="jpegtables"' line from your
patch. So my first sentence above was simply bullshit.

>> 2. The fact that you need to add jpegtables to configure for almost all
>> components that use the jpeg quant tables means that it is not really
>> appropriate to put the jpeg quant tables into the same files as the jpeg
>> huff tables.
>> 3. The jpeg huff tables are duplicated into libavformat for shared
>> builds (because the overhead of exporting them exceeds the size gains
>> from not duplicating them); yet when one uses --enable-shared and
>> --enable-static at the same time, it might be that libavformat.a is
>> linked to libavcodec.so and therefore has no access to libavcodec's
>> internal symbols like the jpegtables, so we have to duplicate the
>> jpegtables into libavformat.a in this case. But if one links using
>> libavformat.a and libavcodec.a with both containing the jpeg huffman
>> tables, then one will get a linker error with this patch: The jpeg
>> huffman tables in libavformat will be pulled in by the libavformat
>> component needing them. With this patch libavcodec/jpegtables.o will
>> also be pulled in. But it also contains the jpeg tables already provided
>> by lavf/jpegtables.o, so you will get a multiple definition error.
>> In contrast to this, before this patch, lavc/jpegtables.o would not be
>> pulled in, because all dependencies to the mjpeg huffman tables will be
>> satisfied by lavf/jpegtabes.o.
>> So to summarize: If one duplicates stuff in multiple libraries, the
>> object files must really provide the exact same symbols; not more, not less.
> 
> wasn't aware jpegtabs.h was duplicated into libavformat.
> 

I said so on IRC yesterday. It's the reason the jpegtabs header exists.

>> The last two points imply that these tables should be moved to a file of
>> their own. Btw: I don't think that a configure subsystem is appropriate
>> for this (a single file with some tables is not really a subsystem);
>> actually I don't think that the current jpegtables subsystem is
>> appropriate at all.
> 
> will do
> 

If you do, please mark the declarations as internal so that the compiler
still knows that these tables are in the same DSO.

- 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 v2] avcodec/startcode: Avoid unaligned accesses

[Andreas Rheinhardt]

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. This commit therefore replaces these
> direct accesses with AV_RN64/32; this also improves
> readability.
> 
> UBSan reported these unaligned accesses which happened in 233
> FATE-tests involving H.264 and VC-1 (this has also been reported
> in tickets #8138 and #8485); these tests are fixed by this commit.
> 
> The output of GCC with -O3 is unchanged for aarch64, alpha, arm,
> loongarch, ppc and x64. There was only a slight difference for mips.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> This is v2 of 
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200122145210.6898-1-andreas.rheinha...@gmail.com/
> 
> Here is the mips code before this change:
> 
> startcode_old_O3.o: file format elf64-tradlittlemips
> 
> 
> Disassembly of section .text:
> 
>  :
>0: 18a00029bleza1,a8 
>4: 3c08ff7flui a4,0xff7f
>8: 3c07ff01lui a3,0xff01
>c: 65087f7fdaddiu  a4,a4,32639
>   10: 64e70101daddiu  a3,a3,257
>   14: 00084438dslla4,a4,0x10
>   18: 00073c38dslla3,a3,0x10
>   1c: 65087f7fdaddiu  a4,a4,32639
>   20: 64e70101daddiu  a3,a3,257
>   24: 00084478dslla4,a4,0x11
>   28: 00073df8dslla3,a3,0x17
>   2c: 00803025movea2,a0
>   30: 1025movev0,zero
>   34: 3508feffori a4,a4,0xfeff
>   38: 1005b   50 
>   3c: 34e78080ori a3,a3,0x8080
>   40: 24420008addiu   v0,v0,8
>   44: 0045182aslt v1,v0,a1
>   48: 10600015beqzv1,a0 
>   4c: nop
>   50: dcc3ld  v1,0(a2)
>   54: 0068482ddaddu   a5,v1,a4
>   58: 44a3dmtc1   v1,$f0
>   5c: 44a90800dmtc1   a5,$f1
>   60: 4be10002pandn   $f0,$f0,$f1
>   64: 4423dmfc1   v1,$f0
>   68: 00671824and v1,v1,a3
>   6c: 1060fff4beqzv1,40 
>   70: 64c60008daddiu  a2,a2,8
>   74: 0045182aslt v1,v0,a1
>   78: 1069beqzv1,a0 
>   7c: 0082182ddaddu   v1,a0,v0
>   80: 1005b   98 
>   84: 9064lbu a0,0(v1)
>   88: 24420001addiu   v0,v0,1
>   8c: 10a20008beq a1,v0,b0 
>   90: nop
>   94: 9064lbu a0,0(v1)
>   98: 1480fffbbneza0,88 
>   9c: 64630001daddiu  v1,v1,1
>   a0: 03e8jr  ra
>   a4: nop
>   a8: 03e8jr  ra
>   ac: 1025movev0,zero
>   b0: 03e8jr  ra
>   b4: 00a01025movev0,a1
>   ...
> 
> And here after this change:
> 
> startcode_new_O3.o: file format elf64-tradlittlemips
> 
> 
> Disassembly of section .text:
> 
>  :
>0: 18a0002bbleza1,b0 
>4: 3c08ff7flui a4,0xff7f
>8: 3c07ff01lui a3,0xff01
>c: 65087f7fdaddiu  a4,a4,32639
>   10: 64e70101daddiu  a3,a3,257
>   14: 00084438dslla4,a4,0x10
>   18: 00073c38dslla3,a3,0x10
>   1c: 65087f7fdaddiu  a4,a4,32639
>   20: 64e70101daddiu  a3,a3,257
>   24: 00084478dslla4,a4,0x11
>   28: 00073df8dslla3,a3,0x17
>   2c: 00803025movea2,a0
>   30: 1025movev0,zero
>   34: 3508feffori a4,a4,0xfeff
>   38: 1005b   50 
>   3c: 34e78080ori a3,a3,0x8080
>   40: 24420008addiu   v0,v0,8
>   44: 0045182aslt v1,v0,a1
>   48: 10600017beqzv1,a8 
>   4c: nop
>   50: 68c30007ldl v1,7(a2)
>   54: 6cc3ldr v1,0(a2)
>   58: 0068482ddaddu   a5,v1,a4
>   5c: 44a3dmtc1   v1,$f0
>   60: 44a90800dmtc1   a5,$f1
>   64: 4be10002pandn   $f0,$f0,$f1
>   68: 4423dmfc1   v1,$f0
>   6c: 00671824and v1,v1,a3
>   70: 1060fff3beqzv1,40 
>   74: 64c60008daddiu  a2,a2,8
>   78: 0045182aslt v1,v0,a1
>   7c: 106abeqzv1,a8 
>   80: 0082182ddaddu   v1,a0,v0
>   84: 1006b   a0 
>   88: 9064lbu a0,0(v1)
>   8c: nop
>   90: 24420001addiu   v0,v0,1
>   94: 10a20008beq a1,v0,b8 
>   98: nop
>   9c: 9064lbu a0,0(v1)
>   a0: 1480fffbbneza0,90 
>   a4: 64630001daddiu  v1,v1,1
>   a8: 03e8jr  ra
>   ac: nop
>   b0: 03e8jr  ra
>   b4: 1025movev0,zero
>   b8: 03e8jr  ra
>   bc: 00a01025movev0,a1
> 
> As one can see, the differe

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.
> > ---

> 1. mss34dsp now uses jpegtables, yet it does not have a dependency on
> it. Instead you seem to rely on all the users of mss34dsp to have a
> dependency on jpegtables, yet this is not true for all of them. You will
> get linking failures with --disable-everything --enable-decoder=msa1.

there is a OBJS-$(CONFIG_JPEGTABLES) += line in avcodec/Makefile that
takes care of this. i tested this patch under few different configurations
and observed no build errors.

> 2. The fact that you need to add jpegtables to configure for almost all
> components that use the jpeg quant tables means that it is not really
> appropriate to put the jpeg quant tables into the same files as the jpeg
> huff tables.
> 3. The jpeg huff tables are duplicated into libavformat for shared
> builds (because the overhead of exporting them exceeds the size gains
> from not duplicating them); yet when one uses --enable-shared and
> --enable-static at the same time, it might be that libavformat.a is
> linked to libavcodec.so and therefore has no access to libavcodec's
> internal symbols like the jpegtables, so we have to duplicate the
> jpegtables into libavformat.a in this case. But if one links using
> libavformat.a and libavcodec.a with both containing the jpeg huffman
> tables, then one will get a linker error with this patch: The jpeg
> huffman tables in libavformat will be pulled in by the libavformat
> component needing them. With this patch libavcodec/jpegtables.o will
> also be pulled in. But it also contains the jpeg tables already provided
> by lavf/jpegtables.o, so you will get a multiple definition error.
> In contrast to this, before this patch, lavc/jpegtables.o would not be
> pulled in, because all dependencies to the mjpeg huffman tables will be
> satisfied by lavf/jpegtabes.o.
> So to summarize: If one duplicates stuff in multiple libraries, the
> object files must really provide the exact same symbols; not more, not less.

wasn't aware jpegtabs.h was duplicated into libavformat.

> The last two points imply that these tables should be moved to a file of
> their own. Btw: I don't think that a configure subsystem is appropriate
> for this (a single file with some tables is not really a subsystem);
> actually I don't think that the current jpegtables subsystem is
> appropriate at all.

will do

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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 v2] avcodec/startcode: Avoid unaligned accesses

[Andreas Rheinhardt]

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 well as effective type
>> rules of the C standard. This commit therefore replaces these
>> direct accesses with AV_RN64/32; this also improves
>> readability.
>>
>> UBSan reported these unaligned accesses which happened in 233
>> FATE-tests involving H.264 and VC-1 (this has also been reported
>> in tickets #8138 and #8485); these tests are fixed by this commit.
>>
>> The output of GCC with -O3 is unchanged for aarch64, alpha, arm,
>> loongarch, ppc and x64. There was only a slight difference for mips.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> This is v2 of 
>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200122145210.6898-1-andreas.rheinha...@gmail.com/
>>
>> Here is the mips code before this change:
>>
>> startcode_old_O3.o: file format elf64-tradlittlemips
>>
>>
>> Disassembly of section .text:
>>
>>  :
>>0:18a00029bleza1,a8 
>> 
>>4:3c08ff7flui a4,0xff7f
>>8:3c07ff01lui a3,0xff01
>>c:65087f7fdaddiu  a4,a4,32639
>>   10:64e70101daddiu  a3,a3,257
>>   14:00084438dslla4,a4,0x10
>>   18:00073c38dslla3,a3,0x10
>>   1c:65087f7fdaddiu  a4,a4,32639
>>   20:64e70101daddiu  a3,a3,257
>>   24:00084478dslla4,a4,0x11
>>   28:00073df8dslla3,a3,0x17
>>   2c:00803025movea2,a0
>>   30:1025movev0,zero
>>   34:3508feffori a4,a4,0xfeff
>>   38:1005b   50 
>>   3c:34e78080ori a3,a3,0x8080
>>   40:24420008addiu   v0,v0,8
>>   44:0045182aslt v1,v0,a1
>>   48:10600015beqzv1,a0 
>> 
>>   4c:nop
>>   50:dcc3ld  v1,0(a2)
>>   54:0068482ddaddu   a5,v1,a4
>>   58:44a3dmtc1   v1,$f0
>>   5c:44a90800dmtc1   a5,$f1
>>   60:4be10002pandn   $f0,$f0,$f1
>>   64:4423dmfc1   v1,$f0
>>   68:00671824and v1,v1,a3
>>   6c:1060fff4beqzv1,40 
>> 
>>   70:64c60008daddiu  a2,a2,8
>>   74:0045182aslt v1,v0,a1
>>   78:1069beqzv1,a0 
>> 
>>   7c:0082182ddaddu   v1,a0,v0
>>   80:1005b   98 
>>   84:9064lbu a0,0(v1)
>>   88:24420001addiu   v0,v0,1
>>   8c:10a20008beq a1,v0,b0 
>> 
>>   90:nop
>>   94:9064lbu a0,0(v1)
>>   98:1480fffbbneza0,88 
>> 
>>   9c:64630001daddiu  v1,v1,1
>>   a0:03e8jr  ra
>>   a4:nop
>>   a8:03e8jr  ra
>>   ac:1025movev0,zero
>>   b0:03e8jr  ra
>>   b4:00a01025movev0,a1
>>  ...
>>
>> And here after this change:
>>
>> startcode_new_O3.o: file format elf64-tradlittlemips
>>
>>
>> Disassembly of section .text:
>>
>>  :
>>0:18a0002bbleza1,b0 
>> 
>>4:3c08ff7flui a4,0xff7f
>>8:3c07ff01lui a3,0xff01
>>c:65087f7fdaddiu  a4,a4,32639
>>   10:64e70101daddiu  a3,a3,257
>>   14:00084438dslla4,a4,0x10
>>   18:00073c38dslla3,a3,0x10
>>   1c:65087f7fdaddiu  a4,a4,32639
>>   20:64e70101daddiu  a3,a3,257
>>   24:00084478dslla4,a4,0x11
>>   28:00073df8dslla3,a3,0x17
>>   2c:00803025movea2,a0
>>   30:1025movev0,zero
>>   34:3508feffori a4,a4,0xfeff
>>   38:1005b   50 
>>   3c:34e78080ori a3,a3,0x8080
>>   40:24420008addiu   v0,v0,8
>>   44:0045182aslt v1,v0,a1
>>   48:10600017beqzv1,a8 
>> 
>>   4c:nop
>>   50:68c30007ldl v1,7(a2)
>>   54:6cc3ldr v1,0(a2)
>>   58:0068482ddaddu   a5,v1,a4
>>   5c:44a3dmtc1   v1,$f0
>>   60:44a90800dmtc1   a5,$f1
>>   64:4be10002pandn   $f0,$f0,$f1
>>   68:4423dmfc1   v1,$f0
>>   6c:00671824and v1,v1,a3
>>   70:1060fff3beqzv1,40 
>> 
>>   74:64c60008d

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

[Michael Niedermayer]

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 does not depend on VPS, so the video is expected to be processed 
> >> normally.
> >> Added "parsed_vps" parameter to indicate whether VPS have been parsed.
> >> Only VPS have been parsed can be verified during SPS parsing.
> >> 
> >> Signed-off-by: Wang Yaqiang 
> >> ---
> >> libavcodec/hevc_ps.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > This causes segfaults
> > 
> > ==816== Invalid read of size 8
> > ==816==at 0xFAF178: hevc_parse (in ffmpeg_g)
> > ==816==by 0xA7A2A6: av_parser_parse2 (in ffmpeg_g)
> > ==816==by 0x5FC388: parse_packet (in ffmpeg_g)
> > ==816==by 0x5FDC5D: read_frame_internal (in ffmpeg_g)
> > ==816==by 0x5FFA10: avformat_find_stream_info (in ffmpeg_g)
> > ==816==by 0x2F6054: open_input_file (in ffmpeg_g)
> > ==816==by 0x2FC6AB: ffmpeg_parse_options (in ffmpeg_g)
> > ==816==by 0x2E8A34: main (in ffmpeg_g)
> > ==816==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
> > 
> > 
> > [...]
> 
> Excuse me, we have run tests on our own business and have not found this 
> problem, but it is a hidden risk,really hope you can tell me how to reproduce 
> this problem. Thanks

heres a more complete stack trace, i willmail you the input sample privatly

Trailing option(s) found in the command: may be ignored.
[hevc @ 0x16a0ad40] Invalid NAL unit 0, skipping.
[hevc @ 0x16a0ad40] PTL information too short
==24589==at 0x12A19DF: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6303)
==24589==by 0x12A259D: av_log_default_callback (log.c:399)
==24589==by 0x12A2844: av_vlog (log.c:434)
==24589==by 0x12A26A3: av_log (log.c:413)
==24589==by 0x10A7216: parse_ptl (hevc_ps.c:342)
==24589==by 0x10A78B4: ff_hevc_decode_nal_vps (hevc_ps.c:503)
==24589==by 0x10A579C: parse_nal_units (hevc_parser.c:212)
==24589==by 0x10A5B46: hevc_parse (hevc_parser.c:331)
==24589==by 0xB82366: av_parser_parse2 (parser.c:163)
==24589==by 0x61BD17: parse_packet (demux.c:1140)
==24589==by 0x61C936: read_frame_internal (demux.c:1334)
==24589==by 0x6217A7: avformat_find_stream_info (demux.c:2612)
==24589==by 0x246A51: open_input_file (ffmpeg_opt.c:1315)
==24589==by 0x255E38: open_files (ffmpeg_opt.c:3703)
==24589==by 0x255FEC: ffmpeg_parse_options (ffmpeg_opt.c:3742)
==24589==by 0x26EFEE: main (ffmpeg.c:4236)
[hevc @ 0x16a0ad40] VPS 0 does not exist
==24589== Invalid read of size 8
==24589==at 0x10A5189: hevc_parse_slice_header (hevc_parser.c:88)
==24589==by 0x10A584E: parse_nal_units (hevc_parser.c:245)
==24589==by 0x10A5B46: hevc_parse (hevc_parser.c:331)
==24589==by 0xB82366: av_parser_parse2 (parser.c:163)
==24589==by 0x61BD17: parse_packet (demux.c:1140)
==24589==by 0x61C936: read_frame_internal (demux.c:1334)
==24589==by 0x6217A7: avformat_find_stream_info (demux.c:2612)
==24589==by 0x246A51: open_input_file (ffmpeg_opt.c:1315)
==24589==by 0x255E38: open_files (ffmpeg_opt.c:3703)
==24589==by 0x255FEC: ffmpeg_parse_options (ffmpeg_opt.c:3742)
==24589==by 0x26EFEE: main (ffmpeg.c:4236)
==24589==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==24589== 
==24589== 
==24589== Process terminating with default action of signal 11 (SIGSEGV)
==24589==  Access not within mapped region at address 0x8
==24589==at 0x10A5189: hevc_parse_slice_header (hevc_parser.c:88)
==24589==by 0x10A584E: parse_nal_units (hevc_parser.c:245)
==24589==by 0x10A5B46: hevc_parse (hevc_parser.c:331)
==24589==by 0xB82366: av_parser_parse2 (parser.c:163)
==24589==by 0x61BD17: parse_packet (demux.c:1140)
==24589==by 0x61C936: read_frame_internal (demux.c:1334)
==24589==by 0x6217A7: avformat_find_stream_info (demux.c:2612)
==24589==by 0x246A51: open_input_file (ffmpeg_opt.c:1315)
==24589==by 0x255E38: open_files (ffmpeg_opt.c:3703)
==24589==by 0x255FEC: ffmpeg_parse_options (ffmpeg_opt.c:3742)
==24589==by 0x26EFEE: main (ffmpeg.c:4236)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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 2/2] avcodec/msmpeg4data: Mark tables as hidden

[Andreas Rheinhardt]

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, 4 insertions(+)

diff --git a/libavcodec/msmpeg4data.h b/libavcodec/msmpeg4data.h
index ec7957c126..b2b5bade4d 100644
--- a/libavcodec/msmpeg4data.h
+++ b/libavcodec/msmpeg4data.h
@@ -32,6 +32,8 @@
 
 #include 
 
+#include "libavutil/attributes_internal.h"
+
 #include "rl.h"
 #include "vlc.h"
 
@@ -45,6 +47,7 @@ typedef struct MVTable {
 VLC vlc;/* decoding: vlc */
 } MVTable;
 
+FF_VISIBILITY_PUSH_HIDDEN
 extern VLC ff_msmp4_mb_i_vlc;
 extern VLC ff_msmp4_dc_luma_vlc[2];
 extern VLC ff_msmp4_dc_chroma_vlc[2];
@@ -83,5 +86,6 @@ extern const uint32_t ff_table1_dc_chroma[120][2];
 
 #define WMV2_INTER_CBP_TABLE_COUNT 4
 extern const uint32_t (* const 
ff_wmv2_inter_table[WMV2_INTER_CBP_TABLE_COUNT])[2];
+FF_VISIBILITY_POP_HIDDEN
 
 #endif /* AVCODEC_MSMPEG4DATA_H */
-- 
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 1/2] avcodec/jpegtables: Mark jpegtables as hidden

[Andreas Rheinhardt]

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 accesses
like ff_mjpeg_bits_dc_luminance + 1 because the "+ 1" can be baked
into the offset.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/jpegtables.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/jpegtables.h b/libavcodec/jpegtables.h
index 49b5ecdeb0..39baec3efb 100644
--- a/libavcodec/jpegtables.h
+++ b/libavcodec/jpegtables.h
@@ -23,6 +23,9 @@
 
 #include 
 
+#include "libavutil/attributes_internal.h"
+
+FF_VISIBILITY_PUSH_HIDDEN
 extern const uint8_t ff_mjpeg_bits_dc_luminance[];
 extern const uint8_t ff_mjpeg_val_dc[];
 
@@ -33,5 +36,6 @@ extern const uint8_t ff_mjpeg_val_ac_luminance[];
 
 extern const uint8_t ff_mjpeg_bits_ac_chrominance[];
 extern const uint8_t ff_mjpeg_val_ac_chrominance[];
+FF_VISIBILITY_POP_HIDDEN
 
 #endif /* AVCODEC_JPEGTABLES_H */
-- 
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] avcodec/motion_est: Remove unused elements

[Andreas Rheinhardt]

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.h
> @@ -51,8 +51,6 @@ typedef struct MotionEstContext {
>  int direct_basis_mv[4][2];
>  uint8_t *scratchpad;/**< data area for the ME algo, so that
>   * the ME does not need to malloc/free. 
> */
> -uint8_t *best_mb;
> -uint8_t *temp_mb[2];
>  uint8_t *temp;
>  int best_bits;
>  uint32_t *map;  ///< map to avoid duplicate evaluations

Will apply this patch tomorrow 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".

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

[Ronald S. Bultje]

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
___
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 2/2] avcodec/libjxl: use RGB32F or RGBA32F for 32-bit float JPEG XL

[Leo Izen]

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 |  1 +
  2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index de48bea4b2..92b98388d4 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -104,9 +104,12 @@ static enum AVPixelFormat libjxl_get_pix_fmt(void *avctx, 
const JxlBasicInfo *ba
  return basic_info->alpha_bits ? AV_PIX_FMT_YA8 : AV_PIX_FMT_GRAY8;
  }
  if (basic_info->exponent_bits_per_sample || basic_info->bits_per_sample 
> 16) {
-if (basic_info->alpha_bits)
-return AV_PIX_FMT_NONE;
  format->data_type = JXL_TYPE_FLOAT;
+if (basic_info->alpha_bits) {
+av_log(avctx, AV_LOG_WARNING, "Decoding gray+alpha JXL input as 
RGBA\n");
+format->num_channels = 4;
+return AV_PIX_FMT_RGBAF32;
+}
  return AV_PIX_FMT_GRAYF32;
  }
  format->data_type = JXL_TYPE_UINT16;
@@ -119,10 +122,10 @@ static enum AVPixelFormat libjxl_get_pix_fmt(void *avctx, 
const JxlBasicInfo *ba
  format->data_type = JXL_TYPE_UINT8;
  return basic_info->alpha_bits ? AV_PIX_FMT_RGBA : 
AV_PIX_FMT_RGB24;
  }
-if (basic_info->bits_per_sample > 16)
-av_log(avctx, AV_LOG_WARNING, "Downsampling larger integer to 16-bit 
via libjxl\n");
-if (basic_info->exponent_bits_per_sample)
-av_log(avctx, AV_LOG_WARNING, "Downsampling float to 16-bit integer via 
libjxl\n");
+if (basic_info->exponent_bits_per_sample || basic_info->bits_per_sample 
> 16) {
+format->data_type = JXL_TYPE_FLOAT;
+return basic_info->alpha_bits ? AV_PIX_FMT_RGBAF32 : 
AV_PIX_FMT_RGBF32;
+}
  format->data_type = JXL_TYPE_UINT16;
  return basic_info->alpha_bits ? AV_PIX_FMT_RGBA64 : AV_PIX_FMT_RGB48;
  }
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 0793ed251b..f9ae086e38 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -474,6 +474,7 @@ const FFCodec ff_libjxl_encoder = {
  .p.pix_fmts   = (const enum AVPixelFormat[]) {
  AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA,
  AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64,
+AV_PIX_FMT_RGBF32, AV_PIX_FMT_RGBAF32,
  AV_PIX_FMT_GRAY8, AV_PIX_FMT_YA8,
  AV_PIX_FMT_GRAY16, AV_PIX_FMT_YA16,
  AV_PIX_FMT_GRAYF32,


Bump, thanks.

- Leo Izen (thebombzen)


___
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 1/2] avcodec/jpegtables: remove duplicate luma and chroma quantization tables

[Andreas Rheinhardt]

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 +--
>  libavcodec/jpegtables.c |  6 ++
>  libavcodec/jpegtables.h |  3 +++
>  libavcodec/mss34dsp.c   | 25 ++---
>  libavcodec/nuv.c| 27 +++
>  libavcodec/vp3.c|  3 ++-
>  libavcodec/vp3data.h| 13 -
>  8 files changed, 21 insertions(+), 89 deletions(-)
> 
> diff --git a/configure b/configure
> index f3fd91f592..2271e9b485 100755
> --- a/configure
> +++ b/configure
> @@ -2758,6 +2758,7 @@ mpegvideodec_select="mpegvideo mpeg_er"
>  mpegvideoenc_select="aandcttables fdctdsp me_cmp mpegvideo pixblockdsp 
> qpeldsp"
>  msmpeg4dec_select="h263_decoder"
>  msmpeg4enc_select="h263_encoder"
> +mss34dsp_select="jpegtables"
>  vc1dsp_select="h264chroma qpeldsp startcode"
>  rdft_select="fft"
>  
> @@ -2773,6 +2774,7 @@ ac3_fixed_encoder_select="ac3dsp audiodsp mdct me_cmp"
>  acelp_kelvin_decoder_select="audiodsp"
>  adpcm_g722_decoder_select="g722dsp"
>  adpcm_g722_encoder_select="g722dsp"
> +agm_decoder_select="jpegtables"
>  aic_decoder_select="golomb idctdsp"
>  alac_encoder_select="lpc"
>  als_decoder_select="bswapdsp mpeg4audio"
> @@ -2918,7 +2920,7 @@ mxpeg_decoder_select="mjpeg_decoder"
>  nellymoser_decoder_select="mdct sinewin"
>  nellymoser_encoder_select="audio_frame_queue mdct sinewin"
>  notchlc_decoder_select="lzf"
> -nuv_decoder_select="idctdsp"
> +nuv_decoder_select="idctdsp jpegtables"
>  on2avc_decoder_select="mdct"
>  opus_decoder_deps="swresample"
>  opus_encoder_select="audio_frame_queue"
> @@ -2983,7 +2985,7 @@ vc1_decoder_select="blockdsp h264qpel intrax8 
> mpegvideodec msmpeg4dec vc1dsp"
>  vc1image_decoder_select="vc1_decoder"
>  vorbis_decoder_select="mdct"
>  vorbis_encoder_select="audio_frame_queue mdct"
> -vp3_decoder_select="hpeldsp vp3dsp videodsp"
> +vp3_decoder_select="hpeldsp jpegtables vp3dsp videodsp"
>  vp4_decoder_select="vp3_decoder"
>  vp5_decoder_select="h264chroma hpeldsp videodsp vp3dsp vp56dsp"
>  vp6_decoder_select="h264chroma hpeldsp huffman videodsp vp3dsp vp56dsp"
> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> index 017aa0e1fa..614bf92d97 100644
> --- a/libavcodec/agm.c
> +++ b/libavcodec/agm.c
> @@ -33,24 +33,7 @@
>  #include "decode.h"
>  #include "get_bits.h"
>  #include "idctdsp.h"
> -
> -static const uint8_t unscaled_luma[64] = {
> -16, 11, 10, 16, 24, 40, 51, 61, 12, 12, 14, 19,
> -26, 58, 60, 55, 14, 13, 16, 24, 40, 57, 69, 56,
> -14, 17, 22, 29, 51, 87, 80, 62, 18, 22, 37, 56,
> -68,109,103, 77, 24, 35, 55, 64, 81,104,113, 92,
> -49, 64, 78, 87,103,121,120,101, 72, 92, 95, 98,
> -112,100,103,99
> -};
> -
> -static const uint8_t unscaled_chroma[64] = {
> -17, 18, 24, 47, 99, 99, 99, 99, 18, 21, 26, 66,
> -99, 99, 99, 99, 24, 26, 56, 99, 99, 99, 99, 99,
> -47, 66, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
> -99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
> -99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
> -99, 99, 99, 99
> -};
> +#include "jpegtables.h"
>  
>  typedef struct MotionVector {
>  int16_t x, y;
> @@ -550,13 +533,13 @@ static void compute_quant_matrix(AGMContext *s, double 
> qscale)
>  } else {
>  if (qscale >= 0.0) {
>  for (int i = 0; i < 64; i++) {
> -luma[i]   = FFMAX(1, unscaled_luma  [(i & 7) * 8 + (i >> 3)] 
> * f);
> -chroma[i] = FFMAX(1, unscaled_chroma[(i & 7) * 8 + (i >> 3)] 
> * f);
> +luma[i]   = FFMAX(1, ff_mjpeg_std_luminance_quant_tbl  [(i & 
> 7) * 8 + (i >> 3)] * f);
> +chroma[i] = FFMAX(1, ff_mjpeg_std_chrominance_quant_tbl[(i & 
> 7) * 8 + (i >> 3)] * f);
>  }
>  } else {
>  for (int i = 0; i < 64; i++) {
> -luma[i]   = FFMAX(1, 255.0 - (255 - unscaled_luma  [(i & 7) 
> * 8 + (i >> 3)]) * f);
> -chroma[i] = FFMAX(1, 255.0 - (255 - unscaled_chroma[(i & 7) 
> * 8 + (i >> 3)]) * f);
> +luma[i]   = FFMAX(1, 255.0 - (255 - 
> ff_mjpeg_std_luminance_quant_tbl  [(i & 7) * 8 + (i >> 3)]) * f);
> +chroma[i] = FFMAX(1, 255.0 - (255 - 
> ff_mjpeg_std_chrominance_quant_tbl[(i & 7) * 8 + (i >> 3)]) * f);
>  }
>  }
>  }
> diff --git a/libavcodec/jpegtables.c b/libavcodec/jpegtables.c
> index e453fcf90d..fadb40527e 100644
> --- a/libavcodec/jpegtables.c
> +++ b/libavcodec/jpegtables.c
> @@ -32,12 +32,11 @@
>  
>  #include "jpegtabs.h"
>  
> -#if 0
>  /* These are the sample quantization tables given in JPEG spec section K.1.
>   * The spec says that the values given produce "good" quality, and
>   * when divided by 2, "very good" quality.
>   */
> -static const unsigned char std_luminance_quant_tbl[64] = {
> +

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

[Gyan Doshi]

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_offset, breaking
of -isync as well as breaking wrap correction.

Fixed by taking cognizance of these parameters, and by correcting start
times just before sync offsets are applied.

Out of interest and sorry for not testing this myself: does this
improve the current state of affairs with itsoffset with discontinuous
inputs like MPEG-TS?


I just recompute the tsoffset the same way but with the effective new 
start time.



Until now the offset was put together with a whole bunch of other
things, which led to logic which was supposed to only start the input
at PTS=0 to also take out the configured itsoffset at the same time
(since both the user defined offset as well as the format start time
offset were both chunked into the same thing).


That's not my experience.
If the itsoffset is 5 and the first packet timestamp is 40, then only 
the 40 is negated and the packet is relayed with a ts of 5.

Isn't that what's expected?

Regards,
Gyan




Cheers,
Jan
___
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] ffmpeg: fix implementation of updated input start time

[Jan Ekström]

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 breaking wrap correction.
>
> Fixed by taking cognizance of these parameters, and by correcting start
> times just before sync offsets are applied.

Out of interest and sorry for not testing this myself: does this
improve the current state of affairs with itsoffset with discontinuous
inputs like MPEG-TS?

Until now the offset was put together with a whole bunch of other
things, which led to logic which was supposed to only start the input
at PTS=0 to also take out the configured itsoffset at the same time
(since both the user defined offset as well as the format start time
offset were both chunked into the same thing).

Cheers,
Jan
___
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: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 decoding

[Wu Jianhua]

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.com:
>
>>> Lynne wrote:
>>>
>>> Oct 12, 2022, 13:09 by toq...@outlook.com:
>>>
 [PATCH] avcodec: add D3D12VA hardware accelerated H264, HEVC, VP9, and AV1 
 decoding

 Patch attached.

>>> The Sync locking functions and the queue locking functions should
>>> be a function pointer in the device/frame context. Vulkan has
>>> the same issue, and that's how I did it there. This allows for
>>> API users to plug their own locking primitives in, which they need
>>> to in case they initialize their own contexts.
>>>
>>
>> I don’t need to follow your design.
>>
>
> Yes, you do, because it's not my design, it's the design of the entire
> hwcontext system. If API users cannot initialize a hwcontext with
> their own, it's breakage. It's not optional.
> Locking primitives are a part of this.
> Either fix this or this is simply not getting merged.
>

As I learn from the docs of Direct3D12, it is a multithreading-friendly API,
which means that the only mandatory field, device, set by the user can be
accessed and used without any lock. Why do the API users need locking
primitives to init the hwcontext_d3d12va? Have you got the initialization
failed? If so, could you share the runtime error details here?

And I checked the other hwcontexts, they didn't have a locking primitive also.
The hwcontext_d3d11va has a locking used to protect accesses to device_context
and video_context calls, which d3d12 doesn't need. So why the API users cannot
initialize the hwcontext with their own? Is there any real failure case? Please 
pardon
I don't quite understand what situation you are talking about, could you 
elaborate
further if I get it wrong?

>
>>> You should also document which fields API users have to set
>>> themselves if they plan to use their own context.
>>>
>>
>> Where should I document them? Doesn’t the comments enough?
>>

> In the comments. Look at how it's done elsewhere.
There is already a comment like what d3d11va wrote:
/**
 * Device used for objects creation and access. This can also be
 * used to set the libavcodec decoding device.
 *
 * Can be set by the user. This is the only mandatory field - the other
 * device context fields are set from this and are available for 
convenience.
 *
 * Deallocating the AVHWDeviceContext will always release this interface,
 * and it does not matter whether it was user-allocated.
 */
ID3D12Device *device;

Is there anything else missing?

>>> Also, struct names in the public context lack an AV prefix.
>>>
>> Will fix. And which struct? Could you add the reference?
>>
>
> In the main public context.
>
I check the codes and found that AVD3D12VASyncContext, AVD3D12VADeviceContext,
AVD3D12FrameDescriptor and AVD3D12VAFramesContext are the structs in
the hwcontext_d3d12va. Is there any other struct without AV prefix? Could you
paste the name here?

>>> D3D12VA_MAX_SURFACES is a terrible hack. Vendors should
>>> fix their own drivers rather than users running out of memory.
>>>
>>
>> Not my responsibility as a personal developer. I know nothing
>> about the drivers. You can ask those vendors to fix them. I don’t
>> think it’s a `terrible hack`. On my test, The MAX_SURFACES is
>> enough for the decoder. If there are any docs or the drivers fixed
>> it, just simply remove it. Why user will run out of memory?
>>
>
> The whole way the hwcontext is designed is sketchy. Why are
> you keeping all texture information in an array (texture_infos)?Frames are 
> already pooled (it's called AVFramePool), so you're
> not doing anything by adding a second layer on top of this other
> than complexity.
> The initial_pool_size parameter was a hack added to support
> hwcontexts which cannot allocate surfaces dynamically, you don't
> need to support this at all, you can just let users allocate
> frames as they need to rather than preinitializing.
>

It’s the same implementation as d3d11va. The static initial_pool_size is
needed by the decoder heap to initialize and the input stream needs it
as well The feature that allows the user to allocate frames is not the basic
functionalities of decoding. I recommend the user who needs the feature
implement it and contribute the codes.

>>> Also, you have code style issues, don't wrap one-line if statements
>>> or loops in brackets.
>>>
>> Will fix. And which loop? Could you add the reference?
>>
>>> ff_d3d12dec_get_suitable_max_bitstream_size is an awful function.
>>> It does float math for sizes and has a magic mult factor of 1.5.
>>> You have to calculate this properly.
>>>
>> It simply calculate the size of NV12 and P010. Will add comment.
>>
>
>Do it _properly_. We have utilities for 

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

[Anton Khirnov]

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
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -164,8 +164,10 @@ static int get_preset_file_2(const char *preset_name, 
const char *codec_name, AV
 return ret;
 }
 
-static OutputStream *new_output_stream(OptionsContext *o, AVFormatContext *oc, 
enum AVMediaType type, int source_index)
+static OutputStream *new_output_stream(Muxer *mux, OptionsContext *o,
+   enum AVMediaType type, int source_index)
 {
+AVFormatContext *oc = mux->fc;
 OutputStream *ost;
 const AVCodec *enc;
 AVStream *st = avformat_new_stream(oc, NULL);
@@ -403,13 +405,14 @@ static void parse_matrix_coeffs(uint16_t *dest, const 
char *str)
 }
 }
 
-static OutputStream *new_video_stream(OptionsContext *o, AVFormatContext *oc, 
int source_index)
+static OutputStream *new_video_stream(Muxer *mux, OptionsContext *o, int 
source_index)
 {
+AVFormatContext *oc = mux->fc;
 AVStream *st;
 OutputStream *ost;
 char *frame_rate = NULL, *max_frame_rate = NULL, *frame_aspect_ratio = 
NULL;
 
-ost = new_output_stream(o, oc, AVMEDIA_TYPE_VIDEO, source_index);
+ost = new_output_stream(mux, o, AVMEDIA_TYPE_VIDEO, source_index);
 st  = ost->st;
 
 MATCH_PER_STREAM_OPT(frame_rates, str, frame_rate, oc, st);
@@ -636,12 +639,13 @@ static OutputStream *new_video_stream(OptionsContext *o, 
AVFormatContext *oc, in
 return ost;
 }
 
-static OutputStream *new_audio_stream(OptionsContext *o, AVFormatContext *oc, 
int source_index)
+static OutputStream *new_audio_stream(Muxer *mux, OptionsContext *o, int 
source_index)
 {
+AVFormatContext *oc = mux->fc;
 AVStream *st;
 OutputStream *ost;
 
-ost = new_output_stream(o, oc, AVMEDIA_TYPE_AUDIO, source_index);
+ost = new_output_stream(mux, o, AVMEDIA_TYPE_AUDIO, source_index);
 st  = ost->st;
 
 
@@ -733,11 +737,11 @@ static OutputStream *new_audio_stream(OptionsContext *o, 
AVFormatContext *oc, in
 return ost;
 }
 
-static OutputStream *new_data_stream(OptionsContext *o, AVFormatContext *oc, 
int source_index)
+static OutputStream *new_data_stream(Muxer *mux, OptionsContext *o, int 
source_index)
 {
 OutputStream *ost;
 
-ost = new_output_stream(o, oc, AVMEDIA_TYPE_DATA, source_index);
+ost = new_output_stream(mux, o, AVMEDIA_TYPE_DATA, source_index);
 if (ost->enc_ctx) {
 av_log(NULL, AV_LOG_FATAL, "Data stream encoding not supported yet 
(only streamcopy)\n");
 exit_program(1);
@@ -746,11 +750,11 @@ static OutputStream *new_data_stream(OptionsContext *o, 
AVFormatContext *oc, int
 return ost;
 }
 
-static OutputStream *new_unknown_stream(OptionsContext *o, AVFormatContext 
*oc, int source_index)
+static OutputStream *new_unknown_stream(Muxer *mux, OptionsContext *o, int 
source_index)
 {
 OutputStream *ost;
 
-ost = new_output_stream(o, oc, AVMEDIA_TYPE_UNKNOWN, source_index);
+ost = new_output_stream(mux, o, AVMEDIA_TYPE_UNKNOWN, source_index);
 if (ost->enc_ctx) {
 av_log(NULL, AV_LOG_FATAL, "Unknown stream encoding not supported yet 
(only streamcopy)\n");
 exit_program(1);
@@ -759,26 +763,26 @@ static OutputStream *new_unknown_stream(OptionsContext 
*o, AVFormatContext *oc,
 return ost;
 }
 
-static OutputStream *new_attachment_stream(OptionsContext *o, AVFormatContext 
*oc, int source_index)
+static OutputStream *new_attachment_stream(Muxer *mux, OptionsContext *o, int 
source_index)
 {
-OutputStream *ost = new_output_stream(o, oc, AVMEDIA_TYPE_ATTACHMENT, 
source_index);
+OutputStream *ost = new_output_stream(mux, o, AVMEDIA_TYPE_ATTACHMENT, 
source_index);
 ost->finished= 1;
 return ost;
 }
 
-static OutputStream *new_subtitle_stream(OptionsContext *o, AVFormatContext 
*oc, int source_index)
+static OutputStream *new_subtitle_stream(Muxer *mux, OptionsContext *o, int 
source_index)
 {
 AVStream *st;
 OutputStream *ost;
 
-ost = new_output_stream(o, oc, AVMEDIA_TYPE_SUBTITLE, source_index);
+ost = new_output_stream(mux, o, AVMEDIA_TYPE_SUBTITLE, source_index);
 st  = ost->st;
 
 if (ost->enc_ctx) {
 AVCodecContext *subtitle_enc = ost->enc_ctx;
 char *frame_size = NULL;
 
-MATCH_PER_STREAM_OPT(frame_sizes, str, frame_size, oc, st);
+MATCH_PER_STREAM_OPT(frame_sizes, str, frame_size, mux->fc, st);
 if (frame_size && av_parse_video_size(&subtitle_enc->width, 
&subtitle_enc->height, frame_size) < 0) {
 av_log(NULL, AV_LOG_FATAL, "Invalid frame size: %s.\n", 
frame_size);
 exit_program(1);
@@ -789,13 +793,13 @@ static OutputStream *new_subtitle_stream(OptionsContext 
*o, AVFormatContext *oc,
 }
 
 static vo

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

[Anton Khirnov]

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 +
 fftools/ffmpeg_mux.h  |  5 ++---
 fftools/ffmpeg_mux_init.c | 23 +--
 3 files changed, 28 insertions(+), 33 deletions(-)

diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 032b2ac34c..4ad69a149a 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -45,6 +45,11 @@ static Muxer *mux_from_of(OutputFile *of)
 return (Muxer*)of;
 }
 
+static MuxStream *ms_from_ost(OutputStream *ost)
+{
+return (MuxStream*)ost;
+}
+
 static int64_t filesize(AVIOContext *pb)
 {
 int64_t ret = -1;
@@ -60,7 +65,7 @@ static int64_t filesize(AVIOContext *pb)
 
 static int write_packet(Muxer *mux, OutputStream *ost, AVPacket *pkt)
 {
-MuxStream *ms = &mux->streams[ost->index];
+MuxStream *ms = ms_from_ost(ost);
 AVFormatContext *s = mux->fc;
 AVStream *st = ost->st;
 int64_t fs;
@@ -251,7 +256,7 @@ finish:
 
 static int queue_packet(Muxer *mux, OutputStream *ost, AVPacket *pkt)
 {
-MuxStream *ms = &mux->streams[ost->index];
+MuxStream *ms = ms_from_ost(ost);
 AVPacket *tmp_pkt = NULL;
 int ret;
 
@@ -409,8 +414,8 @@ static int thread_start(Muxer *mux)
 
 /* flush the muxing queues */
 for (int i = 0; i < fc->nb_streams; i++) {
-MuxStream *ms = &mux->streams[i];
 OutputStream *ost = mux->of.streams[i];
+MuxStream *ms = ms_from_ost(ost);
 AVPacket *pkt;
 
 /* try to improve muxing time_base (only possible if nothing has been 
written yet) */
@@ -626,9 +631,11 @@ int of_write_trailer(OutputFile *of)
 static void ost_free(OutputStream **post)
 {
 OutputStream *ost = *post;
+MuxStream *ms;
 
 if (!ost)
 return;
+ms = ms_from_ost(ost);
 
 if (ost->logfile) {
 if (fclose(ost->logfile))
@@ -638,6 +645,13 @@ static void ost_free(OutputStream **post)
 ost->logfile = NULL;
 }
 
+if (ms->muxing_queue) {
+AVPacket *pkt;
+while (av_fifo_read(ms->muxing_queue, &pkt, 1) >= 0)
+av_packet_free(&pkt);
+av_fifo_freep2(&ms->muxing_queue);
+}
+
 av_bsf_free(&ost->bsf_ctx);
 
 av_frame_free(&ost->filtered_frame);
@@ -697,19 +711,6 @@ void of_close(OutputFile **pof)
 sq_free(&of->sq_encode);
 sq_free(&mux->sq_mux);
 
-for (int i = 0; i < mux->nb_streams; i++) {
-MuxStream *ms = &mux->streams[i];
-AVPacket *pkt;
-
-if (!ms->muxing_queue)
-continue;
-
-while (av_fifo_read(ms->muxing_queue, &pkt, 1) >= 0)
-av_packet_free(&pkt);
-av_fifo_freep2(&ms->muxing_queue);
-}
-av_freep(&mux->streams);
-
 for (int i = 0; i < of->nb_streams; i++)
 ost_free(&of->streams[i]);
 av_freep(&of->streams);
diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
index b73b6c628b..45daeb3591 100644
--- a/fftools/ffmpeg_mux.h
+++ b/fftools/ffmpeg_mux.h
@@ -35,6 +35,8 @@
 #include "libavutil/thread.h"
 
 typedef struct MuxStream {
+OutputStream ost;
+
 /* the packets are buffered here until the muxer is ready to be 
initialized */
 AVFifo *muxing_queue;
 
@@ -57,9 +59,6 @@ typedef struct Muxer {
 pthread_tthread;
 ThreadQueue *tq;
 
-MuxStream *streams;
-int nb_streams;
-
 AVDictionary *opts;
 
 int thread_queue_size;
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 6909a017d8..d6bae92513 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -168,6 +168,7 @@ static OutputStream *new_output_stream(Muxer *mux, 
OptionsContext *o,
enum AVMediaType type, int source_index)
 {
 AVFormatContext *oc = mux->fc;
+MuxStream *ms;
 OutputStream *ost;
 const AVCodec *enc;
 AVStream *st = avformat_new_stream(oc, NULL);
@@ -183,7 +184,14 @@ static OutputStream *new_output_stream(Muxer *mux, 
OptionsContext *o,
 if (oc->nb_streams - 1 < o->nb_streamid_map)
 st->id = o->streamid_map[oc->nb_streams - 1];
 
-ost = ALLOC_ARRAY_ELEM(mux->of.streams, mux->of.nb_streams);
+ms  = allocate_array_elem(&mux->of.streams, sizeof(MuxStream),
+  &mux->of.nb_streams);
+ost = &ms->ost;
+
+ms->muxing_queue = av_fifo_alloc2(8, sizeof(AVPacket*), 0);
+if (!ms->muxing_queue)
+report_and_exit(AVERROR(ENOMEM));
+ms->last_mux_dts = AV_NOPTS_VALUE;
 
 ost->file_index = nb_output_files - 1;
 ost->index  = idx;
@@ -1900,19 +1908,6 @@ int of_open(OptionsContext *o, const char *filename)
 
 of->url= filename;
 
-mux->streams = av_calloc(oc->nb_streams, sizeof(*mux->streams));
-if (!mux->streams)
-return 

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

[Anton Khirnov]

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/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 0af824b9b9..b98bb45331 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -510,8 +510,6 @@ typedef struct OutputStream {
 AVRational mux_timebase;
 AVRational enc_timebase;
 
-AVBSFContext*bsf_ctx;
-
 AVCodecContext *enc_ctx;
 int64_t max_frames;
 AVFrame *filtered_frame;
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 4ad69a149a..525c15b4ae 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -318,6 +318,7 @@ static int submit_packet(Muxer *mux, AVPacket *pkt, 
OutputStream *ost)
 void of_output_packet(OutputFile *of, AVPacket *pkt, OutputStream *ost, int 
eof)
 {
 Muxer *mux = mux_from_of(of);
+MuxStream *ms = ms_from_ost(ost);
 const char *err_msg;
 int ret = 0;
 
@@ -325,17 +326,17 @@ void of_output_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost, int eof)
 ost->last_mux_dts = av_rescale_q(pkt->dts, ost->mux_timebase, 
AV_TIME_BASE_Q);
 
 /* apply the output bitstream filters */
-if (ost->bsf_ctx) {
+if (ms->bsf_ctx) {
 int bsf_eof = 0;
 
-ret = av_bsf_send_packet(ost->bsf_ctx, eof ? NULL : pkt);
+ret = av_bsf_send_packet(ms->bsf_ctx, eof ? NULL : pkt);
 if (ret < 0) {
 err_msg = "submitting a packet for bitstream filtering";
 goto fail;
 }
 
 while (!bsf_eof) {
-ret = av_bsf_receive_packet(ost->bsf_ctx, pkt);
+ret = av_bsf_receive_packet(ms->bsf_ctx, pkt);
 if (ret == AVERROR(EAGAIN))
 return;
 else if (ret == AVERROR_EOF)
@@ -541,9 +542,10 @@ int mux_check_init(Muxer *mux)
 return 0;
 }
 
-static int bsf_init(OutputStream *ost)
+static int bsf_init(MuxStream *ms)
 {
-AVBSFContext *ctx = ost->bsf_ctx;
+OutputStream *ost = &ms->ost;
+AVBSFContext *ctx = ms->bsf_ctx;
 int ret;
 
 if (!ctx)
@@ -573,6 +575,7 @@ static int bsf_init(OutputStream *ost)
 int of_stream_init(OutputFile *of, OutputStream *ost)
 {
 Muxer *mux = mux_from_of(of);
+MuxStream *ms = ms_from_ost(ost);
 int ret;
 
 if (ost->sq_idx_mux >= 0)
@@ -581,7 +584,7 @@ int of_stream_init(OutputFile *of, OutputStream *ost)
 /* initialize bitstream filters for the output stream
  * needs to be done here, because the codec id for streamcopy is not
  * known until now */
-ret = bsf_init(ost);
+ret = bsf_init(ms);
 if (ret < 0)
 return ret;
 
@@ -652,7 +655,7 @@ static void ost_free(OutputStream **post)
 av_fifo_freep2(&ms->muxing_queue);
 }
 
-av_bsf_free(&ost->bsf_ctx);
+av_bsf_free(&ms->bsf_ctx);
 
 av_frame_free(&ost->filtered_frame);
 av_frame_free(&ost->sq_frame);
diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
index 45daeb3591..8470f971cc 100644
--- a/fftools/ffmpeg_mux.h
+++ b/fftools/ffmpeg_mux.h
@@ -40,6 +40,8 @@ typedef struct MuxStream {
 /* the packets are buffered here until the muxer is ready to be 
initialized */
 AVFifo *muxing_queue;
 
+AVBSFContext *bsf_ctx;
+
 /*
  * The size of the AVPackets' buffers in queue.
  * Updated when a packet is either pushed or pulled from the queue.
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index d6bae92513..3f2db04f52 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -304,7 +304,7 @@ static OutputStream *new_output_stream(Muxer *mux, 
OptionsContext *o,
 
 MATCH_PER_STREAM_OPT(bitstream_filters, str, bsfs, oc, st);
 if (bsfs && *bsfs) {
-ret = av_bsf_list_parse_str(bsfs, &ost->bsf_ctx);
+ret = av_bsf_list_parse_str(bsfs, &ms->bsf_ctx);
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Error parsing bitstream filter 
sequence '%s': %s\n", bsfs, av_err2str(ret));
 exit_program(1);
-- 
2.35.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 19/22] fftools/ffmpeg: free output streams in of_close()

[Anton Khirnov]

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/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4e9ea731ff..ceb26145a3 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -502,52 +502,6 @@ static int decode_interrupt_cb(void *ctx)
 
 const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL };
 
-static void ost_free(OutputStream **post)
-{
-OutputStream *ost = *post;
-
-if (!ost)
-return;
-
-if (ost->logfile) {
-if (fclose(ost->logfile))
-av_log(NULL, AV_LOG_ERROR,
-   "Error closing logfile, loss of information possible: %s\n",
-   av_err2str(AVERROR(errno)));
-ost->logfile = NULL;
-}
-
-av_bsf_free(&ost->bsf_ctx);
-
-av_frame_free(&ost->filtered_frame);
-av_frame_free(&ost->sq_frame);
-av_frame_free(&ost->last_frame);
-av_packet_free(&ost->pkt);
-av_dict_free(&ost->encoder_opts);
-
-av_freep(&ost->forced_keyframes);
-av_expr_free(ost->forced_keyframes_pexpr);
-av_freep(&ost->avfilter);
-av_freep(&ost->logfile_prefix);
-av_freep(&ost->forced_kf_pts);
-av_freep(&ost->apad);
-av_freep(&ost->disposition);
-
-#if FFMPEG_OPT_MAP_CHANNEL
-av_freep(&ost->audio_channels_map);
-ost->audio_channels_mapped = 0;
-#endif
-
-av_dict_free(&ost->sws_dict);
-av_dict_free(&ost->swr_opts);
-
-if (ost->enc_ctx)
-av_freep(&ost->enc_ctx->stats_in);
-avcodec_free_context(&ost->enc_ctx);
-
-av_freep(post);
-}
-
 static void ffmpeg_cleanup(int ret)
 {
 int i, j;
@@ -598,15 +552,8 @@ static void ffmpeg_cleanup(int ret)
 av_freep(&filtergraphs);
 
 /* close files */
-for (i = 0; i < nb_output_files; i++) {
-OutputFile *of = output_files[i];
-
-for (int j = 0; j < of->nb_streams; j++)
-ost_free(&of->streams[j]);
-av_freep(&of->streams);
-
+for (i = 0; i < nb_output_files; i++)
 of_close(&output_files[i]);
-}
 
 free_input_threads();
 for (i = 0; i < nb_input_files; i++) {
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index a110691f6a..032b2ac34c 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -623,6 +623,52 @@ int of_write_trailer(OutputFile *of)
 return 0;
 }
 
+static void ost_free(OutputStream **post)
+{
+OutputStream *ost = *post;
+
+if (!ost)
+return;
+
+if (ost->logfile) {
+if (fclose(ost->logfile))
+av_log(NULL, AV_LOG_ERROR,
+   "Error closing logfile, loss of information possible: %s\n",
+   av_err2str(AVERROR(errno)));
+ost->logfile = NULL;
+}
+
+av_bsf_free(&ost->bsf_ctx);
+
+av_frame_free(&ost->filtered_frame);
+av_frame_free(&ost->sq_frame);
+av_frame_free(&ost->last_frame);
+av_packet_free(&ost->pkt);
+av_dict_free(&ost->encoder_opts);
+
+av_freep(&ost->forced_keyframes);
+av_expr_free(ost->forced_keyframes_pexpr);
+av_freep(&ost->avfilter);
+av_freep(&ost->logfile_prefix);
+av_freep(&ost->forced_kf_pts);
+av_freep(&ost->apad);
+av_freep(&ost->disposition);
+
+#if FFMPEG_OPT_MAP_CHANNEL
+av_freep(&ost->audio_channels_map);
+ost->audio_channels_mapped = 0;
+#endif
+
+av_dict_free(&ost->sws_dict);
+av_dict_free(&ost->swr_opts);
+
+if (ost->enc_ctx)
+av_freep(&ost->enc_ctx->stats_in);
+avcodec_free_context(&ost->enc_ctx);
+
+av_freep(post);
+}
+
 static void fc_close(AVFormatContext **pfc)
 {
 AVFormatContext *fc = *pfc;
@@ -663,6 +709,11 @@ void of_close(OutputFile **pof)
 av_fifo_freep2(&ms->muxing_queue);
 }
 av_freep(&mux->streams);
+
+for (int i = 0; i < of->nb_streams; i++)
+ost_free(&of->streams[i]);
+av_freep(&of->streams);
+
 av_dict_free(&mux->opts);
 
 av_packet_free(&mux->sq_pkt);
-- 
2.35.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 22/22] fftools/ffmpeg_mux: move muxing queue fields from OutputStream to MuxStream

[Anton Khirnov]

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/fftools/ffmpeg.h b/fftools/ffmpeg.h
index b98bb45331..8f03d638c3 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -596,11 +596,6 @@ typedef struct OutputStream {
 /* packet quality factor */
 int quality;
 
-int max_muxing_queue_size;
-
-/* Threshold after which max_muxing_queue_size will be in effect */
-size_t muxing_queue_data_threshold;
-
 /* packet picture type */
 int pict_type;
 
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 525c15b4ae..2b70143978 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -264,8 +264,8 @@ static int queue_packet(Muxer *mux, OutputStream *ost, 
AVPacket *pkt)
 size_t cur_size = av_fifo_can_read(ms->muxing_queue);
 size_t pkt_size = pkt ? pkt->size : 0;
 unsigned int are_we_over_size =
-(ms->muxing_queue_data_size + pkt_size) > 
ost->muxing_queue_data_threshold;
-size_t limit= are_we_over_size ? ost->max_muxing_queue_size : 
SIZE_MAX;
+(ms->muxing_queue_data_size + pkt_size) > 
ms->muxing_queue_data_threshold;
+size_t limit= are_we_over_size ? ms->max_muxing_queue_size : 
SIZE_MAX;
 size_t new_size = FFMIN(2 * cur_size, limit);
 
 if (new_size <= cur_size) {
diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
index 8470f971cc..6ea7c692ef 100644
--- a/fftools/ffmpeg_mux.h
+++ b/fftools/ffmpeg_mux.h
@@ -48,6 +48,11 @@ typedef struct MuxStream {
  */
 size_t muxing_queue_data_size;
 
+int max_muxing_queue_size;
+
+/* Threshold after which max_muxing_queue_size will be in effect */
+size_t muxing_queue_data_threshold;
+
 /* dts of the last packet sent to the muxer, in the stream timebase
  * used for making up missing dts values */
 int64_t last_mux_dts;
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 3f2db04f52..24b4631326 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -330,11 +330,11 @@ static OutputStream *new_output_stream(Muxer *mux, 
OptionsContext *o,
 MATCH_PER_STREAM_OPT(disposition, str, ost->disposition, oc, st);
 ost->disposition = av_strdup(ost->disposition);
 
-ost->max_muxing_queue_size = 128;
-MATCH_PER_STREAM_OPT(max_muxing_queue_size, i, ost->max_muxing_queue_size, 
oc, st);
+ms->max_muxing_queue_size = 128;
+MATCH_PER_STREAM_OPT(max_muxing_queue_size, i, ms->max_muxing_queue_size, 
oc, st);
 
-ost->muxing_queue_data_threshold = 50*1024*1024;
-MATCH_PER_STREAM_OPT(muxing_queue_data_threshold, i, 
ost->muxing_queue_data_threshold, oc, st);
+ms->muxing_queue_data_threshold = 50*1024*1024;
+MATCH_PER_STREAM_OPT(muxing_queue_data_threshold, i, 
ms->muxing_queue_data_threshold, oc, st);
 
 MATCH_PER_STREAM_OPT(bits_per_raw_sample, i, ost->bits_per_raw_sample,
  oc, st);
-- 
2.35.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 17/22] fftools/ffmpeg: remove the output_streams global

[Anton Khirnov]

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 ++
 fftools/ffmpeg.h  |   7 +--
 fftools/ffmpeg_filter.c   |   2 +-
 fftools/ffmpeg_mux.c  |  10 ++--
 fftools/ffmpeg_mux.h  |   1 +
 fftools/ffmpeg_mux_init.c |  54 +
 6 files changed, 97 insertions(+), 98 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f426dbc80f..b98065d2a0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -146,8 +146,6 @@ intnb_input_streams = 0;
 InputFile   **input_files   = NULL;
 intnb_input_files   = 0;
 
-OutputStream **output_streams = NULL;
-int nb_output_streams = 0;
 OutputFile   **output_files   = NULL;
 int nb_output_files   = 0;
 
@@ -589,11 +587,15 @@ static void ffmpeg_cleanup(int ret)
 av_freep(&filtergraphs);
 
 /* close files */
-for (i = 0; i < nb_output_files; i++)
-of_close(&output_files[i]);
+for (i = 0; i < nb_output_files; i++) {
+OutputFile *of = output_files[i];
+
+for (int j = 0; j < of->nb_streams; j++)
+ost_free(&of->streams[j]);
+av_freep(&of->streams);
 
-for (i = 0; i < nb_output_streams; i++)
-ost_free(&output_streams[i]);
+of_close(&output_files[i]);
+}
 
 free_input_threads();
 for (i = 0; i < nb_input_files; i++) {
@@ -629,7 +631,6 @@ static void ffmpeg_cleanup(int ret)
 
 av_freep(&input_streams);
 av_freep(&input_files);
-av_freep(&output_streams);
 av_freep(&output_files);
 
 uninit_opts();
@@ -646,6 +647,24 @@ static void ffmpeg_cleanup(int ret)
 ffmpeg_exited = 1;
 }
 
+/* iterate over all output streams in all output files;
+ * pass NULL to start iteration */
+static OutputStream *ost_iter(OutputStream *prev)
+{
+int of_idx  = prev ? prev->file_index : 0;
+int ost_idx = prev ? prev->index + 1  : 0;
+
+for (; of_idx < nb_output_files; of_idx++) {
+OutputFile *of = output_files[of_idx];
+for (; ost_idx < of->nb_streams; ost_idx++)
+return of->streams[ost_idx];
+
+ost_idx = 0;
+}
+
+return NULL;
+}
+
 void remove_avoptions(AVDictionary **a, AVDictionary *b)
 {
 const AVDictionaryEntry *t = NULL;
@@ -1308,11 +1327,9 @@ static void do_video_out(OutputFile *of,
 static int reap_filters(int flush)
 {
 AVFrame *filtered_frame = NULL;
-int i;
 
 /* Reap all buffers present in the buffer sinks */
-for (i = 0; i < nb_output_streams; i++) {
-OutputStream *ost = output_streams[i];
+for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) {
 OutputFile*of = output_files[ost->file_index];
 AVFilterContext *filter;
 AVCodecContext *enc = ost->enc_ctx;
@@ -1397,8 +1414,7 @@ static void print_final_stats(int64_t total_size)
 int i, j;
 int pass1_used = 1;
 
-for (i = 0; i < nb_output_streams; i++) {
-OutputStream *ost = output_streams[i];
+for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) {
 AVCodecParameters *par = ost->st->codecpar;
 const uint64_t s = ost->data_size_mux;
 
@@ -1474,7 +1490,7 @@ static void print_final_stats(int64_t total_size)
i, of->url);
 
 for (j = 0; j < of->nb_streams; j++) {
-OutputStream *ost = output_streams[of->ost_index + j];
+OutputStream *ost = of->streams[j];
 enum AVMediaType type = ost->st->codecpar->codec_type;
 
 total_size+= ost->data_size_mux;
@@ -1513,7 +1529,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 {
 AVBPrint buf, buf_script;
 int64_t total_size = of_filesize(output_files[0]);
-int vid, i;
+int vid;
 double bitrate;
 double speed;
 int64_t pts = INT64_MIN + 1;
@@ -1543,8 +1559,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 vid = 0;
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
 av_bprint_init(&buf_script, 0, AV_BPRINT_SIZE_AUTOMATIC);
-for (i = 0; i < nb_output_streams; i++) {
-OutputStream * const ost = output_streams[i];
+for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) {
 const AVCodecContext * const enc = ost->enc_ctx;
 const float q = enc ? ost->quality / (float) FF_QP2LAMBDA : -1;
 
@@ -1727,17 +1742,15 @@ static int ifilter_parameters_from_codecpar(InputFilter 
*ifilter, AVCodecParamet
 
 static void flush_encoders(void)
 {
-int i, ret;
+int ret;
 
-for (i = 0; i < nb_output_streams; i++) {
-OutputStream   *ost = output_streams[i];
+for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) {
 OutputFile  *of = output_fi

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

[Anton Khirnov]

---
 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_interrupt_cb(void *ctx)
 
 const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL };
 
+static void ost_free(OutputStream **post)
+{
+OutputStream *ost = *post;
+
+if (!ost)
+return;
+
+av_bsf_free(&ost->bsf_ctx);
+
+av_frame_free(&ost->filtered_frame);
+av_frame_free(&ost->sq_frame);
+av_frame_free(&ost->last_frame);
+av_packet_free(&ost->pkt);
+av_dict_free(&ost->encoder_opts);
+
+av_freep(&ost->forced_keyframes);
+av_expr_free(ost->forced_keyframes_pexpr);
+av_freep(&ost->avfilter);
+av_freep(&ost->logfile_prefix);
+
+#if FFMPEG_OPT_MAP_CHANNEL
+av_freep(&ost->audio_channels_map);
+ost->audio_channels_mapped = 0;
+#endif
+
+av_dict_free(&ost->sws_dict);
+av_dict_free(&ost->swr_opts);
+
+if (ost->enc_ctx)
+av_freep(&ost->enc_ctx->stats_in);
+avcodec_free_context(&ost->enc_ctx);
+
+av_freep(post);
+}
+
 static void ffmpeg_cleanup(int ret)
 {
 int i, j;
@@ -557,39 +592,9 @@ static void ffmpeg_cleanup(int ret)
 for (i = 0; i < nb_output_files; i++)
 of_close(&output_files[i]);
 
-for (i = 0; i < nb_output_streams; i++) {
-OutputStream *ost = output_streams[i];
-
-if (!ost)
-continue;
-
-av_bsf_free(&ost->bsf_ctx);
-
-av_frame_free(&ost->filtered_frame);
-av_frame_free(&ost->sq_frame);
-av_frame_free(&ost->last_frame);
-av_packet_free(&ost->pkt);
-av_dict_free(&ost->encoder_opts);
-
-av_freep(&ost->forced_keyframes);
-av_expr_free(ost->forced_keyframes_pexpr);
-av_freep(&ost->avfilter);
-av_freep(&ost->logfile_prefix);
-
-#if FFMPEG_OPT_MAP_CHANNEL
-av_freep(&ost->audio_channels_map);
-ost->audio_channels_mapped = 0;
-#endif
-
-av_dict_free(&ost->sws_dict);
-av_dict_free(&ost->swr_opts);
-
-if (ost->enc_ctx)
-av_freep(&ost->enc_ctx->stats_in);
-avcodec_free_context(&ost->enc_ctx);
+for (i = 0; i < nb_output_streams; i++)
+ost_free(&output_streams[i]);
 
-av_freep(&output_streams[i]);
-}
 free_input_threads();
 for (i = 0; i < nb_input_files; i++) {
 avformat_close_input(&input_files[i]->ctx);
-- 
2.35.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 18/22] fftools/ffmpeg: remove a cleanup block at the end of transcode()

[Anton Khirnov]

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/ffmpeg.c
index b98065d2a0..4e9ea731ff 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -509,6 +509,14 @@ static void ost_free(OutputStream **post)
 if (!ost)
 return;
 
+if (ost->logfile) {
+if (fclose(ost->logfile))
+av_log(NULL, AV_LOG_ERROR,
+   "Error closing logfile, loss of information possible: %s\n",
+   av_err2str(AVERROR(errno)));
+ost->logfile = NULL;
+}
+
 av_bsf_free(&ost->bsf_ctx);
 
 av_frame_free(&ost->filtered_frame);
@@ -521,6 +529,9 @@ static void ost_free(OutputStream **post)
 av_expr_free(ost->forced_keyframes_pexpr);
 av_freep(&ost->avfilter);
 av_freep(&ost->logfile_prefix);
+av_freep(&ost->forced_kf_pts);
+av_freep(&ost->apad);
+av_freep(&ost->disposition);
 
 #if FFMPEG_OPT_MAP_CHANNEL
 av_freep(&ost->audio_channels_map);
@@ -4033,24 +4044,6 @@ static int transcode(void)
  fail:
 free_input_threads();
 
-for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) {
-if (ost) {
-if (ost->logfile) {
-if (fclose(ost->logfile))
-av_log(NULL, AV_LOG_ERROR,
-   "Error closing logfile, loss of information 
possible: %s\n",
-   av_err2str(AVERROR(errno)));
-ost->logfile = NULL;
-}
-av_freep(&ost->forced_kf_pts);
-av_freep(&ost->apad);
-av_freep(&ost->disposition);
-av_dict_free(&ost->encoder_opts);
-av_dict_free(&ost->sws_dict);
-av_dict_free(&ost->swr_opts);
-}
-}
-
 return ret;
 }
 
-- 
2.35.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 15/22] fftools/ffmpeg: reindent after previous commit

[Anton Khirnov]

---
 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(OutputStream **post)
 if (!ost)
 return;
 
-av_bsf_free(&ost->bsf_ctx);
+av_bsf_free(&ost->bsf_ctx);
 
-av_frame_free(&ost->filtered_frame);
-av_frame_free(&ost->sq_frame);
-av_frame_free(&ost->last_frame);
-av_packet_free(&ost->pkt);
-av_dict_free(&ost->encoder_opts);
+av_frame_free(&ost->filtered_frame);
+av_frame_free(&ost->sq_frame);
+av_frame_free(&ost->last_frame);
+av_packet_free(&ost->pkt);
+av_dict_free(&ost->encoder_opts);
 
-av_freep(&ost->forced_keyframes);
-av_expr_free(ost->forced_keyframes_pexpr);
-av_freep(&ost->avfilter);
-av_freep(&ost->logfile_prefix);
+av_freep(&ost->forced_keyframes);
+av_expr_free(ost->forced_keyframes_pexpr);
+av_freep(&ost->avfilter);
+av_freep(&ost->logfile_prefix);
 
 #if FFMPEG_OPT_MAP_CHANNEL
-av_freep(&ost->audio_channels_map);
-ost->audio_channels_mapped = 0;
+av_freep(&ost->audio_channels_map);
+ost->audio_channels_mapped = 0;
 #endif
 
-av_dict_free(&ost->sws_dict);
-av_dict_free(&ost->swr_opts);
+av_dict_free(&ost->sws_dict);
+av_dict_free(&ost->swr_opts);
 
-if (ost->enc_ctx)
-av_freep(&ost->enc_ctx->stats_in);
-avcodec_free_context(&ost->enc_ctx);
+if (ost->enc_ctx)
+av_freep(&ost->enc_ctx->stats_in);
+avcodec_free_context(&ost->enc_ctx);
 
 av_freep(post);
 }
-- 
2.35.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 v2] lavc/hevc_ps: fix process failed when SPS before VPS in hvcC

[wangyaqiang]

> 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.
>> Added "parsed_vps" parameter to indicate whether VPS have been parsed.
>> Only VPS have been parsed can be verified during SPS parsing.
>> 
>> Signed-off-by: Wang Yaqiang 
>> ---
>> libavcodec/hevc_ps.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
> 
> This causes segfaults
> 
> ==816== Invalid read of size 8
> ==816==at 0xFAF178: hevc_parse (in ffmpeg_g)
> ==816==by 0xA7A2A6: av_parser_parse2 (in ffmpeg_g)
> ==816==by 0x5FC388: parse_packet (in ffmpeg_g)
> ==816==by 0x5FDC5D: read_frame_internal (in ffmpeg_g)
> ==816==by 0x5FFA10: avformat_find_stream_info (in ffmpeg_g)
> ==816==by 0x2F6054: open_input_file (in ffmpeg_g)
> ==816==by 0x2FC6AB: ffmpeg_parse_options (in ffmpeg_g)
> ==816==by 0x2E8A34: main (in ffmpeg_g)
> ==816==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
> 
> 
> [...]

Excuse me, we have run tests on our own business and have not found this 
problem, but it is a hidden risk,really hope you can tell me how to reproduce 
this problem. Thanks

> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> When the tyrant has disposed of foreign enemies by conquest or treaty, and
> there is nothing more to fear from them, then he is always stirring up
> some war or other, in order that the people may require a leader. -- Plato
> ___
> 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] avcodec/dolby_e: Add error recovery when parse_mantissas run out of bits

[Nicolas Gaullier]

>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 about once 
>every 2 hours.
>The truncation is at about 950 out of the 1024 values (never seen below 923 so 
>far).
>The current code raises a severe 'Read past end' error and all data is lost 
>resulting in
>20ms(@25fps) of silence for the affected channel.
>This patch introduces a tolerance: if 800 out of the 1024 mantissas have been 
>parsed, a simple warning is raised and the data is preserved.

I did not received any feedback yet (except trivial wrap-lines warning from 
patchwork).
I tried to contact fooba...@gmail.com > 2 weeks ago, but with no answer, I fear 
there is nobody behind the screen.
And no activity in https://github.com/foo86 for 5 years.

Maybe MAINTAINERS should be updated ?

There are a lot of things to come as DolbyED2 support (rawly already decodable 
with current code) and broader avformats support,
so this is not only about this single interoperability point issue.

Thank you for your support
Nicolas
___
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".