[FFmpeg-devel] [PATCH] Update sample upload instructions

2022-05-17 Thread Marvin Scholz
The previous instructions do not work, there is no FTP server
running at upload.ffmpeg.org
(which is an alias for streams.videolan.org)

Signed-off-by: Marvin Scholz 
---
 src/bugreports | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/src/bugreports b/src/bugreports
index ac9216c..f8c2581 100644
--- a/src/bugreports
+++ b/src/bugreports
@@ -144,16 +144,14 @@ info all-registers
 block_artifacts_after_seeking.mkv. We already have plenty of 
bug.rm
 and sample.avi.
 
-  Upload the sample to the FTP server. Note that our FTP server
-is write-only. Even though you cannot see the files that you upload,
-it will be there and the FFmpeg developers will have access.
+  Upload the sample with the VideoLAN file uploader.
 
-  Log into upload.ffmpeg.org with an anonymous FTP login.
-  cd -> incoming
-  Upload a brief text file describing the sample and what is wrong.
-This is important! If you leave out the text file, your
-sample will most likely be deleted without further examination.
-  Upload the sample.
+  Go to https://streams.videolan.org/upload/";>streams.videolan.org/upload/
+  Select the FFmpeg Project.
+  Fill in the FFmpeg version in the VLC version field.
+  Put the corresponding Trac ticket number in the GitLab ticket field, 
if a ticket exists.
+  Write a brief describing of the sample and what is wrong.
+  Upload the sample. Note that the file size limit is 1024M, file 
exceeding that are discarded.
 
 
   Email the ffmpeg mailing list and indicate the filename of the 
sample.
-- 
2.32.0 (Apple Git-132)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/3] lavc/aarch64: add hevc sao edge 8x8

2022-05-17 Thread J. Dekker
On 28 Apr 2022, at 21:50, Martin Storsjö wrote:

> [...]
> Compared with the previously applied (and reverted) patch, here, you 
> previously had "mov x17, #4". I guess that'd mean the function only ever 
> produced 8 output rows, while it now uses the real height parameter? Was this 
> change a no-op (height is always 8?) or was this another hidden bug in the 
> previous implementation?
>

Yes, this was another bug in a previous implementation which I've fixed in both 
of the newer versions.

>> [...]
>> +sqxtun  v6.8b, v20.8h
>> +sqxtun  v7.8b, v21.8h
>> +st1 {v6.8b}, [ x0], x2
>> +st1 {v7.8b}, [x16], x2
>> +subsx17, x17, #1
>
> This could be "subs w6, w6, #2" and you wouldn't need the lsr instruction at 
> all. And you could place the subs before the two st1 instructions to reduce 
> latency between them a little. (The same thing goes for moving subs further 
> away from the branch that uses its outcome in the previous patch too.) But as 
> this is just a reapply of a previously committed and reverted patch, I guess 
> it's fine this way too...

Will do before apply if you're fine with it, not too complex change.

> The patchset otherwise looks good to me, modulo the question about the 
> difference to the previous patchset above.

--
J. Dekker
___
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] checkasm: improve hevc_sao test

2022-05-17 Thread J. Dekker
The HEVC decoder can call these functions with smaller widths than the
functions themselves are designed to operate on so we should only check
the relevant output

Signed-off-by: J. Dekker 
---
 tests/checkasm/hevc_sao.c | 51 ---
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
index 6b750758e2..72cdb87dd1 100644
--- a/tests/checkasm/hevc_sao.c
+++ b/tests/checkasm/hevc_sao.c
@@ -78,20 +78,26 @@ static void check_sao_band(HEVCDSPContext h, int bit_depth)
 
 for (i = 0; i <= 4; i++) {
 int block_size = sao_size[i];
+int prev_size = i > 0 ? sao_size[i - 1] : 0;
 ptrdiff_t stride = PIXEL_STRIDE*SIZEOF_PIXEL;
 declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *dst, uint8_t *src, 
ptrdiff_t dst_stride, ptrdiff_t src_stride,
   int16_t *sao_offset_val, int sao_left_class, int 
width, int height);
 
-randomize_buffers(src0, src1, BUF_SIZE);
-randomize_buffers2(offset_val, OFFSET_LENGTH);
-memset(dst0, 0, BUF_SIZE);
-memset(dst1, 0, BUF_SIZE);
-
-if (check_func(h.sao_band_filter[i], "hevc_sao_band_%dx%d_%d", 
block_size, block_size, bit_depth)) {
-call_ref(dst0, src0, stride, stride, offset_val, left_class, 
block_size, block_size);
-call_new(dst1, src1, stride, stride, offset_val, left_class, 
block_size, block_size);
-if (memcmp(dst0, dst1, BUF_SIZE))
-fail();
+if (check_func(h.sao_band_filter[i], "hevc_sao_band_%d_%d", 
block_size, bit_depth)) {
+
+for (int w = prev_size + 4; w <= block_size; w += 4) {
+randomize_buffers(src0, src1, BUF_SIZE);
+randomize_buffers2(offset_val, OFFSET_LENGTH);
+memset(dst0, 0, BUF_SIZE);
+memset(dst1, 0, BUF_SIZE);
+
+call_ref(dst0, src0, stride, stride, offset_val, left_class, 
w, block_size);
+call_new(dst1, src1, stride, stride, offset_val, left_class, 
w, block_size);
+for (int j = 0; j < block_size; j++) {
+if (memcmp(dst0 + j*MAX_PB_SIZE*2, dst1 + j*MAX_PB_SIZE*2, 
w))
+fail();
+}
+}
 bench_new(dst1, src1, stride, stride, offset_val, left_class, 
block_size, block_size);
 }
 }
@@ -109,21 +115,26 @@ static void check_sao_edge(HEVCDSPContext h, int 
bit_depth)
 
 for (i = 0; i <= 4; i++) {
 int block_size = sao_size[i];
+int prev_size = i > 0 ? sao_size[i - 1] : 0;
 ptrdiff_t stride = PIXEL_STRIDE*SIZEOF_PIXEL;
 int offset = (AV_INPUT_BUFFER_PADDING_SIZE + 
PIXEL_STRIDE)*SIZEOF_PIXEL;
 declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *dst, uint8_t *src, 
ptrdiff_t stride_dst,
   int16_t *sao_offset_val, int eo, int width, int 
height);
 
-randomize_buffers(src0, src1, BUF_SIZE);
-randomize_buffers2(offset_val, OFFSET_LENGTH);
-memset(dst0, 0, BUF_SIZE);
-memset(dst1, 0, BUF_SIZE);
-
-if (check_func(h.sao_edge_filter[i], "hevc_sao_edge_%dx%d_%d", 
block_size, block_size, bit_depth)) {
-call_ref(dst0, src0 + offset, stride, offset_val, eo, block_size, 
block_size);
-call_new(dst1, src1 + offset, stride, offset_val, eo, block_size, 
block_size);
-if (memcmp(dst0, dst1, BUF_SIZE))
-fail();
+for (int w = prev_size + 4; w <= block_size; w += 4) {
+randomize_buffers(src0, src1, BUF_SIZE);
+randomize_buffers2(offset_val, OFFSET_LENGTH);
+memset(dst0, 0, BUF_SIZE);
+memset(dst1, 0, BUF_SIZE);
+
+if (check_func(h.sao_edge_filter[i], "hevc_sao_edge_%d_%d", 
block_size, bit_depth)) {
+call_ref(dst0, src0 + offset, stride, offset_val, eo, w, 
block_size);
+call_new(dst1, src1 + offset, stride, offset_val, eo, w, 
block_size);
+for (int j = 0; j < block_size; j++) {
+if (memcmp(dst0 + j*MAX_PB_SIZE*2, dst1 + j*MAX_PB_SIZE*2, 
w))
+fail();
+}
+}
 bench_new(dst1, src1 + offset, stride, offset_val, eo, block_size, 
block_size);
 }
 }
-- 
2.32.0 (Apple Git-132)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3 0/2] use av_fopen_utf8() instead of plain fopen()

2022-05-17 Thread Tobias Rapp

On 17/05/2022 02:39, ffmpegagent wrote:

Unify file access operations by replacing usages of direct calls to posix
fopen()


As the cover letter will be gone after commit I think it would be a good 
idea to add the reason for the change also in the commit messages directly.


Is this in preparation for the long filename support on Windows? Then 
maybe this could be mentioned, too.



v2: Remove changes to fftools for now
v3: Add some additional replacements

softworkz (2):
   avfilter: use av_fopen_utf8() instead of plain fopen()
   avfilter/dvdsubdec: use av_fopen_utf8() instead of plain fopen()


Patch #2 title should start with "avcodec/dvdsubdec: ..." I guess.



  libavcodec/dvdsubdec.c| 2 +-
  libavfilter/af_firequalizer.c | 2 +-
  libavfilter/vf_deshake.c  | 2 +-
  libavfilter/vf_psnr.c | 2 +-
  libavfilter/vf_signature.c| 4 ++--
  libavfilter/vf_ssim.c | 2 +-
  libavfilter/vf_vidstabdetect.c| 2 +-
  libavfilter/vf_vidstabtransform.c | 2 +-
  libavfilter/vf_vmafmotion.c   | 2 +-
  9 files changed, 10 insertions(+), 10 deletions(-)

[...]


Regards,
Tobias

___
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] AV1 VDPAU hwaccel Decode support

2022-05-17 Thread Manoj Bonda
Hi Philip, 

I am currently relying on using ffmpeg with nvcuvid to cross verify my vdpau 
patch 
I see the clips with me are matching in output for both VDPAU and NVCUVID/NVDEC.
Attached are the script I used to verify and its output.

Was unable to use AV1 VDPAU with MPV hence not able to repro the issue you are 
seeing. 
looking into it once resolved will check and resend the patch. Please bear with 
me.

Thanks,
ManojGupta.

> -Original Message-
> From: Philip Langdale 
> Sent: Tuesday, May 17, 2022 10:17 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: ManojGuptaBonda ;
> vd...@lists.freedesktop.org; Aaron Plattner ;
> Manoj Bonda ; Andy Ritger 
> Subject: Re: [FFmpeg-devel] [PATCH] AV1 VDPAU hwaccel Decode support
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, 16 May 2022 18:45:58 +0530
> ManojGuptaBonda  wrote:
> 
> > Support for VDPAU accelerated AV1 decoding was added with
> > libvdpau-1.5. Support for the same in ffmpeg is added with this patch.
> > Profiles related to VDPAU AV1 can be found in latest vdpau.h present
> > in libvdpau-1.5.
> >
> > Add AV1 VDPAU to list of hwaccels and supported formats Added file
> > vdpau_av1.c and Modified configure to add VDPAU AV1 support. Mapped
> > AV1 profiles to VDPAU AV1 profiles. Populated the codec specific
> > params that need to be passed to VDPAU.
> > ---
> >  Changelog   |   1 +
> >  configure   |   3 +
> >  libavcodec/Makefile |   1 +
> >  libavcodec/av1dec.c |  13 +-
> >  libavcodec/hwaccels.h   |   1 +
> >  libavcodec/vdpau_av1.c  | 370
> > 
> libavcodec/vdpau_internal.h |
> > 3 + libavcodec/version.h|   2 +-
> >  8 files changed, 392 insertions(+), 2 deletions(-)  create mode
> > 100644 libavcodec/vdpau_av1.c
> >
> 
> 
> 
> > diff --git a/libavcodec/vdpau_av1.c b/libavcodec/vdpau_av1.c new file
> > mode 100644 index 00..95c1e58cf7
> > --- /dev/null
> > +++ b/libavcodec/vdpau_av1.c
> > @@ -0,0 +1,370 @@
> > +/*
> > + * AV1 HW decode acceleration through VDPAU
> > + *
> > + * Copyright (c) 2022 Manoj Gupta Bonda
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > Foundation,
> > + * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> > + */
> > +
> > +#include 
> > +#include "libavutil/pixdesc.h"
> > +#include "avcodec.h"
> > +#include "internal.h"
> > +#include "av1dec.h"
> > +#include "hwconfig.h"
> > +#include "vdpau.h"
> > +#include "vdpau_internal.h"
> > +
> > +static int get_bit_depth_from_seq(const AV1RawSequenceHeader *seq)
> {
> > +if (seq->seq_profile == 2 && seq->color_config.high_bitdepth) {
> > +return seq->color_config.twelve_bit ? 12 : 10;
> > +} else if (seq->seq_profile <= 2 &&
> > seq->color_config.high_bitdepth) {
> > +return 10;
> > +} else {
> > +return 8;
> > +}
> > +}
> > +
> > +static int vdpau_av1_start_frame(AVCodecContext *avctx,
> > +  const uint8_t *buffer, uint32_t
> > size) +{
> > +AV1DecContext *s = avctx->priv_data;
> > +const AV1RawSequenceHeader *seq = s->raw_seq;
> > +const AV1RawFrameHeader *frame_header = s->raw_frame_header;
> > +const AV1RawFilmGrainParams *film_grain =
> > &s->cur_frame.film_grain; +
> > +struct vdpau_picture_context *pic_ctx =
> > s->cur_frame.hwaccel_picture_private;
> > +int i,j;
> > +
> > +unsigned char remap_lr_type[4] = { AV1_RESTORE_NONE,
> > AV1_RESTORE_SWITCHABLE, AV1_RESTORE_WIENER,
> AV1_RESTORE_SGRPROJ }; +
> > +
> > +VdpPictureInfoAV1 *info = &pic_ctx->info.av1;
> > +const AVPixFmtDescriptor *pixdesc =
> > av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > +if (!pixdesc) {
> > +return AV_PIX_FMT_NONE;
> > +}
> > +
> > +info->width = avctx->width;
> > +info->height = avctx->height;
> > +
> > +
> > +info->frame_offset = frame_header->order_hint;
> > +
> > +/* Sequence Header */
> > +info->profile= seq->seq_profile;
> > +info->use_128x128_superblock = seq->use_128x128_superblock;
> > +info->subsampling_x  =
> > seq->color_config.subsampling_x;
> > +info->subsampling_y  =
> > seq->color_config.subsampling_y;

Re: [FFmpeg-devel] [PATCH] ffmpeg: set user-set rotation for encoded streams too

2022-05-17 Thread Jan Ekström
On Sun, May 15, 2022 at 3:21 PM Jan Ekström  wrote:
>
> On Sun, May 15, 2022 at 2:58 PM Gyan Doshi  wrote:
> >
> >
> >
> > On 2022-05-15 04:29 pm, Jan Ekström wrote:
> > > On Thu, May 12, 2022 at 11:19 AM Anton Khirnov  wrote:
> > >> Quoting Gyan Doshi (2022-05-12 09:01:31)
> > >>> A substitute option for metadata rotate would accept a single rotation
> > >>> value.
> > >>> If adding an option for matrix, we should allow flips too.
> > >> I see no reason not to have both. You can have a simple option for just
> > >> the rotation and an advanced option for specifying full matrix.
> > >>
> > > FYI I had thought about arguments-to-side data earlier, and as I saw
> > > this thread I decided to make a proof-of-concept that has one layer
> > > which constructs an AVBufferRef of the side data itself based on an
> > > AVDictionary (constructor, basically), and then another which then
> > > goes over type-arguments sort of dictionary and attaches things (to an
> > > AVFrame in this case). AVPacket and AVFrame side data is slightly
> > > different, so I guess you'd have to split one layer which generates an
> > > AVBufferRef, and then that'd be utilized (discarded or not) by the
> > > utilizing function.
> > >
> > > I do wonder if AVOptions wouldn't be better for something like this,
> > > but at least it lets you play around with the idea. My initial API
> > > user ended up being the setparams filter.
> > >
> > > Link to PoC branch:
> > > https://github.com/jeeb/ffmpeg/commits/arguments_to_side_data
> > >
> > > Usage example:
> > > ffmpeg -v verbose -i INPUT -map 0:v:0 -vf
> > > setparams=side_data=displaymatrix=angle=34.34,showinfo -vframes 1 -f
> > > null -
> >
> > The metadata hack uses avutil/display API to set the matrix and then
> > attach it to the *stream* as side data  A filter will force encoding.
> > Since this is usability/display info for the consumer , it should remain
> > available for streamcopy.
>
> Yes, that is why I noted that there probably needs to be a separation
> of APIs between the AVBufferRef and the "final" one. For re-encoding a
> video filter would lead to the first AVFrame having it, and then that
> could be utilized in the encoder initialization - just like my changes
> pushing the video encoding later enabled color space information to be
> passed on. For stream copy, it should be set either to the AVPacket(s)
> or AVStream, yes. Anton talked about a bit stream filter but I have
> not looked into that side of things.
>
> This was just a proof-of-concept so people can see how string
> arguments to side data might look, since IMHO we are badly lacking
> such an interface (while the C APIs might be OK, we are clearly
> lacking stuff to do string based object generation, which is more or
> less required for CLI etc usage).

What I missed to note earlier, as we still don't have things settled
completely regarding arguments/AVOptions for constructors for side
data (not to mention the fun bits of the side data related structures
being slightly different between packets/streams and frames), it
completely makes sense to have options for specific side data to be
added to streams (or otherwise) for now.

I pushed an initial PoC of such a thing to
https://github.com/jeeb/ffmpeg/commits/ffmpeg_c_display_matrix
You can override the display matrix on both input side (which would
lead to autorotate logic etc working with it - although the side data
indeed does not get applied to the AVFrames themselves looking at the
showinfo filter's output), as well as on the output side, which only
affects the output stream specifically.

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 v3 0/2] use av_fopen_utf8() instead of plain fopen()

2022-05-17 Thread Soft Works


> -Original Message-
> From: Tobias Rapp 
> Sent: Tuesday, May 17, 2022 1:56 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>; ffmpegagent 
> Cc: Martin Storsjö ; softworkz
> 
> Subject: Re: [FFmpeg-devel] [PATCH v3 0/2] use av_fopen_utf8() instead
> of plain fopen()
> 
> On 17/05/2022 02:39, ffmpegagent wrote:
> > Unify file access operations by replacing usages of direct calls to
> posix
> > fopen()
> 
> As the cover letter will be gone after commit I think it would be a
> good
> idea to add the reason for the change also in the commit messages
> directly.
> 
> Is this in preparation for the long filename support on Windows? Then
> maybe this could be mentioned, too.
> 
> > v2: Remove changes to fftools for now
> > v3: Add some additional replacements
> >
> > softworkz (2):
> >avfilter: use av_fopen_utf8() instead of plain fopen()
> >avfilter/dvdsubdec: use av_fopen_utf8() instead of plain fopen()
> 
> Patch #2 title should start with "avcodec/dvdsubdec: ..." I guess.

Yes, yes and yes. ;-)

Thanks a lot for reviewing. Update will follow.

Kind regards,
softworkz
___
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 v4 0/2] use av_fopen_utf8() instead of plain fopen()

2022-05-17 Thread ffmpegagent
Unify file access operations by replacing usages of direct calls to posix
fopen()

v2: Remove changes to fftools for now
v3: Add some additional replacements
v4: Fix and improve commit messages

softworkz (2):
  avfilter: use av_fopen_utf8() instead of plain fopen()
  avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()

 libavcodec/dvdsubdec.c| 2 +-
 libavfilter/af_firequalizer.c | 2 +-
 libavfilter/vf_deshake.c  | 2 +-
 libavfilter/vf_psnr.c | 2 +-
 libavfilter/vf_signature.c| 4 ++--
 libavfilter/vf_ssim.c | 2 +-
 libavfilter/vf_vidstabdetect.c| 2 +-
 libavfilter/vf_vidstabtransform.c | 2 +-
 libavfilter/vf_vmafmotion.c   | 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)


base-commit: e3580f60775c897c3b13b178c57ab191ecc4a031
Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-26%2Fsoftworkz%2Fsubmit_replace_fopen-v4
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-26/softworkz/submit_replace_fopen-v4
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/26

Range-diff vs v3:

 1:  d81855ba42 ! 1:  7c455d7fa0 avfilter: use av_fopen_utf8() instead of plain 
fopen()
 @@ Metadata
   ## Commit message ##
  avfilter: use av_fopen_utf8() instead of plain fopen()
  
 +Unify file access operations by replacing usages of direct calls
 +to posix fopen() to prepare for long filename support on Windows.
 +
  Signed-off-by: softworkz 
  
   ## libavfilter/af_firequalizer.c ##
 2:  1be02d9e04 ! 2:  68192b1a1e avfilter/dvdsubdec: use av_fopen_utf8() 
instead of plain fopen()
 @@ Metadata
  Author: softworkz 
  
   ## Commit message ##
 -avfilter/dvdsubdec: use av_fopen_utf8() instead of plain fopen()
 +avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()
 +
 +Unify file access operations by replacing usages of direct calls
 +to posix fopen() to prepare for long filename support on Windows.
  
  Signed-off-by: softworkz 
  

-- 
ffmpeg-codebot
___
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 v4 1/2] avfilter: use av_fopen_utf8() instead of plain fopen()

2022-05-17 Thread softworkz
From: softworkz 

Unify file access operations by replacing usages of direct calls
to posix fopen() to prepare for long filename support on Windows.

Signed-off-by: softworkz 
---
 libavfilter/af_firequalizer.c | 2 +-
 libavfilter/vf_deshake.c  | 2 +-
 libavfilter/vf_psnr.c | 2 +-
 libavfilter/vf_signature.c| 4 ++--
 libavfilter/vf_ssim.c | 2 +-
 libavfilter/vf_vidstabdetect.c| 2 +-
 libavfilter/vf_vidstabtransform.c | 2 +-
 libavfilter/vf_vmafmotion.c   | 2 +-
 8 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavfilter/af_firequalizer.c b/libavfilter/af_firequalizer.c
index c19a2fe122..e1497dcef0 100644
--- a/libavfilter/af_firequalizer.c
+++ b/libavfilter/af_firequalizer.c
@@ -604,7 +604,7 @@ static int generate_kernel(AVFilterContext *ctx, const char 
*gain, const char *g
 if (ret < 0)
 return ret;
 
-if (s->dumpfile && (!s->dump_buf || !s->analysis_rdft || !(dump_fp = 
fopen(s->dumpfile, "w"
+if (s->dumpfile && (!s->dump_buf || !s->analysis_rdft || !(dump_fp = 
av_fopen_utf8(s->dumpfile, "w"
 av_log(ctx, AV_LOG_WARNING, "dumping failed.\n");
 
 vars[VAR_CHS] = inlink->ch_layout.nb_channels;
diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c
index 4f28467bb2..dea69e11cd 100644
--- a/libavfilter/vf_deshake.c
+++ b/libavfilter/vf_deshake.c
@@ -353,7 +353,7 @@ static av_cold int init(AVFilterContext *ctx)
 }
 
 if (deshake->filename)
-deshake->fp = fopen(deshake->filename, "w");
+deshake->fp = av_fopen_utf8(deshake->filename, "w");
 if (deshake->fp)
 fwrite("Ori x, Avg x, Fin x, Ori y, Avg y, Fin y, Ori angle, Avg 
angle, Fin angle, Ori zoom, Avg zoom, Fin zoom\n", 1, 104, deshake->fp);
 
diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index 19852eaa69..09c2a5164a 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -280,7 +280,7 @@ static av_cold int init(AVFilterContext *ctx)
 if (!strcmp(s->stats_file_str, "-")) {
 s->stats_file = stdout;
 } else {
-s->stats_file = fopen(s->stats_file_str, "w");
+s->stats_file = av_fopen_utf8(s->stats_file_str, "w");
 if (!s->stats_file) {
 int err = AVERROR(errno);
 char buf[128];
diff --git a/libavfilter/vf_signature.c b/libavfilter/vf_signature.c
index 4ca57ebf1d..904123fd4e 100644
--- a/libavfilter/vf_signature.c
+++ b/libavfilter/vf_signature.c
@@ -386,7 +386,7 @@ static int xml_export(AVFilterContext *ctx, StreamContext 
*sc, const char* filen
 FILE* f;
 unsigned int pot3[5] = { 3*3*3*3, 3*3*3, 3*3, 3, 1 };
 
-f = fopen(filename, "w");
+f = av_fopen_utf8(filename, "w");
 if (!f) {
 int err = AVERROR(EINVAL);
 char buf[128];
@@ -500,7 +500,7 @@ static int binary_export(AVFilterContext *ctx, 
StreamContext *sc, const char* fi
 if (!buffer)
 return AVERROR(ENOMEM);
 
-f = fopen(filename, "wb");
+f = av_fopen_utf8(filename, "wb");
 if (!f) {
 int err = AVERROR(EINVAL);
 char buf[128];
diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index 32f313817d..4a82cbec06 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -404,7 +404,7 @@ static av_cold int init(AVFilterContext *ctx)
 if (!strcmp(s->stats_file_str, "-")) {
 s->stats_file = stdout;
 } else {
-s->stats_file = fopen(s->stats_file_str, "w");
+s->stats_file = av_fopen_utf8(s->stats_file_str, "w");
 if (!s->stats_file) {
 int err = AVERROR(errno);
 char buf[128];
diff --git a/libavfilter/vf_vidstabdetect.c b/libavfilter/vf_vidstabdetect.c
index 267a62ea9b..4acae5a3ea 100644
--- a/libavfilter/vf_vidstabdetect.c
+++ b/libavfilter/vf_vidstabdetect.c
@@ -126,7 +126,7 @@ static int config_input(AVFilterLink *inlink)
 av_log(ctx, AV_LOG_INFO, "  show = %d\n", s->conf.show);
 av_log(ctx, AV_LOG_INFO, "result = %s\n", s->result);
 
-s->f = fopen(s->result, "w");
+s->f = av_fopen_utf8(s->result, "w");
 if (s->f == NULL) {
 av_log(ctx, AV_LOG_ERROR, "cannot open transform file %s\n", 
s->result);
 return AVERROR(EINVAL);
diff --git a/libavfilter/vf_vidstabtransform.c 
b/libavfilter/vf_vidstabtransform.c
index 4619e9b256..17214f039f 100644
--- a/libavfilter/vf_vidstabtransform.c
+++ b/libavfilter/vf_vidstabtransform.c
@@ -191,7 +191,7 @@ static int config_input(AVFilterLink *inlink)
 av_log(ctx, AV_LOG_INFO, "zoomspeed = %g\n", tc->conf.zoomSpeed);
 av_log(ctx, AV_LOG_INFO, "interpol  = %s\n", 
getInterpolationTypeName(tc->conf.interpolType));
 
-f = fopen(tc->input, "r");
+f = av_fopen_utf8(tc->input, "r");
 if (!f) {
 int ret = AVERROR(errno);
 av_log(ctx, AV_LOG_ERROR, "cannot open input file %s\n", tc->input);
diff --git a/libavfilter/vf_vmafmotion.c b/libavfil

[FFmpeg-devel] [PATCH v4 2/2] avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()

2022-05-17 Thread softworkz
From: softworkz 

Unify file access operations by replacing usages of direct calls
to posix fopen() to prepare for long filename support on Windows.

Signed-off-by: softworkz 
---
 libavcodec/dvdsubdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 30fe4d41de..19b78b3eb1 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -617,7 +617,7 @@ static int parse_ifo_palette(DVDSubContext *ctx, char *p)
 const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
 
 ctx->has_palette = 0;
-if ((ifo = fopen(p, "r")) == NULL) {
+if ((ifo = av_fopen_utf8(p, "r")) == NULL) {
 av_log(ctx, AV_LOG_WARNING, "Unable to open IFO file \"%s\": %s\n", p, 
av_err2str(AVERROR(errno)));
 return AVERROR_EOF;
 }
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/3] avcodec/mpeg4videodec: Replace always true check by assert

2022-05-17 Thread Michael Niedermayer
On Mon, May 16, 2022 at 01:05:28PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Maybe helps coverity
> > Helps: CID1433771
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/mpeg4videodec.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> > index e2bde73639..715cb606c9 100644
> > --- a/libavcodec/mpeg4videodec.c
> > +++ b/libavcodec/mpeg4videodec.c
> > @@ -1981,7 +1981,8 @@ static int mpeg4_decode_studio_block(MpegEncContext 
> > *s, int32_t block[64], int n
> >  return AVERROR_INVALIDDATA;
> >  j = scantable[idx++];
> >  block[j] = get_xbits(&s->gb, additional_code_len);
> > -} else if (group == 21) {
> > +} else {
> > +av_assert2(group == 21);
> >  /* Escape */
> >  if (idx > 63)
> >  return AVERROR_INVALIDDATA;
> 
> This also reminds me of an old attempt of mine to add an AV_UNREACHABLE
> macro for such scenarios:
> https://github.com/mkver/FFmpeg/commits/unreachable. There are two
> reasons why I never sent it to the ML:

> a) It uses ASSERT_LEVEL (i.e. with a high ASSERT_LEVEL it degenarates
> into an actual assert). But this is only defined internally, so useless
> to an API user. Therefore I wonder whether this should be in a public
> header (the same issue exists for av_assert1 and av_assert2).

for av_assertX to be usefull to a user app, the developer of that app
needs to be able to set ASSERT_LEVEL. It would be less useful if it
was fixed to the value ffmpeg used in its built

The developer should be able to set ASSERT_LEVEL before the include
or with -D
but some other way could be added too


> b) Both Clang and MSVC have something more, namely a
> __builtin_assume(cond)  resp. __assume(cond). I was unsure whether this
> should not be added, too. It could be translated to "if (!(cond))
> __builtin_unreachable()" to GCC, but would be more natural in general.
> (Of course, cond must not have any side effects.)


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban


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 v2] avutil/csp: create public API for colorspace structs

2022-05-17 Thread Leo Izen
This commit moves some of the functionality from avfilter/colorspace
into avutil/csp and exposes it as a public API so it can be used by
libavcodec and/or libavformat.
---
 libavfilter/colorspace.c|  94 +-
 libavfilter/colorspace.h|  31 ++
 libavfilter/fflcms2.c   |  11 ++--
 libavfilter/fflcms2.h   |   4 +-
 libavfilter/vf_colorspace.c |  19 +++---
 libavfilter/vf_iccdetect.c  |   5 +-
 libavfilter/vf_tonemap.c|  15 +
 libavutil/Makefile  |   2 +
 libavutil/csp.c | 111 
 libavutil/csp.h |  49 
 libavutil/version.h |   4 +-
 11 files changed, 195 insertions(+), 150 deletions(-)
 create mode 100644 libavutil/csp.c
 create mode 100644 libavutil/csp.h

diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
index 8d7b882375..d6de313a5c 100644
--- a/libavfilter/colorspace.c
+++ b/libavfilter/colorspace.c
@@ -65,8 +65,8 @@ void ff_matrix_mul_3x3(double dst[3][3],
 /*
  * see e.g. http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
  */
-void ff_fill_rgb2xyz_table(const struct PrimaryCoefficients *coeffs,
-   const struct WhitepointCoefficients *wp,
+void ff_fill_rgb2xyz_table(const AVPrimaryCoefficients *coeffs,
+   const AVWhitepointCoefficients *wp,
double rgb2xyz[3][3])
 {
 double i[3][3], sr, sg, sb, zw;
@@ -107,95 +107,7 @@ static const double gbr_matrix[3][3] =
 { 0.5, -0.5, 0   },
 };
 
-/*
- * All constants explained in e.g. 
https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html
- * The older ones (bt470bg/m) are also explained in their respective ITU docs
- * (e.g. 
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-5-199802-S!!PDF-E.pdf)
- * whereas the newer ones can typically be copied directly from wikipedia :)
- */
-static const struct LumaCoefficients luma_coefficients[AVCOL_SPC_NB] = {
-[AVCOL_SPC_FCC]= { 0.30,   0.59,   0.11   },
-[AVCOL_SPC_BT470BG]= { 0.299,  0.587,  0.114  },
-[AVCOL_SPC_SMPTE170M]  = { 0.299,  0.587,  0.114  },
-[AVCOL_SPC_BT709]  = { 0.2126, 0.7152, 0.0722 },
-[AVCOL_SPC_SMPTE240M]  = { 0.212,  0.701,  0.087  },
-[AVCOL_SPC_YCOCG]  = { 0.25,   0.5,0.25   },
-[AVCOL_SPC_RGB]= { 1,  1,  1  },
-[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
-[AVCOL_SPC_BT2020_CL]  = { 0.2627, 0.6780, 0.0593 },
-};
-
-const struct LumaCoefficients *ff_get_luma_coefficients(enum AVColorSpace csp)
-{
-const struct LumaCoefficients *coeffs;
-
-if (csp >= AVCOL_SPC_NB)
-return NULL;
-coeffs = &luma_coefficients[csp];
-if (!coeffs->cr)
-return NULL;
-
-return coeffs;
-}
-
-#define WP_D65 { 0.3127, 0.3290 }
-#define WP_C   { 0.3100, 0.3160 }
-#define WP_DCI { 0.3140, 0.3510 }
-#define WP_E   { 1/3.0f, 1/3.0f }
-
-static const struct ColorPrimaries color_primaries[AVCOL_PRI_NB] = {
-[AVCOL_PRI_BT709] = { WP_D65, { 0.640, 0.330, 0.300, 0.600, 0.150, 
0.060 } },
-[AVCOL_PRI_BT470M]= { WP_C,   { 0.670, 0.330, 0.210, 0.710, 0.140, 
0.080 } },
-[AVCOL_PRI_BT470BG]   = { WP_D65, { 0.640, 0.330, 0.290, 0.600, 0.150, 
0.060 } },
-[AVCOL_PRI_SMPTE170M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
0.070 } },
-[AVCOL_PRI_SMPTE240M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
0.070 } },
-[AVCOL_PRI_SMPTE428]  = { WP_E,   { 0.735, 0.265, 0.274, 0.718, 0.167, 
0.009 } },
-[AVCOL_PRI_SMPTE431]  = { WP_DCI, { 0.680, 0.320, 0.265, 0.690, 0.150, 
0.060 } },
-[AVCOL_PRI_SMPTE432]  = { WP_D65, { 0.680, 0.320, 0.265, 0.690, 0.150, 
0.060 } },
-[AVCOL_PRI_FILM]  = { WP_C,   { 0.681, 0.319, 0.243, 0.692, 0.145, 
0.049 } },
-[AVCOL_PRI_BT2020]= { WP_D65, { 0.708, 0.292, 0.170, 0.797, 0.131, 
0.046 } },
-[AVCOL_PRI_JEDEC_P22] = { WP_D65, { 0.630, 0.340, 0.295, 0.605, 0.155, 
0.077 } },
-};
-
-const struct ColorPrimaries *ff_get_color_primaries(enum AVColorPrimaries prm)
-{
-const struct ColorPrimaries *p;
-
-if (prm >= AVCOL_PRI_NB)
-return NULL;
-p = &color_primaries[prm];
-if (!p->prim.xr)
-return NULL;
-
-return p;
-}
-
-enum AVColorPrimaries ff_detect_color_primaries(const struct ColorPrimaries 
*prm)
-{
-double delta;
-
-for (enum AVColorPrimaries p = 0; p < AVCOL_PRI_NB; p++) {
-const struct ColorPrimaries *ref = &color_primaries[p];
-if (!ref->prim.xr)
-continue;
-
-delta = fabs(prm->prim.xr - ref->prim.xr) +
-fabs(prm->prim.yr - ref->prim.yr) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->wp.xw - ref->wp.xw) +
-fabs(prm->wp.yw - ref->wp.yw);
-
-if (delta < 0.

Re: [FFmpeg-devel] [PATCH v2] avutil/csp: create public API for colorspace structs

2022-05-17 Thread Andreas Rheinhardt
Leo Izen:
> This commit moves some of the functionality from avfilter/colorspace
> into avutil/csp and exposes it as a public API so it can be used by
> libavcodec and/or libavformat.
> ---
>  libavfilter/colorspace.c|  94 +-
>  libavfilter/colorspace.h|  31 ++
>  libavfilter/fflcms2.c   |  11 ++--
>  libavfilter/fflcms2.h   |   4 +-
>  libavfilter/vf_colorspace.c |  19 +++---
>  libavfilter/vf_iccdetect.c  |   5 +-
>  libavfilter/vf_tonemap.c|  15 +
>  libavutil/Makefile  |   2 +
>  libavutil/csp.c | 111 
>  libavutil/csp.h |  49 
>  libavutil/version.h |   4 +-
>  11 files changed, 195 insertions(+), 150 deletions(-)
>  create mode 100644 libavutil/csp.c
>  create mode 100644 libavutil/csp.h
> 
> diff --git a/libavutil/csp.c b/libavutil/csp.c
> new file mode 100644
> index 00..deecefbffc
> --- /dev/null
> +++ b/libavutil/csp.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2016 Ronald S. Bultje 
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "csp.h"
> +#include "frame.h"

?

> +#include "mastering_display_metadata.h"

?

> +#include "pixfmt.h"
> +
> +/*
> + * All constants explained in e.g. 
> https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html
> + * The older ones (bt470bg/m) are also explained in their respective ITU docs
> + * (e.g. 
> https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-5-199802-S!!PDF-E.pdf)
> + * whereas the newer ones can typically be copied directly from wikipedia :)
> + */
> +static const struct AVLumaCoefficients luma_coefficients[AVCOL_SPC_NB] = {
> +[AVCOL_SPC_FCC]= { 0.30,   0.59,   0.11   },
> +[AVCOL_SPC_BT470BG]= { 0.299,  0.587,  0.114  },
> +[AVCOL_SPC_SMPTE170M]  = { 0.299,  0.587,  0.114  },
> +[AVCOL_SPC_BT709]  = { 0.2126, 0.7152, 0.0722 },
> +[AVCOL_SPC_SMPTE240M]  = { 0.212,  0.701,  0.087  },
> +[AVCOL_SPC_YCOCG]  = { 0.25,   0.5,0.25   },
> +[AVCOL_SPC_RGB]= { 1,  1,  1  },
> +[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
> +[AVCOL_SPC_BT2020_CL]  = { 0.2627, 0.6780, 0.0593 },
> +};
> +
> +const struct AVLumaCoefficients *av_get_luma_coefficients(enum AVColorSpace 
> csp)
> +{
> +const AVLumaCoefficients *coeffs;
> +
> +if (csp >= AVCOL_SPC_NB)
> +return NULL;
> +coeffs = &luma_coefficients[csp];
> +if (!coeffs->cr)
> +return NULL;
> +
> +return coeffs;
> +}
> +
> +#define WP_D65 { 0.3127, 0.3290 }
> +#define WP_C   { 0.3100, 0.3160 }
> +#define WP_DCI { 0.3140, 0.3510 }
> +#define WP_E   { 1/3.0f, 1/3.0f }
> +
> +static const AVColorPrimariesDesc color_primaries[AVCOL_PRI_NB] = {
> +[AVCOL_PRI_BT709] = { WP_D65, { 0.640, 0.330, 0.300, 0.600, 0.150, 
> 0.060 } },
> +[AVCOL_PRI_BT470M]= { WP_C,   { 0.670, 0.330, 0.210, 0.710, 0.140, 
> 0.080 } },
> +[AVCOL_PRI_BT470BG]   = { WP_D65, { 0.640, 0.330, 0.290, 0.600, 0.150, 
> 0.060 } },
> +[AVCOL_PRI_SMPTE170M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
> 0.070 } },
> +[AVCOL_PRI_SMPTE240M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
> 0.070 } },
> +[AVCOL_PRI_SMPTE428]  = { WP_E,   { 0.735, 0.265, 0.274, 0.718, 0.167, 
> 0.009 } },
> +[AVCOL_PRI_SMPTE431]  = { WP_DCI, { 0.680, 0.320, 0.265, 0.690, 0.150, 
> 0.060 } },
> +[AVCOL_PRI_SMPTE432]  = { WP_D65, { 0.680, 0.320, 0.265, 0.690, 0.150, 
> 0.060 } },
> +[AVCOL_PRI_FILM]  = { WP_C,   { 0.681, 0.319, 0.243, 0.692, 0.145, 
> 0.049 } },
> +[AVCOL_PRI_BT2020]= { WP_D65, { 0.708, 0.292, 0.170, 0.797, 0.131, 
> 0.046 } },
> +[AVCOL_PRI_JEDEC_P22] = { WP_D65, { 0.630, 0.340, 0.295, 0.605, 0.155, 
> 0.077 } },
> +};
> +
> +const AVColorPrimariesDesc *av_get_color_primaries(enum AVColorPrimaries prm)
> +{
> +const AVColorPrimariesDesc *p;
> +
> +if (prm >= AVCOL_PRI_NB)
> +return NULL;
> +p = &color_primaries[prm];
> +if (!p->prim.xr)
> +return NULL;
> +
> +return p;
> +}
> +
> +enum AVColorPrimaries av_detect_color_primaries(const AVColorPrimariesDesc 
> *prm)
> +{
> +double delta;
> +
> +for (enum AVColorP

Re: [FFmpeg-devel] [PATCH v2] avutil/csp: create public API for colorspace structs

2022-05-17 Thread Leo Izen

On 5/17/22 10:09, Andreas Rheinhardt wrote:

Leo Izen:

+#include "csp.h"
+#include "frame.h"


?


+#include "mastering_display_metadata.h"


?


+#include "libavutil/frame.h"


Once again: ?

This includes were all in libavfilter/colorspace, I missed removing them 
when I moved it over. I'll remove them.


- 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 v2 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

2022-05-17 Thread nil-admirari
> stat wasn't already defined as win32_stat.
> win32_stat was already defined but not mapped. That's what my change
> does. 

There are two defines in os_support.h:

#  ifdef stat
#   undef stat
#  endif
#  define stat _stati64

and

DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)

which defines win32_stat (not stat). This function takes struct stat*, which 
due to previous define
expands into struct _stati64*.

_stati64 and _wstati64 both take struct _stati64*, which is named identically 
to the first function.
struct _stati64 expands into different structs depending on the value of 
_USE_32BIT_TIME_T,
which your explicit structure definition does not capture, see:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=msvc-170.
If someone defines_USE_32BIT_TIME_T, your code will fail to compile.

C allows functions and structs to have identical names, preprocessor does not;
therefore win32_stat must be used explicitly where stat is required as in 
file.c:160

struct stat st; // expands into struct _stati64 on Windows.
#   ifndef _WIN32
ret = stat(filename, &st);
#   else
ret = win32_stat(filename, &st);
#   endif

However, no everyone follows: img2dec.c:504 and ipfsgateway.c:104 use plain 
stat.

if (stat(filename, &img_stat)) {
stat_ret = stat(ipfs_full_data_folder, &st);

In these files, on Windows, both the struct and the function call expand into 
_stati64,
and this time the function call bypasses the UTF-8 to wchar conversion.

Apparently yet another macro is necessary:

#ifdef _WIN32
#define ff_stat win32_stat
#else
#define ff_stat stat
#endif



___
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 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

2022-05-17 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of nil-
> admir...@mailo.com
> Sent: Tuesday, May 17, 2022 5:07 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> file_open: Support long file names on Windows
> 
> > stat wasn't already defined as win32_stat.
> > win32_stat was already defined but not mapped. That's what my change
> > does.
> 
> There are two defines in os_support.h:
> 
> #  ifdef stat
> #   undef stat
> #  endif
> #  define stat _stati64
> 
> and
> 
> DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
> 
> which defines win32_stat (not stat). This function takes struct stat*,
> which due to previous define
> expands into struct _stati64*.
> 
> _stati64 and _wstati64 both take struct _stati64*, which is named
> identically to the first function.
> struct _stati64 expands into different structs depending on the value
> of _USE_32BIT_TIME_T,
> which your explicit structure definition does not capture, see:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-
> functions?view=msvc-170.
> If someone defines_USE_32BIT_TIME_T, your code will fail to compile.

Yes, that's true. But there are hundreds of other things someone could
define which makes compilation fail. 
We don't need to accommodate for every single possibility, and it's not
that _USE_32BIT_TIME_T would be required or the default for 32bit 
compilation.


> C allows functions and structs to have identical names, preprocessor
> does not;
> therefore win32_stat must be used explicitly where stat is required as
> in file.c:160

Except when you define a compatible struct with the same name as the
function - like I did.


> struct stat st; // expands into struct _stati64 on Windows.
> #   ifndef _WIN32
> ret = stat(filename, &st);
> #   else
> ret = win32_stat(filename, &st);
> #   endif

This could be removed after the patch.


> However, no everyone follows: img2dec.c:504 and ipfsgateway.c:104 use
> plain stat.
> 
> if (stat(filename, &img_stat)) {
> stat_ret = stat(ipfs_full_data_folder, &st);
> 
> In these files, on Windows, both the struct and the function call
> expand into _stati64,
> and this time the function call bypasses the UTF-8 to wchar
> conversion.
> 
> Apparently yet another macro is necessary:
> 
> #ifdef _WIN32
> #define ff_stat win32_stat
> #else
> #define ff_stat stat
> #endif

Probably you didn't spot it. It's already there:

#  define stat win32_stat

Kind regards,
softworkz

___
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 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

2022-05-17 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Soft
> Works
> Sent: Tuesday, May 17, 2022 5:28 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> file_open: Support long file names on Windows
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> nil-
> > admir...@mailo.com
> > Sent: Tuesday, May 17, 2022 5:07 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> > file_open: Support long file names on Windows
> >
> > > stat wasn't already defined as win32_stat.
> > > win32_stat was already defined but not mapped. That's what my
> change
> > > does.
> >
> > There are two defines in os_support.h:
> >
> > #  ifdef stat
> > #   undef stat
> > #  endif
> > #  define stat _stati64
> >
> > and
> >
> > DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
> >
> > which defines win32_stat (not stat). This function takes struct
> stat*,
> > which due to previous define
> > expands into struct _stati64*.
> >
> > _stati64 and _wstati64 both take struct _stati64*, which is named
> > identically to the first function.
> > struct _stati64 expands into different structs depending on the
> value
> > of _USE_32BIT_TIME_T,
> > which your explicit structure definition does not capture, see:
> > https://docs.microsoft.com/en-us/cpp/c-runtime-
> library/reference/stat-
> > functions?view=msvc-170.
> > If someone defines_USE_32BIT_TIME_T, your code will fail to compile.
> 
> Yes, that's true. But there are hundreds of other things someone could
> define which makes compilation fail.
> We don't need to accommodate for every single possibility, and it's
> not
> that _USE_32BIT_TIME_T would be required or the default for 32bit
> compilation.
> 
> 
> > C allows functions and structs to have identical names, preprocessor
> > does not;
> > therefore win32_stat must be used explicitly where stat is required
> as
> > in file.c:160
> 
> Except when you define a compatible struct with the same name as the
> function - like I did.

I don't want to say that I'd consider this to be a great solution.
But the problem is that the function and struct names are identical
and when we want to re-define/map the function, we also need to
provide a struct of that name because the macro-replacement can't
work selectively.

Maybe there is some cool trick to handle this, yet I haven't had
a better idea so far.

Thanks,
softworkz


___
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 v3] avutil/csp: create public API for colorspace structs

2022-05-17 Thread Leo Izen
This commit moves some of the functionality from avfilter/colorspace
into avutil/csp and exposes it as a public API so it can be used by
libavcodec and/or libavformat.
---
 libavfilter/colorspace.c|  94 +-
 libavfilter/colorspace.h|  31 ++
 libavfilter/fflcms2.c   |  11 ++--
 libavfilter/fflcms2.h   |   4 +-
 libavfilter/vf_colorspace.c |  19 +++---
 libavfilter/vf_iccdetect.c  |   5 +-
 libavfilter/vf_tonemap.c|  15 +
 libavutil/Makefile  |   2 +
 libavutil/csp.c | 112 
 libavutil/csp.h |  48 
 libavutil/version.h |   4 +-
 11 files changed, 195 insertions(+), 150 deletions(-)
 create mode 100644 libavutil/csp.c
 create mode 100644 libavutil/csp.h

diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
index 8d7b882375..d6de313a5c 100644
--- a/libavfilter/colorspace.c
+++ b/libavfilter/colorspace.c
@@ -65,8 +65,8 @@ void ff_matrix_mul_3x3(double dst[3][3],
 /*
  * see e.g. http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
  */
-void ff_fill_rgb2xyz_table(const struct PrimaryCoefficients *coeffs,
-   const struct WhitepointCoefficients *wp,
+void ff_fill_rgb2xyz_table(const AVPrimaryCoefficients *coeffs,
+   const AVWhitepointCoefficients *wp,
double rgb2xyz[3][3])
 {
 double i[3][3], sr, sg, sb, zw;
@@ -107,95 +107,7 @@ static const double gbr_matrix[3][3] =
 { 0.5, -0.5, 0   },
 };
 
-/*
- * All constants explained in e.g. 
https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html
- * The older ones (bt470bg/m) are also explained in their respective ITU docs
- * (e.g. 
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-5-199802-S!!PDF-E.pdf)
- * whereas the newer ones can typically be copied directly from wikipedia :)
- */
-static const struct LumaCoefficients luma_coefficients[AVCOL_SPC_NB] = {
-[AVCOL_SPC_FCC]= { 0.30,   0.59,   0.11   },
-[AVCOL_SPC_BT470BG]= { 0.299,  0.587,  0.114  },
-[AVCOL_SPC_SMPTE170M]  = { 0.299,  0.587,  0.114  },
-[AVCOL_SPC_BT709]  = { 0.2126, 0.7152, 0.0722 },
-[AVCOL_SPC_SMPTE240M]  = { 0.212,  0.701,  0.087  },
-[AVCOL_SPC_YCOCG]  = { 0.25,   0.5,0.25   },
-[AVCOL_SPC_RGB]= { 1,  1,  1  },
-[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
-[AVCOL_SPC_BT2020_CL]  = { 0.2627, 0.6780, 0.0593 },
-};
-
-const struct LumaCoefficients *ff_get_luma_coefficients(enum AVColorSpace csp)
-{
-const struct LumaCoefficients *coeffs;
-
-if (csp >= AVCOL_SPC_NB)
-return NULL;
-coeffs = &luma_coefficients[csp];
-if (!coeffs->cr)
-return NULL;
-
-return coeffs;
-}
-
-#define WP_D65 { 0.3127, 0.3290 }
-#define WP_C   { 0.3100, 0.3160 }
-#define WP_DCI { 0.3140, 0.3510 }
-#define WP_E   { 1/3.0f, 1/3.0f }
-
-static const struct ColorPrimaries color_primaries[AVCOL_PRI_NB] = {
-[AVCOL_PRI_BT709] = { WP_D65, { 0.640, 0.330, 0.300, 0.600, 0.150, 
0.060 } },
-[AVCOL_PRI_BT470M]= { WP_C,   { 0.670, 0.330, 0.210, 0.710, 0.140, 
0.080 } },
-[AVCOL_PRI_BT470BG]   = { WP_D65, { 0.640, 0.330, 0.290, 0.600, 0.150, 
0.060 } },
-[AVCOL_PRI_SMPTE170M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
0.070 } },
-[AVCOL_PRI_SMPTE240M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
0.070 } },
-[AVCOL_PRI_SMPTE428]  = { WP_E,   { 0.735, 0.265, 0.274, 0.718, 0.167, 
0.009 } },
-[AVCOL_PRI_SMPTE431]  = { WP_DCI, { 0.680, 0.320, 0.265, 0.690, 0.150, 
0.060 } },
-[AVCOL_PRI_SMPTE432]  = { WP_D65, { 0.680, 0.320, 0.265, 0.690, 0.150, 
0.060 } },
-[AVCOL_PRI_FILM]  = { WP_C,   { 0.681, 0.319, 0.243, 0.692, 0.145, 
0.049 } },
-[AVCOL_PRI_BT2020]= { WP_D65, { 0.708, 0.292, 0.170, 0.797, 0.131, 
0.046 } },
-[AVCOL_PRI_JEDEC_P22] = { WP_D65, { 0.630, 0.340, 0.295, 0.605, 0.155, 
0.077 } },
-};
-
-const struct ColorPrimaries *ff_get_color_primaries(enum AVColorPrimaries prm)
-{
-const struct ColorPrimaries *p;
-
-if (prm >= AVCOL_PRI_NB)
-return NULL;
-p = &color_primaries[prm];
-if (!p->prim.xr)
-return NULL;
-
-return p;
-}
-
-enum AVColorPrimaries ff_detect_color_primaries(const struct ColorPrimaries 
*prm)
-{
-double delta;
-
-for (enum AVColorPrimaries p = 0; p < AVCOL_PRI_NB; p++) {
-const struct ColorPrimaries *ref = &color_primaries[p];
-if (!ref->prim.xr)
-continue;
-
-delta = fabs(prm->prim.xr - ref->prim.xr) +
-fabs(prm->prim.yr - ref->prim.yr) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yg - ref->prim.yg) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->prim.yb - ref->prim.yb) +
-fabs(prm->wp.xw - ref->wp.xw) +
-fabs(prm->wp.yw - ref->wp.yw);
-
-if (delta < 0.

[FFmpeg-devel] [PATCH] avcodec/libaomenc: Expose the allintra usage mode

2022-05-17 Thread Vignesh Venkatasubramanian
libaom added an usage=allintra mode for doing better with still
images. Expose that in the ffmpeg's wrapper. This is especially
useful for encoding still AVIF images.

Signed-off-by: Vignesh Venkatasubramanian 
---
 libavcodec/libaomenc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 0411773bbf..7a601c120e 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1298,8 +1298,11 @@ static const AVOption options[] = {
 { "enable-intrabc",  "Enable intra block copy prediction mode", 
OFFSET(enable_intrabc), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-restoration", "Enable Loop Restoration filtering", 
OFFSET(enable_restoration), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "usage",   "Quality and compression efficiency vs speed 
trade-off", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE, 
"usage"},
-{ "good","Good quality",  0, AV_OPT_TYPE_CONST, {.i64 = 0 
/* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
-{ "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 1 
/* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
+{ "good","Good quality",   0, AV_OPT_TYPE_CONST, {.i64 = 0 
/* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
+{ "realtime","Realtime encoding",  0, AV_OPT_TYPE_CONST, {.i64 = 1 
/* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
+#ifdef AOM_USAGE_ALL_INTRA
+{ "allintra","All Intra encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 2 
/* AOM_USAGE_ALL_INTRA */},0, 0, VE, "usage"},
+#endif
 { "tune","The metric that the encoder tunes for. Automatically 
chosen by the encoder by default", OFFSET(tune), AV_OPT_TYPE_INT, {.i64 = -1}, 
-1, AOM_TUNE_SSIM, VE, "tune"},
 { "psnr",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
AOM_TUNE_PSNR}, 0, 0, VE, "tune"},
 { "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
AOM_TUNE_SSIM}, 0, 0, VE, "tune"},
-- 
2.36.0.550.gb090851708-goog

___
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] avformat/img2: Add support for AVIF mux in image2

2022-05-17 Thread James Zern
On Mon, May 16, 2022 at 10:40 AM Vignesh Venkatasubramanian
 wrote:
>
> Add support for AVIF muxing in the image2 muxer.
>
> Tested with this example:
> ffmpeg -lavfi testsrc=duration=1:size=320x320 -g 1 -flags global_header -c:v 
> libaom-av1 -f image2 img-%2d.avif
>
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  libavformat/img2enc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>

lgtm.
___
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/libaomenc: Expose the allintra usage mode

2022-05-17 Thread James Zern
On Tue, May 17, 2022 at 11:24 AM Vignesh Venkatasubramanian
 wrote:
>
> libaom added an usage=allintra mode for doing better with still
> images. Expose that in the ffmpeg's wrapper. This is especially
> useful for encoding still AVIF images.
>
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  libavcodec/libaomenc.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>

lgtm. It seems this was never documented in encoders.texi:
http://ffmpeg.org/ffmpeg-codecs.html#libaom_002dav1

> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 0411773bbf..7a601c120e 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -1298,8 +1298,11 @@ static const AVOption options[] = {
>  { "enable-intrabc",  "Enable intra block copy prediction mode", 
> OFFSET(enable_intrabc), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>  { "enable-restoration", "Enable Loop Restoration filtering", 
> OFFSET(enable_restoration), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>  { "usage",   "Quality and compression efficiency vs speed 
> trade-off", OFFSET(usage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, VE, 
> "usage"},
> -{ "good","Good quality",  0, AV_OPT_TYPE_CONST, {.i64 = 
> 0 /* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
> -{ "realtime","Realtime encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 
> 1 /* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
> +{ "good","Good quality",   0, AV_OPT_TYPE_CONST, {.i64 = 
> 0 /* AOM_USAGE_GOOD_QUALITY */}, 0, 0, VE, "usage"},
> +{ "realtime","Realtime encoding",  0, AV_OPT_TYPE_CONST, {.i64 = 
> 1 /* AOM_USAGE_REALTIME */}, 0, 0, VE, "usage"},
> +#ifdef AOM_USAGE_ALL_INTRA
> +{ "allintra","All Intra encoding", 0, AV_OPT_TYPE_CONST, {.i64 = 
> 2 /* AOM_USAGE_ALL_INTRA */},0, 0, VE, "usage"},
> +#endif
>  { "tune","The metric that the encoder tunes for. 
> Automatically chosen by the encoder by default", OFFSET(tune), 
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, AOM_TUNE_SSIM, VE, "tune"},
>  { "psnr",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> AOM_TUNE_PSNR}, 0, 0, VE, "tune"},
>  { "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> AOM_TUNE_SSIM}, 0, 0, VE, "tune"},
> --
> 2.36.0.550.gb090851708-goog
>
> ___
> 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 v2] avcodec/libaomenc: Add unmet target level warning

2022-05-17 Thread James Zern
On Tue, Apr 19, 2022 at 11:20 AM Bohan Li
 wrote:
>
> When target levels are set, this patch checks whether they are
> satisfied by libaom. If not, a warning is shown. Otherwise the output
> levels are also logged.
>
> This patch applies basically the same approach used for libvpx.
>
> Signed-off-by: Bohan Li 
> ---
>  libavcodec/libaomenc.c | 64 ++
>  1 file changed, 64 insertions(+)
>

lgtm.
___
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] mov: Compare frag times in correct time base when seeking a stream without a corresponding sidx

2022-05-17 Thread Derek Buitenhuis
Some muxers, such as GPAC, create files with only one sidx, but two streams
muxed into the same fragments pointed to by this sidx.

Prevously, in such a case, when we seeked in such files, we fell back
to, for example, using the sidx associated with the video stream, to
seek the audio stream, leaving the seekhead in the wrong place.

We can still do this, but we need to take care to compare timestamps
in the same time base.

Signed-off-by: Derek Buitenhuis 
---
 libavformat/mov.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index d7be593a86..fe3b2b15ab 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1270,12 +1270,12 @@ static int64_t 
get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
 return frag_stream_info->tfdt_dts;
 }
 
-static int64_t get_frag_time(MOVFragmentIndex *frag_index,
- int index, int track_id)
+static int64_t get_frag_time(AVFormatContext *s, AVStream *dst_st,
+ MOVFragmentIndex *frag_index, int index, int 
track_id)
 {
 MOVFragmentStreamInfo * frag_stream_info;
 int64_t timestamp;
-int i;
+int i, j;
 
 if (track_id >= 0) {
 frag_stream_info = get_frag_stream_info(frag_index, index, track_id);
@@ -1287,15 +1287,23 @@ static int64_t get_frag_time(MOVFragmentIndex 
*frag_index,
 }
 
 for (i = 0; i < frag_index->item[index].nb_stream_info; i++) {
+AVStream *frag_stream = NULL;
 frag_stream_info = &frag_index->item[index].stream_info[i];
+for (j = 0; j < s->nb_streams; j++)
+if (s->streams[j]->id == frag_stream_info->id)
+frag_stream = s->streams[j];
 timestamp = get_stream_info_time(frag_stream_info);
-if (timestamp != AV_NOPTS_VALUE)
-return timestamp;
+if (timestamp != AV_NOPTS_VALUE) {
+if (frag_stream)
+return av_rescale_q(timestamp, frag_stream->time_base, 
dst_st->time_base);
+else
+return timestamp;
+}
 }
 return AV_NOPTS_VALUE;
 }
 
-static int search_frag_timestamp(MOVFragmentIndex *frag_index,
+static int search_frag_timestamp(AVFormatContext *s, MOVFragmentIndex 
*frag_index,
  AVStream *st, int64_t timestamp)
 {
 int a, b, m, m0;
@@ -1317,7 +1325,7 @@ static int search_frag_timestamp(MOVFragmentIndex 
*frag_index,
 m0 = m = (a + b) >> 1;
 
 while (m < b &&
-   (frag_time = get_frag_time(frag_index, m, id)) == 
AV_NOPTS_VALUE)
+   (frag_time = get_frag_time(s, st, frag_index, m, id)) == 
AV_NOPTS_VALUE)
 m++;
 
 if (m < b && frag_time <= timestamp)
@@ -8782,7 +8790,7 @@ static int mov_seek_fragment(AVFormatContext *s, AVStream 
*st, int64_t timestamp
 if (!mov->frag_index.complete)
 return 0;
 
-index = search_frag_timestamp(&mov->frag_index, st, timestamp);
+index = search_frag_timestamp(s, &mov->frag_index, st, timestamp);
 if (index < 0)
 index = 0;
 if (!mov->frag_index.item[index].headers_read)
-- 
2.36.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] libavformat/avformat: Check codec whitelist

2022-05-17 Thread Eric Juteau
Modified the function av_find_best_stream() such that, when a list of allowed 
codecs is supplied in the format context, and when the caller is requesting a 
decoder be returned, the function will select the best stream that has a 
decoder in the allowed decoders list.

Signed-off-by: Eric Juteau 
---
 libavformat/avformat.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 30d6ea6a49..396c1affa1 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -376,7 +376,8 @@ int av_find_best_stream(AVFormatContext *ic, enum 
AVMediaType type,
 continue;
 if (decoder_ret) {
 decoder = ff_find_decoder(ic, st, par->codec_id);
-if (!decoder) {
+if ((!decoder) ||
+(ic->codec_whitelist && av_match_list(decoder->name, 
ic->codec_whitelist, ',') <= 0)) {
 if (ret < 0)
 ret = AVERROR_DECODER_NOT_FOUND;
 continue;
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] mov: Compare frag times in correct time base when seeking a stream without a corresponding sidx

2022-05-17 Thread zhilizhao(赵志立)



> On May 18, 2022, at 4:39 AM, Derek Buitenhuis  
> wrote:
> 
> Some muxers, such as GPAC, create files with only one sidx, but two streams
> muxed into the same fragments pointed to by this sidx.
> 
> Prevously, in such a case, when we seeked in such files, we fell back
> to, for example, using the sidx associated with the video stream, to
> seek the audio stream, leaving the seekhead in the wrong place.
> 
> We can still do this, but we need to take care to compare timestamps
> in the same time base.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
> libavformat/mov.c | 24 
> 1 file changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index d7be593a86..fe3b2b15ab 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1270,12 +1270,12 @@ static int64_t 
> get_stream_info_time(MOVFragmentStreamInfo * frag_stream_info)
> return frag_stream_info->tfdt_dts;
> }
> 
> -static int64_t get_frag_time(MOVFragmentIndex *frag_index,
> - int index, int track_id)
> +static int64_t get_frag_time(AVFormatContext *s, AVStream *dst_st,
> + MOVFragmentIndex *frag_index, int index, int 
> track_id)
> {

I have an idea which needs more refactor:

1. Remove track_id argument, the `if (track_id >= 0)` code path, and the related
part in search_frag_timestamp().

Setting track_id in search_frag_timestamp() is defect. sc->has_sidx is checked
there, while tfra can be used here.

track_id means to set a higher priority on a stream, while now we have dst_st,
which has more information than track_id.


2. Give dst_st a higher priority, and search all streams.


> MOVFragmentStreamInfo * frag_stream_info;
> int64_t timestamp;
> -int i;
> +int i, j;
> 
> if (track_id >= 0) {
> frag_stream_info = get_frag_stream_info(frag_index, index, track_id);
> @@ -1287,15 +1287,23 @@ static int64_t get_frag_time(MOVFragmentIndex 
> *frag_index,
> }
> 
> for (i = 0; i < frag_index->item[index].nb_stream_info; i++) {
> +AVStream *frag_stream = NULL;
> frag_stream_info = &frag_index->item[index].stream_info[i];
> +for (j = 0; j < s->nb_streams; j++)
> +if (s->streams[j]->id == frag_stream_info->id)
> +frag_stream = s->streams[j];
> timestamp = get_stream_info_time(frag_stream_info);
> -if (timestamp != AV_NOPTS_VALUE)
> -return timestamp;
> +if (timestamp != AV_NOPTS_VALUE) {
> +if (frag_stream)
> +return av_rescale_q(timestamp, frag_stream->time_base, 
> dst_st->time_base);
> +else
> +return timestamp;
> +}
> }
> return AV_NOPTS_VALUE;
> }
> 
> -static int search_frag_timestamp(MOVFragmentIndex *frag_index,
> +static int search_frag_timestamp(AVFormatContext *s, MOVFragmentIndex 
> *frag_index,
>  AVStream *st, int64_t timestamp)
> {
> int a, b, m, m0;
> @@ -1317,7 +1325,7 @@ static int search_frag_timestamp(MOVFragmentIndex 
> *frag_index,
> m0 = m = (a + b) >> 1;
> 
> while (m < b &&
> -   (frag_time = get_frag_time(frag_index, m, id)) == 
> AV_NOPTS_VALUE)
> +   (frag_time = get_frag_time(s, st, frag_index, m, id)) == 
> AV_NOPTS_VALUE)
> m++;
> 
> if (m < b && frag_time <= timestamp)
> @@ -8782,7 +8790,7 @@ static int mov_seek_fragment(AVFormatContext *s, 
> AVStream *st, int64_t timestamp
> if (!mov->frag_index.complete)
> return 0;
> 
> -index = search_frag_timestamp(&mov->frag_index, st, timestamp);
> +index = search_frag_timestamp(s, &mov->frag_index, st, timestamp);
> if (index < 0)
> index = 0;
> if (!mov->frag_index.item[index].headers_read)
> -- 
> 2.36.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 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".