[FFmpeg-devel] [PATCH] avformat/aviobuf: don't reduce short seek threshold
From: Andriy Gelman
Commit 8c8e5d5286bf598a89ef9993a2cf6ea409d03a32 added a way to reduce
seek time by waiting for the windowed tcp packets instead of creating a
new socket connection. It implemented this by overwriting
s->short_seek_threshold in the avio_seek(). However,
s->short_seek_threshold could already be set and be higher than the
threshold set by the protocol (i.e. s->short_seek_threshold is set in
ff_configure_buffers_for_index()).
This new feature was only enabled for tls connections in
70d8077b795766e2486e6ec8110f22a97362d6d7. As in Ticket #9148 it reduced
performance because instead of waiting to refill the AVIOContext buffers
with an existing connections, a new HTTP request was often made instead.
Fixes Ticket #9148.
Signed-off-by: Andriy Gelman
---
libavformat/aviobuf.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 78cc60b2ae..518cb11129 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -283,13 +283,9 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int
whence)
if (offset < 0)
return AVERROR(EINVAL);
-if (s->short_seek_get) {
-short_seek = s->short_seek_get(s->opaque);
-/* fallback to default short seek */
-if (short_seek <= 0)
-short_seek = s->short_seek_threshold;
-} else
-short_seek = s->short_seek_threshold;
+short_seek = s->short_seek_threshold;
+if (s->short_seek_get)
+short_seek = FFMAX(s->short_seek_get(s->opaque), short_seek);
offset1 = offset - pos; // "offset1" is the relative offset from the
beginning of s->buffer
s->buf_ptr_max = FFMAX(s->buf_ptr_max, s->buf_ptr);
--
2.30.2
___
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] avutils/hwcontext_qsv: set the source device in qsv_device_create
> You are hacking it to lie to the hwcontext implementation around how the > device was derived, so the test fails because it finds a different derivation > structure to what it created? That seems correct? > > Your command-line was: > > $ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device > opencl=ocl@intel -hwaccel qsv -c:v h264_qsv -hwaccel_output_format qsv -i > $input -filter_hw_device ocl -vf > 'hwmap=derive_device=opencl,format=opencl,unsharp_opencl,hwmap=der > ive_device=qsv:reverse=1:extra_hw_frames=32' -c:v hevc_qsv -y test.h265 > > So that's trying to make five device references in turn: > > 1. Make a VAAPI device explicitly. > 2. Derive an OpenCL device from the VAAPI device 1. > 3. Make a libmfx device implicitly (because a libmfx decoder was requested). > 4. Derive a new OpenCL device from the libmfx device 3 (you told the filter > graph about device 2, but then didn't use it anywhere). > 5. Derive a libmfx device from the OpenCL device 4, which should return > libmfx device 3. > > What's going wrong? Step 4 fails to create an OpenCL device because > devices 1/2 and device 3 aren't actually connected together at all. > > How to solve that? Either we can fix the connection, or we could just use the > device we already have in step 4 rather than trying to create a new one. > > To fix the connection, derive device 3 from device 1. This doesn't work in > the > ffmpeg utility because the hacky support in ffmpeg_qsv.c doesn't support > the normal device stuff. It would work in your own program. > > Using the existing device (by using device 2 rather than deriving a new on at > step 4) looks like it should work: > > $ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device > opencl=ocl@intel -hwaccel qsv -c:v h264_qsv -hwaccel_output_format qsv -i > $input -filter_hw_device ocl -vf > 'hwmap,format=opencl,unsharp_opencl,hwmap=derive_device=qsv:revers > e=1:extra_hw_frames=32' -c:v hevc_qsv -y test.h265 > > Unfortunately it doesn't, and for the same reason that the first approach > didn't - devices 1 and 3 aren't connected, so the OpenCL mapping is being > given frames in the wrong device context and therefore fails (in fact the > Intel > ICD crashes with an abort, which is about the best you can hope for with this > sort of undefined behaviour). > > > So, how can we make this work? Well, the weird libmfx hacks are causing the > problem, so let's just duck that by dumping the pointless wrapper decoder > and using the normal decoder directly: Hi Mark, Thanks for the detailed explaining. I will try the vaapi path. thanks > > $ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -hwaccel vaapi - > hwaccel_output_format vaapi -i $input -vf > 'hwmap=derive_device=opencl,format=opencl,unsharp_opencl,hwmap=der > ive_device=qsv:reverse=1:extra_hw_frames=32' -c:v hevc_qsv -y test.h265 > > If you want to make it work with the libmfx wrapper decoder, then I think > the most sensible way is to implement > AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX in that decoder so it > works like the others and the ffmpeg_qsv.c hacks can be removed entirely. > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: stop using sizeof(AVFrame)
Signed-off-by: James Almer
---
Setting pkt->size to 0 but leaving pkt->data pointing to the frame ensures that
the packet isn't mistaken for an empty one, and prevents wrong use of the data
pointer in case av_packet_make_writable() is called on it (The resulting packet
will be the same as if you call it on an empty one).
I decided to set the opaque field of the AVBufferRef to the frame pointer so
we can do something like ensure pkt->size is 0 and pkt->data is equal to it
before trying to treat pkt->data as an AVFrame, but i'm not sure if that could
be done now, or only after a major bump (e.g. 4.3 lavf/lavd and 4.4 lavc at
runtime, where demuxers like the vapoursynth one propagate packets to the
wrapped_avframe decoder, and if the latter does the above check, it would
fail).
libavcodec/wrapped_avframe.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c
index 85ff32d13a..c921990024 100644
--- a/libavcodec/wrapped_avframe.c
+++ b/libavcodec/wrapped_avframe.c
@@ -44,32 +44,20 @@ static int wrapped_avframe_encode(AVCodecContext *avctx,
AVPacket *pkt,
const AVFrame *frame, int *got_packet)
{
AVFrame *wrapped = av_frame_clone(frame);
-uint8_t *data;
-int size = sizeof(*wrapped) + AV_INPUT_BUFFER_PADDING_SIZE;
if (!wrapped)
return AVERROR(ENOMEM);
-data = av_mallocz(size);
-if (!data) {
-av_frame_free();
-return AVERROR(ENOMEM);
-}
-
-pkt->buf = av_buffer_create(data, size,
-wrapped_avframe_release_buffer, NULL,
+pkt->buf = av_buffer_create((uint8_t *)wrapped, 0,
+wrapped_avframe_release_buffer, wrapped,
AV_BUFFER_FLAG_READONLY);
if (!pkt->buf) {
av_frame_free();
-av_freep();
return AVERROR(ENOMEM);
}
-av_frame_move_ref((AVFrame*)data, wrapped);
-av_frame_free();
-
-pkt->data = data;
-pkt->size = sizeof(*wrapped);
+pkt->data = (uint8_t *)wrapped;
+pkt->size = 0;
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = 1;
@@ -87,9 +75,6 @@ static int wrapped_avframe_decode(AVCodecContext *avctx, void
*data,
return AVERROR(EPERM);
}
-if (pkt->size < sizeof(AVFrame))
-return AVERROR(EINVAL);
-
in = (AVFrame*)pkt->data;
out = data;
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/http, tls: honor http_proxy command line variable for HTTPS
On Sun, Aug 23, 2020 at 22:50:18 +0300, Martin Storsjö wrote:
> > On Fri, Aug 21, 2020 at 12:19:06 +0300, Martin Storsjö wrote:
> > > LGTM, with one small nit:
> > [...]
> > > > {"listen", "Listen for incoming connections",
> > > > offsetof(pstruct, options_field . listen),AV_OPT_TYPE_INT, { .i64 =
> > > > 0 }, 0, 1, .flags = TLS_OPTFL }, \
> > > > +{"http_proxy", "set proxy to tunnel through when using HTTPS",
> > > > offsetof(pstruct, options_field . http_proxy), AV_OPT_TYPE_STRING,
> > > > .flags = TLS_OPTFL }, \
> > > > {"verifyhost", "Verify against a specific hostname",
> > > > offsetof(pstruct, options_field . host), AV_OPT_TYPE_STRING,
> > > > .flags = TLS_OPTFL }
> > >
> > > I'd remove the "when using HTTPS" bit here.
> >
> > Done. I also chose to make the capitalization consistent, and move the
> > option down, as "verifyhost" is related to the certificate options (and
> > should thus perhaps even be above "listen").
>
> Thanks, this version LGTM.
Ping. Is this okay to apply? Could someone please?
Thanks,
Moritz
___
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] fftools/ffmpeg: use the correct size value for wrapped_avframe packets
On 3/13/2021 8:44 PM, James Almer wrote:
pkt->size on packets wrapping an AVFrame signaled by the wrapped_avframe
codec_id are set to the size of the AVFrame structure and not the actual raw
data contained in it.
ffmpeg.c was using those values to print bogus stats about the resulting output
file.
Before this patch:
frame= 24 fps=0.0 q=-0.0 Lsize=7594kB time=00:00:01.00
bitrate=62209.8kbits/s speed= 27x
video:13kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 60349.488281%
After:
frame= 24 fps=0.0 q=-0.0 Lsize=7594kB time=00:00:01.00
bitrate=62209.8kbits/s speed= 28x
video:7594kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.002855%
Signed-off-by: James Almer
---
wrapped_avframe should be redefined to stop using sizeof(AVFrame) altogether.
I'll send a patch with a proposed approach for this.
fftools/ffmpeg.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2abbc0ff29..6dcf9006db 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -727,7 +727,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost, int u
{
AVFormatContext *s = of->ctx;
AVStream *st = ost->st;
-int ret;
+int size, ret;
/*
* Audio encoders may split the packets -- #frames in != #packets out.
@@ -842,7 +842,17 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost, int u
}
ost->last_mux_dts = pkt->dts;
-ost->data_size += pkt->size;
+if (st->codecpar->codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
+AVFrame *frame = (AVFrame *)pkt->data;
+if (!frame)
+exit_program(1);
+size = av_image_get_buffer_size(frame->format, frame->width,
frame->height, 1);
+if (size < 0)
+exit_program(1);
Changed this locally to fallback to pkt->size to avoid breaking hardware
pixel formats.
+} else
+size = pkt->size;
+
+ost->data_size += size;
ost->packets_written++;
pkt->stream_index = ost->index;
___
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] fftools/ffmpeg: use the correct size value for wrapped_avframe packets
pkt->size on packets wrapping an AVFrame signaled by the wrapped_avframe
codec_id are set to the size of the AVFrame structure and not the actual raw
data contained in it.
ffmpeg.c was using those values to print bogus stats about the resulting output
file.
Before this patch:
frame= 24 fps=0.0 q=-0.0 Lsize=7594kB time=00:00:01.00
bitrate=62209.8kbits/s speed= 27x
video:13kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 60349.488281%
After:
frame= 24 fps=0.0 q=-0.0 Lsize=7594kB time=00:00:01.00
bitrate=62209.8kbits/s speed= 28x
video:7594kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.002855%
Signed-off-by: James Almer
---
wrapped_avframe should be redefined to stop using sizeof(AVFrame) altogether.
I'll send a patch with a proposed approach for this.
fftools/ffmpeg.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2abbc0ff29..6dcf9006db 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -727,7 +727,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost, int u
{
AVFormatContext *s = of->ctx;
AVStream *st = ost->st;
-int ret;
+int size, ret;
/*
* Audio encoders may split the packets -- #frames in != #packets out.
@@ -842,7 +842,17 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost, int u
}
ost->last_mux_dts = pkt->dts;
-ost->data_size += pkt->size;
+if (st->codecpar->codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
+AVFrame *frame = (AVFrame *)pkt->data;
+if (!frame)
+exit_program(1);
+size = av_image_get_buffer_size(frame->format, frame->width,
frame->height, 1);
+if (size < 0)
+exit_program(1);
+} else
+size = pkt->size;
+
+ost->data_size += size;
ost->packets_written++;
pkt->stream_index = ost->index;
--
2.30.2
___
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] FFmpeg Meeting of March 13.
Hello folks, Today, March 13, 2021, was held an FFmpeg developer meeting, to speak about our current developer situation. The meeting started on IRC and on Jitsi, at 17:00 Berlin/Paris time. There were from 10 to 16 people on the Jitsi call, and a few other that were only on IRC. 1. GA update The General Assembly list of members was updated with the rules that were decided in the past. The extra members are kept. The current GA is now 40 people in 2021. A few people lost their vote rights (Dale, Diego, foobaz, Vittorio, some Google, and Akamai folks) and a few were added, notably from Intel. No new extra member was nominated lately, nor doing the call. You can nominate anyone at any time. 2. Voting system The new voting system is finally in place and working And the SchulzeSTV method now works. Please note that some people don't receive the voting system emails, notably in China. 3. TC & TC rules 24 people out of 40 people from the GA voted for the new Technical Committee rules. 23 people were for, and 1 was against. The rules are now enforced. TC is now fully functional. t...@ffmpeg.org alias is actually working. 4. GSoC FFmpeg is part of GSoC 2021. Yay \o/ PLEASE please, PLEASE add more tasks, even without mentors: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2021 Note that GSoC this year is shorter than usual, so smaller tasks, including improvements of current projects or current modules. Smallish improvement or cleanups of patches that were never merged can work as GSoC Ideas discussed were: Vapoursynth, curl Dash, Pipewire?, Wayland?, Better Windows capture? Fate-network. Please add some of them. 5. Hardware Who needs hardware? We discussed about access to hardware for Fate and for HwAccel development. Discussion around access to nVidia hardware was done. In order to get more hardware, please ask on the mailing list like Kieran did the other day. We have over 100k$ available at SPI, so please ask. The hardware is still owned by SPI, but it can be used unlimited in time. Question was raised about FFmtech fate/bane -> JB to ask Ronald and Stefano what is the statut. We then discussed about doing a Simple software to be developed for network testing of Fate. Maybe as a GSoC task? 6. Next major bump discussion We discussed about the next major bump. Tasks mentionned: - james's AVPacket patch set - being able to remove deprecated features - mcdeint and uspp still utilize deprecated (?) APIs It is important to explain WHY we need this bump, and the reasons, for our users. 7. CC/CoC CoC -> JB, move your *ss 8. Next release We spoke quickly about the next release. Nothing very specific, but it would be nice if james patchset could get in. 9. Release schedule Discussion arrived about codifying the release schedule, notably which versions to maintain, when do we bump or not, when do we deprecate or not, and if we can do an LTS system. This will be discussed on the mailing list later. 10. Migrate Trac to an up-to-date version -> let's talk to A Strasser to at least update to 1.4.x 11. We spoke about Gitlab-like migration. - Easier to list MRs VS mailing list threads - Built-in CI which can be modified more easily than the current patchwork FATE running nothing was decided, but the list of requirements for such a system should be discussed. 12. NDI/Vk and so on We discussed about a policy for hardware criteria to allow or not those hardware and libraries. 13. Swscale. We talked about it, without any specific conclusion. Same for I/O event-based loop. I probably forgot things, but you should attend anyway :) Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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 8/8] avformat/assenc: do not overread if zero padding is missing
Signed-off-by: Marton Balint
---
libavformat/assenc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavformat/assenc.c b/libavformat/assenc.c
index 68c3396e5a..265b5996ac 100644
--- a/libavformat/assenc.c
+++ b/libavformat/assenc.c
@@ -156,16 +156,23 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
ASSContext *ass = s->priv_data;
long int layer;
-char *p = pkt->data;
+char *dup = av_strndup(pkt->data, pkt->size);
+char *p = dup;
int64_t start = pkt->pts;
int64_t end = start + pkt->duration;
int hh1, mm1, ss1, ms1;
int hh2, mm2, ss2, ms2;
-DialogueLine *dialogue = av_mallocz(sizeof(*dialogue));
+DialogueLine *dialogue;
-if (!dialogue)
+if (!dup)
return AVERROR(ENOMEM);
+dialogue = av_mallocz(sizeof(*dialogue));
+if (!dialogue) {
+av_free(dup);
+return AVERROR(ENOMEM);
+}
+
dialogue->readorder = strtol(p, , 10);
if (dialogue->readorder < ass->expected_readorder)
av_log(s, AV_LOG_WARNING, "Unexpected ReadOrder %d\n",
@@ -189,6 +196,8 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
dialogue->line =
av_asprintf("%s%ld,%d:%02d:%02d.%02d,%d:%02d:%02d.%02d,%s",
ass->ssa_mode ? "Marked=" : "",
layer, hh1, mm1, ss1, ms1, hh2, mm2, ss2,
ms2, p);
+av_free(dup);
+
if (!dialogue->line) {
av_free(dialogue);
return AVERROR(ENOMEM);
--
2.26.2
___
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 7/8] avcodec/srtdec: do not overread if zero padding is missing
Signed-off-by: Marton Balint
---
libavcodec/srtdec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/srtdec.c b/libavcodec/srtdec.c
index 98f84ac673..37fb0d3173 100644
--- a/libavcodec/srtdec.c
+++ b/libavcodec/srtdec.c
@@ -62,6 +62,7 @@ static int srt_decode_frame(AVCodecContext *avctx,
buffer_size_t size;
const uint8_t *p = av_packet_get_side_data(avpkt,
AV_PKT_DATA_SUBTITLE_POSITION, );
FFASSDecoderContext *s = avctx->priv_data;
+char *dup;
if (p && size == 16) {
x1 = AV_RL32(p );
@@ -73,12 +74,17 @@ static int srt_decode_frame(AVCodecContext *avctx,
if (avpkt->size <= 0)
return avpkt->size;
+dup = av_strndup(avpkt->data, avpkt->size);
+if (!dup)
+return AVERROR(ENOMEM);
+
av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
-ret = srt_to_ass(avctx, , avpkt->data, x1, y1, x2, y2);
+ret = srt_to_ass(avctx, , dup, x1, y1, x2, y2);
if (ret >= 0)
ret = ff_ass_add_rect(sub, buffer.str, s->readorder++, 0, NULL, NULL);
av_bprint_finalize(, NULL);
+av_free(dup);
if (ret < 0)
return ret;
--
2.26.2
___
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 6/8] avcodec/webvttdec: do not overread if zero padding is missing
Signed-off-by: Marton Balint
---
libavcodec/webvttdec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 7b2d1750de..43caf3edbd 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -42,23 +42,23 @@ static const struct {
{"", "&"}, {"", "\\h"},
};
-static int webvtt_event_to_ass(AVBPrint *buf, const char *p)
+static int webvtt_event_to_ass(AVBPrint *buf, const char *p, const char *pend)
{
int i, again = 0, skip = 0;
-while (*p) {
+while (p < pend && *p) {
for (i = 0; i < FF_ARRAY_ELEMS(webvtt_tag_replace); i++) {
const char *from = webvtt_tag_replace[i].from;
const size_t len = strlen(from);
-if (!strncmp(p, from, len)) {
+if (pend - p >= len && !strncmp(p, from, len)) {
av_bprintf(buf, "%s", webvtt_tag_replace[i].to);
p += len;
again = 1;
break;
}
}
-if (!*p)
+if (p == pend || !*p)
break;
if (again) {
@@ -89,7 +89,7 @@ static int webvtt_decode_frame(AVCodecContext *avctx,
AVBPrint buf;
av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
-if (ptr && avpkt->size > 0 && !webvtt_event_to_ass(, ptr))
+if (ptr && avpkt->size > 0 && !webvtt_event_to_ass(, ptr, ptr +
avpkt->size))
ret = ff_ass_add_rect(sub, buf.str, s->readorder++, 0, NULL, NULL);
av_bprint_finalize(, NULL);
if (ret < 0)
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/8] avcodec/subviewerdec: do not overread if zero padding is missing
Signed-off-by: Marton Balint
---
libavcodec/subviewerdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/subviewerdec.c b/libavcodec/subviewerdec.c
index 805c7dd547..1016ac7ada 100644
--- a/libavcodec/subviewerdec.c
+++ b/libavcodec/subviewerdec.c
@@ -28,10 +28,10 @@
#include "ass.h"
#include "libavutil/bprint.h"
-static int subviewer_event_to_ass(AVBPrint *buf, const char *p)
+static int subviewer_event_to_ass(AVBPrint *buf, const char *p, const char
*pend)
{
-while (*p) {
-if (!strncmp(p, "[br]", 4)) {
+while (p < pend && *p) {
+if (pend - p >= 4 && !strncmp(p, "[br]", 4)) {
av_bprintf(buf, "\\N");
p += 4;
} else {
@@ -56,7 +56,7 @@ static int subviewer_decode_frame(AVCodecContext *avctx,
AVBPrint buf;
av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
-if (ptr && avpkt->size > 0 && !subviewer_event_to_ass(, ptr))
+if (ptr && avpkt->size > 0 && !subviewer_event_to_ass(, ptr, ptr +
avpkt->size))
ret = ff_ass_add_rect(sub, buf.str, s->readorder++, 0, NULL, NULL);
av_bprint_finalize(, NULL);
if (ret < 0)
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/8] avcodec/realtextdec: do not overread if zero padding is missing
Signed-off-by: Marton Balint
---
libavcodec/realtextdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/realtextdec.c b/libavcodec/realtextdec.c
index 5084781123..bdd9659235 100644
--- a/libavcodec/realtextdec.c
+++ b/libavcodec/realtextdec.c
@@ -29,11 +29,11 @@
#include "libavutil/avstring.h"
#include "libavutil/bprint.h"
-static int rt_event_to_ass(AVBPrint *buf, const char *p)
+static int rt_event_to_ass(AVBPrint *buf, const char *p, const char *pend)
{
int prev_chr_is_space = 1;
-while (*p) {
+while (p < pend && *p) {
if (*p != '<') {
if (!av_isspace(*p))
av_bprint_chars(buf, *p, 1);
@@ -41,7 +41,7 @@ static int rt_event_to_ass(AVBPrint *buf, const char *p)
av_bprint_chars(buf, ' ', 1);
prev_chr_is_space = av_isspace(*p);
} else {
-const char *end = strchr(p, '>');
+const char *end = av_strnstr(p, ">", pend - p);
if (!end)
break;
if (!av_strncasecmp(p, "", 5) ||
@@ -65,7 +65,7 @@ static int realtext_decode_frame(AVCodecContext *avctx,
AVBPrint buf;
av_bprint_init(, 0, 4096);
-if (ptr && avpkt->size > 0 && !rt_event_to_ass(, ptr))
+if (ptr && avpkt->size > 0 && !rt_event_to_ass(, ptr, ptr +
avpkt->size))
ret = ff_ass_add_rect(sub, buf.str, s->readorder++, 0, NULL, NULL);
av_bprint_finalize(, NULL);
if (ret < 0)
--
2.26.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/8] avcodec/mpl2dec: do not overread if zero padding is missing
Signed-off-by: Marton Balint
---
libavcodec/mpl2dec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mpl2dec.c b/libavcodec/mpl2dec.c
index 409e4b3708..efeecb0d64 100644
--- a/libavcodec/mpl2dec.c
+++ b/libavcodec/mpl2dec.c
@@ -29,15 +29,15 @@
#include "ass.h"
#include "libavutil/bprint.h"
-static int mpl2_event_to_ass(AVBPrint *buf, const char *p)
+static int mpl2_event_to_ass(AVBPrint *buf, const char *p, const char *pend)
{
if (*p == ' ')
p++;
-while (*p) {
+while (p < pend && *p) {
int got_style = 0;
-while (*p && strchr("/\\_", *p)) {
+while (p < pend && *p && strchr("/\\_", *p)) {
if (*p == '/') av_bprintf(buf, "{\\i1}");
else if (*p == '\\') av_bprintf(buf, "{\\b1}");
else if (*p == '_') av_bprintf(buf, "{\\u1}");
@@ -45,13 +45,13 @@ static int mpl2_event_to_ass(AVBPrint *buf, const char *p)
p++;
}
-while (*p && *p != '|') {
+while (p < pend && *p && *p != '|') {
if (*p != '\r' && *p != '\n')
av_bprint_chars(buf, *p, 1);
p++;
}
-if (*p == '|') {
+if (p < pend && *p == '|') {
if (got_style)
av_bprintf(buf, "{\\r}");
av_bprintf(buf, "\\N");
@@ -72,7 +72,7 @@ static int mpl2_decode_frame(AVCodecContext *avctx, void
*data,
FFASSDecoderContext *s = avctx->priv_data;
av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
-if (ptr && avpkt->size > 0 && *ptr && !mpl2_event_to_ass(, ptr))
+if (ptr && avpkt->size > 0 && *ptr && !mpl2_event_to_ass(, ptr, ptr +
avpkt->size))
ret = ff_ass_add_rect(sub, buf.str, s->readorder++, 0, NULL, NULL);
av_bprint_finalize(, NULL);
if (ret < 0)
--
2.26.2
___
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/8] avcodec/samidec: do not overread if zero padding is missing
Signed-off-by: Marton Balint
---
libavcodec/samidec.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavcodec/samidec.c b/libavcodec/samidec.c
index e32f238c62..f03b5db958 100644
--- a/libavcodec/samidec.c
+++ b/libavcodec/samidec.c
@@ -38,12 +38,12 @@ typedef struct {
int readorder;
} SAMIContext;
-static int sami_paragraph_to_ass(AVCodecContext *avctx, const char *src)
+static int sami_paragraph_to_ass(AVCodecContext *avctx, const char *src,
size_t size)
{
SAMIContext *sami = avctx->priv_data;
int ret = 0;
char *tag = NULL;
-char *dupsrc = av_strdup(src);
+char *dupsrc = av_strndup(src, size);
char *p = dupsrc;
AVBPrint *dst_content = >encoded_content;
AVBPrint *dst_source = >encoded_source;
@@ -135,11 +135,10 @@ static int sami_decode_frame(AVCodecContext *avctx,
void *data, int *got_sub_ptr, AVPacket *avpkt)
{
AVSubtitle *sub = data;
-const char *ptr = avpkt->data;
SAMIContext *sami = avctx->priv_data;
-if (ptr && avpkt->size > 0) {
-int ret = sami_paragraph_to_ass(avctx, ptr);
+if (avpkt->data && avpkt->size > 0) {
+int ret = sami_paragraph_to_ass(avctx, avpkt->data, avpkt->size);
if (ret < 0)
return ret;
// TODO: pass escaped sami->encoded_source.str as source
--
2.26.2
___
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/8] avcodec/assdec: do not overread if zero padding is missing
Signed-off-by: Marton Balint --- libavcodec/assdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/assdec.c b/libavcodec/assdec.c index f0b1069cd2..655fc1365c 100644 --- a/libavcodec/assdec.c +++ b/libavcodec/assdec.c @@ -54,7 +54,7 @@ static int ass_decode_frame(AVCodecContext *avctx, void *data, int *got_sub_ptr, return AVERROR(ENOMEM); sub->num_rects = 1; sub->rects[0]->type = SUBTITLE_ASS; -sub->rects[0]->ass = av_strdup(avpkt->data); +sub->rects[0]->ass = av_strndup(avpkt->data, avpkt->size); if (!sub->rects[0]->ass) return AVERROR(ENOMEM); *got_sub_ptr = 1; -- 2.26.2 ___ 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] avutil/common: Add FFINCREASE_PTR()
On Sat, Mar 13, 2021 at 04:41:39PM +0100, Lynne wrote:
> Mar 13, 2021, 16:18 by mich...@niedermayer.cc:
>
> > On Fri, Feb 19, 2021 at 10:00:39PM +0100, Andreas Rheinhardt wrote:
> >
> >> Michael Niedermayer:
> >> > Suggested-by: Andreas Rheinhardt
> >> > Signed-off-by: Michael Niedermayer
> >> > ---
> >> > doc/APIchanges | 3 +++
> >> > libavutil/common.h | 2 ++
> >> > 2 files changed, 5 insertions(+)
> >> >
> >> > diff --git a/doc/APIchanges b/doc/APIchanges
> >> > index c353d2d281..e38a5cb91c 100644
> >> > --- a/doc/APIchanges
> >> > +++ b/doc/APIchanges
> >> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >> >
> >> > API changes, most recent first:
> >> >
> >> > +2021-02-xx - xx - lavu 57.xx.100 - common.h
> >> > + Add FFINCREASE_PTR()
> >> > +
> >> > 2021-02-14 - xx - lavd 58.12.100 - avdevice.h
> >> >Deprecated avdevice_capabilities_create() and
> >> >avdevice_capabilities_free().
> >> > diff --git a/libavutil/common.h b/libavutil/common.h
> >> > index aee353d399..bf35bc8507 100644
> >> > --- a/libavutil/common.h
> >> > +++ b/libavutil/common.h
> >> > @@ -108,6 +108,8 @@
> >> > #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a=
> >> > SWAP_tmp;}while(0)
> >> > #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
> >> >
> >> > +#define FFINCREASE_PTR(ptr, off) ((off) ? (ptr) + (off) : (ptr))
> >> > +
> >> > /* misc math functions */
> >> >
> >> > #ifdef HAVE_AV_CONFIG_H
> >> >
> >> If this is intended to be a public macro, it should have a proper AV
> >> prefix.
> >>
> >
> > will apply with AV prefix
> >
>
> Could we not make it public? Macros like FF_ARRAY_ELEMS aren't,
> and I think this is one of those utility functions that API users probably
> won't find useful.
> Plus the name is kinda long.
would you prefer FF_PTR_ADD() ?
or do you have another name in mind ?
thx
[..]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
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] libavdevice/avfoundation: add buffer fifo and output packets in order they arrive
On Sun., Feb. 28, 2021, 8:30 p.m. Mark Reid, wrote:
>
>
> On Sat, Feb 13, 2021 at 10:04 PM wrote:
>
>> From: Mark Reid
>>
>> Hi,
>> This patch fixes audio issues I've had with some capture devices. The
>> audio
>> gets really choppy and stops working. This seems to be because
>> avf_read_packet
>> stops outputting the audio frames because a video frame happens to be
>> available first.
>>
>> It base on the approach used in a patch from #4437
>> https://trac.ffmpeg.org/ticket/4437
>>
>> My approach uses an AVFifoBuffer instead of NSMutableArray and also
>> outputs the packets in the same order they arrive from AVFFoundation.
>>
>> should fix ticket #4437 and #4513
>>
>>
>> ---
>> libavdevice/avfoundation.m | 160 -
>> 1 file changed, 124 insertions(+), 36 deletions(-)
>>
>> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
>> index 59d5b0af4f..5ac6ec4183 100644
>> --- a/libavdevice/avfoundation.m
>> +++ b/libavdevice/avfoundation.m
>> @@ -31,13 +31,17 @@
>> #include "libavutil/pixdesc.h"
>> #include "libavutil/opt.h"
>> #include "libavutil/avstring.h"
>> +#include "libavutil/avassert.h"
>> #include "libavformat/internal.h"
>> #include "libavutil/internal.h"
>> #include "libavutil/parseutils.h"
>> #include "libavutil/time.h"
>> #include "libavutil/imgutils.h"
>> +#include "libavutil/fifo.h"
>> #include "avdevice.h"
>>
>> +#define FIFO_SIZE 4
>> +
>> static const int avf_time_base = 100;
>>
>> static const AVRational avf_time_base_q = {
>> @@ -128,8 +132,8 @@ typedef struct
>> AVCaptureSession *capture_session;
>> AVCaptureVideoDataOutput *video_output;
>> AVCaptureAudioDataOutput *audio_output;
>> -CMSampleBufferRef current_frame;
>> -CMSampleBufferRef current_audio_frame;
>> +AVFifoBuffer *video_fifo;
>> +AVFifoBuffer *audio_fifo;
>>
>> AVCaptureDevice *observed_device;
>> #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
>> @@ -138,6 +142,11 @@ typedef struct
>> int observed_quit;
>> } AVFContext;
>>
>> +typedef struct {
>> +int64_t ts;
>> +CMSampleBufferRef frame;
>> +} BufferRef;
>> +
>> static void lock_frames(AVFContext* ctx)
>> {
>> pthread_mutex_lock(>frame_lock);
>> @@ -148,6 +157,48 @@ static void unlock_frames(AVFContext* ctx)
>> pthread_mutex_unlock(>frame_lock);
>> }
>>
>> +static inline void fifo_write(AVFifoBuffer* f, int64_t ts,
>> CMSampleBufferRef frame)
>> +{
>> +BufferRef buf = {
>> +.ts= ts,
>> +.frame = frame,
>> +};
>> +
>> +CFRetain(frame);
>> +av_fifo_generic_write(f, , sizeof(BufferRef), NULL);
>> +}
>> +
>> +static inline void fifo_peek(AVFifoBuffer* f, BufferRef *buf)
>> +{
>> +if (av_fifo_size(f)) {
>> +av_fifo_generic_peek(f, buf, sizeof(BufferRef), NULL);
>> +return;
>> +}
>> +buf->frame = nil;
>> +return;
>> +}
>> +
>> +static inline void fifo_drain(AVFifoBuffer* f, int release)
>> +{
>> +av_assert2(av_fifo_size(f) >= sizeof(BufferRef));
>> +if (release) {
>> +BufferRef buf;
>> +fifo_peek(f, );
>> +CFRelease(buf.frame);
>> +}
>> +av_fifo_drain(f, sizeof(BufferRef));
>> +}
>> +
>> +static inline void fifo_freep(AVFifoBuffer **f)
>> +{
>> +if (f) {
>> +while (av_fifo_size(*f)) {
>> +fifo_drain(*f, 1);
>> +}
>> +av_fifo_freep(f);
>> +}
>> +}
>> +
>> /** FrameReciever class - delegate for AVCaptureSession
>> */
>> @interface AVFFrameReceiver : NSObject
>> @@ -225,13 +276,16 @@ static void unlock_frames(AVFContext* ctx)
>>didOutputSampleBuffer:(CMSampleBufferRef)videoFrame
>> fromConnection:(AVCaptureConnection *)connection
>> {
>> +AVFifoBuffer *fifo = _context->video_fifo;
>> +int64_t ts = av_gettime_relative();
>> lock_frames(_context);
>>
>> -if (_context->current_frame != nil) {
>> -CFRelease(_context->current_frame);
>> +if (av_fifo_space(fifo) == 0) {
>> +av_log(_context, AV_LOG_DEBUG, "video fifo is full, the oldest
>> frame has been dropped\n");
>> +fifo_drain(fifo, 1);
>> }
>>
>> -_context->current_frame = (CMSampleBufferRef)CFRetain(videoFrame);
>> +fifo_write(fifo, ts, videoFrame);
>>
>> unlock_frames(_context);
>>
>> @@ -269,13 +323,16 @@ static void unlock_frames(AVFContext* ctx)
>>didOutputSampleBuffer:(CMSampleBufferRef)audioFrame
>> fromConnection:(AVCaptureConnection *)connection
>> {
>> +AVFifoBuffer *fifo = _context->audio_fifo;
>> +int64_t ts = av_gettime_relative();
>> lock_frames(_context);
>>
>> -if (_context->current_audio_frame != nil) {
>> -CFRelease(_context->current_audio_frame);
>> +if (!av_fifo_space(fifo)) {
>> +av_log(_context, AV_LOG_DEBUG, "audio fifo is full, the oldest
>> frame has been dropped\n");
>> +fifo_drain(fifo, 1);
>> }
>>
>> -
Re: [FFmpeg-devel] [REMINDER] FFmpeg dev meeting
On Sat, Mar 13, 2021 at 04:08:25PM +0100, Paul B Mahol wrote: > On Sat, Mar 13, 2021 at 9:10 AM Jean-Baptiste Kempf wrote: > > > Hello, > > > > Reminder, we're doing an FFmpeg dev meeting this afternoon, Berlin Time. > > On IRC and jitsi. > > > > Currently the topics are: > > > - swscale rewrite iam certainly interrested in being involved in this work. But most (>90%) of the work would have to be done by others. If i had the time i would already have cleaned up swscale. So this is really a "iam interrested in being involved" not a "ill do the work" Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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 1/3] avcodec/avpacket: add av_packet_resize()
On Fri, 12 Mar 2021, James Almer wrote: I get a packet from a demuxer. It contains two independent portions (NALUs, OBUs, etc) i want to separate in order to feed them to something like a multi threaded decoder. And so I create a new reference to it, resulting in two packets pointing to the same data. I shrink one to only contain the first portion, and i add the required byte offset to the data pointer and subtract it to the size field on the second packet so it contains only the second portion. The result if i use av_packet_resize() will be two valid, properly padded packets containing their respective expected data, but if i use av_shrink_packet(), the result will be the packet with the second portion featuring padding bytes worth of data zeroed at the start of its payload. This looks like an unfortunate example, since you are: - adding a reference to the packet, so you don't have to duplicate data - and then want to add zero padding to the partial packet, so you will duplicate data. And I think the padding does not have to be zero for the partial packet. The padding exists AFAIK because something, like an optimized bitstream reader that tries to process several bytes at the same time, may end up reading or writing pass the reported end of the buffer. That means that if reading and it's not all zeroes, it could in theory have unpredictable results. Hence why everything always zeroes the padding, even av_shrink_packet(). And yes, what you describe is what some bitstream filters and the matroska demuxer do. They just create several packet references pointing to the same data buffer, but using different offsets for the data pointer. They all have "padding", but in many cases said padding is the beginning of the payload of another packet, and that's not ideal. Well, performance reasons come in play and the ability to not copy the data. Yeah, it does not play nicely with our historical requirement of zero padding. I did a little experimenting, and except for subtitles (which have crashed and burned because of the missing 0 string terminator), most tests handled non-zero padding well, a few failed tests, mostly for partial source files, for which I guess it is inevitable? So I guess for now we will stay in the gray area of "if it does not crash, then having non-zero padding for some partial packets is OKish"... I agree that it is not nice that av_shrink_packet() writes something to the packet, people may not think about it and misuse it instead of directly decreaseing pkt->size when they need a partial packet. That is why I suggested the assert(). One might argue that it kind of breaks behaviour, but I'd say it does not break it too much, and writing to a non-writable packet was broken in the first place. Alternatively we can change av_shrink_packet() to only zero the padding if the packet is writable, which has the benefit that it will do what people generally expect, no matter if you throw a writable or a non-writable packet to it. A third alternative is to introduce void av_shrink_packet2() in which you explicitly document that a writable packet is needed and do the assert there, and deprecate av_shrink_packet(). Not a fan of functions with a 2 suffix. And to be honest, I really don't care about what we do with av_shrink_packet(). Do you want to keep it around? Ok. Want to deprecate and remove it? Better. Want to add an assert to it? Not a fan and it may result in unexpected crashes for library users, but whatever. I just want to add av_packet_resize() to have a single resize function that will properly handle AVPackets in their current and any potential future states. Ok, then I suggest you add av_resize_packet but keep av_shrink_packet() as well, and we can add an assert() to it after the release/bump. Regards, Marton ___ 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 7/7] avformat: add Changelog entry for librist and bump minor
On Sat, 13 Mar 2021, Paul B Mahol wrote: On Sat, Mar 13, 2021 at 5:56 PM Marton Balint wrote: On Fri, 12 Mar 2021, Paul B Mahol wrote: > On Fri, Mar 12, 2021 at 12:21 AM Marton Balint wrote: > >> >> >> On Sun, 7 Mar 2021, Marton Balint wrote: >> >> > >> > >> > On Sun, 7 Mar 2021, Paul B Mahol wrote: >> > >> >> On Sun, Mar 7, 2021 at 9:02 AM Marton Balint wrote: >> >> >> >>> >> >>> >> >>> On Sun, 7 Mar 2021, Paul B Mahol wrote: >> >>> >> >>> > On Sun, Mar 7, 2021 at 1:57 AM James Almer >> wrote: >> >>> > >> >>> >> On 3/6/2021 9:51 PM, Paul B Mahol wrote: >> >>> >> > On Sun, Mar 7, 2021 at 1:35 AM Marton Balint >> wrote: >> >>> >> > >> >>> >> >> >> >>> >> >> >> >>> >> >> On Sun, 7 Mar 2021, Paul B Mahol wrote: >> >>> >> >> >> >>> >> >>> How you tested this? >> >>> >> >> >> >>> >> >> with the librist tools. >> >>> >> >> >> >>> >> >>> >> >>> >> >>> And why you have not asked nicely before taking working on this? >> >>> >> >> >> >>> >> >> You wrote you have given up. It is your behaviour which is not >> very >> >>> >> nice. >> >>> >> >> After your continuous ignorance of my requests, I try to help >> your >> >>> work >> >>> >> >> get merged, and this is your feedback... >> >>> >> >> >> >>> >> > >> >>> >> > >> >>> >> > Why are you so aggressive? Other devs raised issues that looks not >> >>> >> resolved. >> >>> >> >> >>> >> I don't see aggressiveness from his part. I see you making things >> >>> >> incredibly more complex than they should be. >> >>> >> >> >>> > >> >>> > The code in functional part is not much different from initial >> versions. >> >>> > >> >>> > So I really doubt that fifo filling up issue have been properly >> >>> addressed. >> >>> >> >>> I can take a look at that if you provide command lines to reproduce. >> >>> >> >> >> >> I couldn't reproduce it, so you have to ask others. >> > >> > I found one issue in librist code which can be related and might cause >> > ffmpeg not to recover from a fifo fillup. I have reported it here: >> > >> > https://code.videolan.org/rist/librist/-/issues/93 >> >> I'd love to see rist support in 4.4, so maybe we should apply this series >> as is and fix any remaining issues later... >> > > > Not gonna block it. OK, will apply. IIRC librist have not released new release yet, and configure check does not check for new functions that are required for building. They are still at 0.2 RC something and we require 0.2. I thought that means the stable 0.2 release, so we are good. But yes, if somebody uses an earlier RC from git, it might not work correctly. Is that something we should fix? I am not sure. Regards, Marton ___ 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 7/7] avformat: add Changelog entry for librist and bump minor
On Sat, Mar 13, 2021 at 5:56 PM Marton Balint wrote: > > > On Fri, 12 Mar 2021, Paul B Mahol wrote: > > > On Fri, Mar 12, 2021 at 12:21 AM Marton Balint wrote: > > > >> > >> > >> On Sun, 7 Mar 2021, Marton Balint wrote: > >> > >> > > >> > > >> > On Sun, 7 Mar 2021, Paul B Mahol wrote: > >> > > >> >> On Sun, Mar 7, 2021 at 9:02 AM Marton Balint wrote: > >> >> > >> >>> > >> >>> > >> >>> On Sun, 7 Mar 2021, Paul B Mahol wrote: > >> >>> > >> >>> > On Sun, Mar 7, 2021 at 1:57 AM James Almer > >> wrote: > >> >>> > > >> >>> >> On 3/6/2021 9:51 PM, Paul B Mahol wrote: > >> >>> >> > On Sun, Mar 7, 2021 at 1:35 AM Marton Balint > >> wrote: > >> >>> >> > > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> On Sun, 7 Mar 2021, Paul B Mahol wrote: > >> >>> >> >> > >> >>> >> >>> How you tested this? > >> >>> >> >> > >> >>> >> >> with the librist tools. > >> >>> >> >> > >> >>> >> >>> > >> >>> >> >>> And why you have not asked nicely before taking working on > this? > >> >>> >> >> > >> >>> >> >> You wrote you have given up. It is your behaviour which is not > >> very > >> >>> >> nice. > >> >>> >> >> After your continuous ignorance of my requests, I try to help > >> your > >> >>> work > >> >>> >> >> get merged, and this is your feedback... > >> >>> >> >> > >> >>> >> > > >> >>> >> > > >> >>> >> > Why are you so aggressive? Other devs raised issues that looks > not > >> >>> >> resolved. > >> >>> >> > >> >>> >> I don't see aggressiveness from his part. I see you making things > >> >>> >> incredibly more complex than they should be. > >> >>> >> > >> >>> > > >> >>> > The code in functional part is not much different from initial > >> versions. > >> >>> > > >> >>> > So I really doubt that fifo filling up issue have been properly > >> >>> addressed. > >> >>> > >> >>> I can take a look at that if you provide command lines to reproduce. > >> >>> > >> >> > >> >> I couldn't reproduce it, so you have to ask others. > >> > > >> > I found one issue in librist code which can be related and might cause > >> > ffmpeg not to recover from a fifo fillup. I have reported it here: > >> > > >> > https://code.videolan.org/rist/librist/-/issues/93 > >> > >> I'd love to see rist support in 4.4, so maybe we should apply this > series > >> as is and fix any remaining issues later... > >> > > > > > > Not gonna block it. > > OK, will apply. > IIRC librist have not released new release yet, and configure check does not check for new functions that are required for building. > > Thanks, > Marton > ___ > 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] [WANTED] Fix incorrect audio duration reporting
On Sat, Mar 13, 2021 at 04:04:32PM +0100, Paul B Mahol wrote: > On Sat, Mar 13, 2021 at 3:48 PM Michael Niedermayer > wrote: > > > On Sat, Mar 13, 2021 at 03:11:34PM +0100, Paul B Mahol wrote: > > > On Sat, Mar 13, 2021 at 1:30 PM Michael Niedermayer > > > > > wrote: > > > > > > > On Thu, Mar 11, 2021 at 07:33:53PM +0100, Paul B Mahol wrote: > > > > > Hi, > > > > > > > > > > With latest master and with any audio only file, using "ffmpeg -i > > file -f > > > > > null -" reports incorrect duration. > > > > > > > > ./ffmpeg -i ~/videos/1sec-zero.mp3 -f null - > > > > shows durations at 2 points in the output > > > > Duration: 00:00:01.03, start: 0.023021, bitrate: 129 kb/s > > > > size=N/A time=00:00:00.98 bitrate=N/A speed= 620x > > > > > > > > the first is exactly the same in ffmpeg 4.3, 3.4 and 2.8.17 > > > > The 2nd is a regression since 50b49f833ae2f7d33bd2a99776fed6cb692c171a > > > > > > > > > > Check it with wav files. > > > > No difference between master and 4.3 or 3.4 > > ./ffmpeg -i ~/videos/1sec-zero.wav -f null - > > Duration: 00:00:01.01, bitrate: 1536 kb/s > > size=N/A time=00:00:01.00 bitrate=N/A speed=1.02e+03x > > > > Duration: 00:00:01.01, bitrate: 1536 kb/s > > size=N/A time=00:00:01.00 bitrate=N/A speed= 993x > > > > Now try with filtering, loudnorm or dynaudnorm, there is even bigger > difference. ./ffmpeg -i ~/videos/1sec-zero.wav -af loudnorm -f null - size=N/A time=00:00:01.00 bitrate=N/A speed=61.9x vs. size=N/A time=00:00:00.00 bitrate=N/A speed= 0x yes that seems caused by the first hunk of 50b49f833ae2f7d33bd2a99776fed6cb692c171a so ccing the author as this would otherwise be likely missed Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle 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 7/7] avformat: add Changelog entry for librist and bump minor
On Fri, 12 Mar 2021, Paul B Mahol wrote: On Fri, Mar 12, 2021 at 12:21 AM Marton Balint wrote: On Sun, 7 Mar 2021, Marton Balint wrote: > > > On Sun, 7 Mar 2021, Paul B Mahol wrote: > >> On Sun, Mar 7, 2021 at 9:02 AM Marton Balint wrote: >> >>> >>> >>> On Sun, 7 Mar 2021, Paul B Mahol wrote: >>> >>> > On Sun, Mar 7, 2021 at 1:57 AM James Almer wrote: >>> > >>> >> On 3/6/2021 9:51 PM, Paul B Mahol wrote: >>> >> > On Sun, Mar 7, 2021 at 1:35 AM Marton Balint wrote: >>> >> > >>> >> >> >>> >> >> >>> >> >> On Sun, 7 Mar 2021, Paul B Mahol wrote: >>> >> >> >>> >> >>> How you tested this? >>> >> >> >>> >> >> with the librist tools. >>> >> >> >>> >> >>> >>> >> >>> And why you have not asked nicely before taking working on this? >>> >> >> >>> >> >> You wrote you have given up. It is your behaviour which is not very >>> >> nice. >>> >> >> After your continuous ignorance of my requests, I try to help your >>> work >>> >> >> get merged, and this is your feedback... >>> >> >> >>> >> > >>> >> > >>> >> > Why are you so aggressive? Other devs raised issues that looks not >>> >> resolved. >>> >> >>> >> I don't see aggressiveness from his part. I see you making things >>> >> incredibly more complex than they should be. >>> >> >>> > >>> > The code in functional part is not much different from initial versions. >>> > >>> > So I really doubt that fifo filling up issue have been properly >>> addressed. >>> >>> I can take a look at that if you provide command lines to reproduce. >>> >> >> I couldn't reproduce it, so you have to ask others. > > I found one issue in librist code which can be related and might cause > ffmpeg not to recover from a fifo fillup. I have reported it here: > > https://code.videolan.org/rist/librist/-/issues/93 I'd love to see rist support in 4.4, so maybe we should apply this series as is and fix any remaining issues later... Not gonna block it. OK, will apply. Thanks, Marton ___ 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/dv_profile: dv files with wrong dsf flag - detect via buf_size
On Sat, 16 Jan 2021, Mark Plomer wrote: Trying to fix https://trac.ffmpeg.org/ticket/8333 Some of my old DV AVI files have the DSF-Flag of frames set to 0, although it is PAL (I think they were rendered with Ulead Media Studio Pro) ... this causes ffmpeg/VLC-player to produce/play corrupted video. In other players/editors it works fine including: - VirtualDub - Windows Media Player - AVCutty - Ulead Media Studio Pro (very old) I had a look at VirtualDub ... there the PAL/NTSC detection is based on the frame rate from AVISTREAMINFO header (dwRate/dwScale) - see https://github.com/Pavuucek/VirtualDub/blob/f47ebd2536f0034b048180d0b9cb9bde0ab10c73/src/VirtualDub/source/VideoSource.cpp#L1211 As I don't know, how to access the AVI header info inside dvvideo_decode_frame()/ff_dv_frame_profile(), I tried another workaround by checking the buf_size against the dv_profile. It works fine now, but I don't know, if this is really the best solution ... --- a/libavcodec/dv_profile.c +++ b/libavcodec/dv_profile.c @@ -281,6 +281,10 @@ const AVDVProfile* ff_dv_frame_profile(AVCodecContext* codec, const AVDVProfile && codec->coded_height==576) return _profiles[1]; +/* hack for trac issue #8333, dv files with wrong dsf flag - detect via buf_size */ +if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size == dv_profiles[1].frame_size) +return _profiles[1]; + If possible, then it is probably better to move this fallback to later in the code, right after the hack for trac issue #217, so previous hacks won't get broken... Regards, Marton ___ 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] avutil/common: Add FFINCREASE_PTR()
On Sat, Mar 13, 2021 at 04:41:39PM +0100, Lynne wrote:
> Mar 13, 2021, 16:18 by mich...@niedermayer.cc:
>
> > On Fri, Feb 19, 2021 at 10:00:39PM +0100, Andreas Rheinhardt wrote:
> >
> >> Michael Niedermayer:
> >> > Suggested-by: Andreas Rheinhardt
> >> > Signed-off-by: Michael Niedermayer
> >> > ---
> >> > doc/APIchanges | 3 +++
> >> > libavutil/common.h | 2 ++
> >> > 2 files changed, 5 insertions(+)
> >> >
> >> > diff --git a/doc/APIchanges b/doc/APIchanges
> >> > index c353d2d281..e38a5cb91c 100644
> >> > --- a/doc/APIchanges
> >> > +++ b/doc/APIchanges
> >> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >> >
> >> > API changes, most recent first:
> >> >
> >> > +2021-02-xx - xx - lavu 57.xx.100 - common.h
> >> > + Add FFINCREASE_PTR()
> >> > +
> >> > 2021-02-14 - xx - lavd 58.12.100 - avdevice.h
> >> >Deprecated avdevice_capabilities_create() and
> >> >avdevice_capabilities_free().
> >> > diff --git a/libavutil/common.h b/libavutil/common.h
> >> > index aee353d399..bf35bc8507 100644
> >> > --- a/libavutil/common.h
> >> > +++ b/libavutil/common.h
> >> > @@ -108,6 +108,8 @@
> >> > #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a=
> >> > SWAP_tmp;}while(0)
> >> > #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
> >> >
> >> > +#define FFINCREASE_PTR(ptr, off) ((off) ? (ptr) + (off) : (ptr))
> >> > +
> >> > /* misc math functions */
> >> >
> >> > #ifdef HAVE_AV_CONFIG_H
> >> >
> >> If this is intended to be a public macro, it should have a proper AV
> >> prefix.
> >>
> >
> > will apply with AV prefix
> >
>
> Could we not make it public? Macros like FF_ARRAY_ELEMS aren't,
> and I think this is one of those utility functions that API users probably
> won't find useful.
> Plus the name is kinda long.
sure, what do others prefer, iam fine with either
thx
[...]
--
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".
Re: [FFmpeg-devel] [PATCH 1/2] avutil/common: Add FFINCREASE_PTR()
Mar 13, 2021, 16:18 by mich...@niedermayer.cc:
> On Fri, Feb 19, 2021 at 10:00:39PM +0100, Andreas Rheinhardt wrote:
>
>> Michael Niedermayer:
>> > Suggested-by: Andreas Rheinhardt
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > doc/APIchanges | 3 +++
>> > libavutil/common.h | 2 ++
>> > 2 files changed, 5 insertions(+)
>> >
>> > diff --git a/doc/APIchanges b/doc/APIchanges
>> > index c353d2d281..e38a5cb91c 100644
>> > --- a/doc/APIchanges
>> > +++ b/doc/APIchanges
>> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>> >
>> > API changes, most recent first:
>> >
>> > +2021-02-xx - xx - lavu 57.xx.100 - common.h
>> > + Add FFINCREASE_PTR()
>> > +
>> > 2021-02-14 - xx - lavd 58.12.100 - avdevice.h
>> >Deprecated avdevice_capabilities_create() and
>> >avdevice_capabilities_free().
>> > diff --git a/libavutil/common.h b/libavutil/common.h
>> > index aee353d399..bf35bc8507 100644
>> > --- a/libavutil/common.h
>> > +++ b/libavutil/common.h
>> > @@ -108,6 +108,8 @@
>> > #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
>> > #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
>> >
>> > +#define FFINCREASE_PTR(ptr, off) ((off) ? (ptr) + (off) : (ptr))
>> > +
>> > /* misc math functions */
>> >
>> > #ifdef HAVE_AV_CONFIG_H
>> >
>> If this is intended to be a public macro, it should have a proper AV prefix.
>>
>
> will apply with AV prefix
>
Could we not make it public? Macros like FF_ARRAY_ELEMS aren't,
and I think this is one of those utility functions that API users probably
won't find useful.
Plus the name is kinda long.
___
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 8/8] avcodec/exr: Check col/line for integer overflow
On Mon, Feb 01, 2021 at 11:31:16PM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: -2272 + -2147483360 cannot be represented in > type 'int' > Fixes: > 30009/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5005660322398208 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/exr.c | 5 + > 1 file changed, 5 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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 1/5] avformat/sbgdec: Use av_sat_add64() in str_to_time()
On Sun, Jan 31, 2021 at 10:56:01PM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: 727999279212000 + 4611686018427387904 > cannot be represented in type 'long long' > Fixes: > 29744/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-6434060249464832 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/sbgdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/flacdec: Avoid undefined shift in error case
On Tue, Mar 09, 2021 at 09:04:45PM +0100, Michael Niedermayer wrote: > Fixes: flac_1040988 > > Reported-by: Thomas Guilbert > Signed-off-by: Michael Niedermayer > --- > libavcodec/flacdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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 2/2] avfilter/vf_scale: Fix adding 0 to NULL (which is UB) in scale_slice()
On Fri, Feb 19, 2021 at 09:43:45PM +0100, Michael Niedermayer wrote: > Found-by: Jeremy Leconte > Signed-off-by: Michael Niedermayer > --- > libavfilter/vf_scale.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 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 1/2] avutil/common: Add FFINCREASE_PTR()
On Fri, Feb 19, 2021 at 10:00:39PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Suggested-by: Andreas Rheinhardt
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/APIchanges | 3 +++
> > libavutil/common.h | 2 ++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index c353d2d281..e38a5cb91c 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >
> > API changes, most recent first:
> >
> > +2021-02-xx - xx - lavu 57.xx.100 - common.h
> > + Add FFINCREASE_PTR()
> > +
> > 2021-02-14 - xx - lavd 58.12.100 - avdevice.h
> >Deprecated avdevice_capabilities_create() and
> >avdevice_capabilities_free().
> > diff --git a/libavutil/common.h b/libavutil/common.h
> > index aee353d399..bf35bc8507 100644
> > --- a/libavutil/common.h
> > +++ b/libavutil/common.h
> > @@ -108,6 +108,8 @@
> > #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
> > #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
> >
> > +#define FFINCREASE_PTR(ptr, off) ((off) ? (ptr) + (off) : (ptr))
> > +
> > /* misc math functions */
> >
> > #ifdef HAVE_AV_CONFIG_H
> >
> If this is intended to be a public macro, it should have a proper AV prefix.
will apply with AV prefix
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
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] [REMINDER] FFmpeg dev meeting
On Sat, Mar 13, 2021 at 9:10 AM Jean-Baptiste Kempf wrote: > Hello, > > Reminder, we're doing an FFmpeg dev meeting this afternoon, Berlin Time. > On IRC and jitsi. > > Currently the topics are: > - swscale rewrite > - GA update > - TC rules > - hardware > - GSoC > - next major bump > - next release > > Any other topic? Please add to the list. > > Best, > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > 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 1/1] libavformat/hls: Reset options after open_url_keepalive() fails
On 3/10/21 10:16 PM, Steven Liu wrote:
2021年3月11日 上午5:43，li...@edman007.com 写道：
From: Ed Martin
open_url_keepalive() unsets the options when it uses them, this
includes the offsets for the Range: header. When using the HLS
tag #EXT-X-BYTERANGE along with multiple files, the range options
must be preserved after open_url_keepalive() returns EOF so that
the new file can be opened. Failure to do this results in ignoring
the #EXT-X-BYTERANGE tag and reading the wrong bytes of the file.
To fix it, reset the options before calling io_open() following
open_url_keepalive() reaching EOF
---
libavformat/hls.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index af2468ad9b..d08d00cf24 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -677,6 +677,8 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
const char *url,
av_log(s, AV_LOG_WARNING,
"keepalive request failed for '%s' with error: '%s' when
opening url, retrying with new connection\n",
url, av_err2str(ret));
+av_dict_copy(, *opts, 0);
+av_dict_copy(, opts2, 0);
ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
}
} else {
--
2.30.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
LGTM
Thanks
Steven Liu
___
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".
Thanks for the review, if it's all good can someone commit the patch?
___
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] avutils/hwcontext_qsv: set the source device in qsv_device_create
On 11/03/2021 08:53, Xu, Guangxin wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Guangxin Xu
Sent: Friday, March 5, 2021 9:46 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] avutils/hwcontext_qsv: set the source
device in qsv_device_create
On Tue, Feb 23, 2021 at 9:34 AM Guangxin Xu wrote:
On Mon, Feb 22, 2021 at 5:17 PM Soft Works
wrote:
-Original Message-
From: ffmpeg-devel On Behalf
Of
Xu Guangxin
Sent: Monday, February 22, 2021 9:45 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Xu Guangxin
Subject: [FFmpeg-devel] [PATCH] avutils/hwcontext_qsv: set the
source device in qsv_device_create
opencl_device_derive only handles AV_HWDEVICE_TYPE_VAAPI.
We need a source device for qsv.
this will fix following pipeline:
ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128
-init_hw_device opencl=ocl@intel -hwaccel qsv -c:v h264_qsv
-hwaccel_output_format qsv
-i
$input -filter_hw_device ocl -vf
'hwmap=derive_device=opencl,format=opencl,unsharp_opencl,hwmap=der
ive_device=qsv:reverse=1:extra_hw_frames=32' -c:v hevc_qsv -y
test.h265
---
libavutil/hwcontext_qsv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 35a944f8f8..af3ee32cac 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1269,7 +1269,13 @@ static int
qsv_device_create(AVHWDeviceContext
*ctx, const char *device,
impl = choose_implementation(device);
-return qsv_device_derive_from_child(ctx, impl, child_device, 0);
+ret = qsv_device_derive_from_child(ctx, impl, child_device, 0);
+if (ret == 0) {
+ctx->internal->source_device =
av_buffer_ref(priv->child_device_ctx);
+if (!ctx->internal->source_device)
+ret = AVERROR(ENOMEM);
+}
+return ret;
}
That's funny, I made almost the same change only two days ago:
impl = choose_implementation(device);
ret = qsv_device_derive_from_child(ctx, impl, child_device, 0);
if (ret >= 0)
ctx->internal->source_device =
av_buffer_ref(priv->child_device_ctx);
return ret;
From my POV, this change is correct and required.
Glad to hear this. Thanks for the endorsement :)
Hi softworkz,
Could you help merge this?
thanks
Hmm, this patch will failed for "make fate-hwdevice V=2"
It because Qsv's internal->source_device is vaapi.
When we derivation qsv to vaapi, and derivation back again, it will create a
new qsv device.
Hi Mark,
Can we remove this test for qsv and vaapi? Or could you suggest a better way
for me?
https://github.com/FFmpeg/FFmpeg/blob/069d2b4a50a6eb2f925f36884e6b9bd9a1e54670/libavutil/tests/hwdevice.c#L75
thanks
...
Successfully tested derivation vaapi -> qsv.
Test passed for vaapi with device :0.
Device type qsv successfully created.
Derivation qsv to vaapi succeeded, but derivation back again did not return the
original device.
Test failed for qsv with default options.
Attempted to test 2 device types: 1 passed, 1 failed, 0 skipped.
make: *** [tests/Makefile:256: fate-hwdevice] Error 1
You are hacking it to lie to the hwcontext implementation around how the device
was derived, so the test fails because it finds a different derivation
structure to what it created? That seems correct?
Your command-line was:
$ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device
opencl=ocl@intel -hwaccel qsv -c:v h264_qsv -hwaccel_output_format qsv -i
$input -filter_hw_device ocl -vf
'hwmap=derive_device=opencl,format=opencl,unsharp_opencl,hwmap=derive_device=qsv:reverse=1:extra_hw_frames=32'
-c:v hevc_qsv -y test.h265
So that's trying to make five device references in turn:
1. Make a VAAPI device explicitly.
2. Derive an OpenCL device from the VAAPI device 1.
3. Make a libmfx device implicitly (because a libmfx decoder was requested).
4. Derive a new OpenCL device from the libmfx device 3 (you told the filter
graph about device 2, but then didn't use it anywhere).
5. Derive a libmfx device from the OpenCL device 4, which should return libmfx
device 3.
What's going wrong? Step 4 fails to create an OpenCL device because devices
1/2 and device 3 aren't actually connected together at all.
How to solve that? Either we can fix the connection, or we could just use the
device we already have in step 4 rather than trying to create a new one.
To fix the connection, derive device 3 from device 1. This doesn't work in the
ffmpeg utility because the hacky support in ffmpeg_qsv.c doesn't support the
normal device stuff. It would work in your own program.
Using the existing device (by using device 2 rather than deriving a new on at
step 4) looks like it should work:
$ ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device
opencl=ocl@intel -hwaccel qsv -c:v h264_qsv -hwaccel_output_format qsv -i
$input -filter_hw_device ocl -vf
Re: [FFmpeg-devel] [WANTED] Fix incorrect audio duration reporting
On Sat, Mar 13, 2021 at 3:48 PM Michael Niedermayer wrote: > On Sat, Mar 13, 2021 at 03:11:34PM +0100, Paul B Mahol wrote: > > On Sat, Mar 13, 2021 at 1:30 PM Michael Niedermayer > > > wrote: > > > > > On Thu, Mar 11, 2021 at 07:33:53PM +0100, Paul B Mahol wrote: > > > > Hi, > > > > > > > > With latest master and with any audio only file, using "ffmpeg -i > file -f > > > > null -" reports incorrect duration. > > > > > > ./ffmpeg -i ~/videos/1sec-zero.mp3 -f null - > > > shows durations at 2 points in the output > > > Duration: 00:00:01.03, start: 0.023021, bitrate: 129 kb/s > > > size=N/A time=00:00:00.98 bitrate=N/A speed= 620x > > > > > > the first is exactly the same in ffmpeg 4.3, 3.4 and 2.8.17 > > > The 2nd is a regression since 50b49f833ae2f7d33bd2a99776fed6cb692c171a > > > > > > > Check it with wav files. > > No difference between master and 4.3 or 3.4 > ./ffmpeg -i ~/videos/1sec-zero.wav -f null - > Duration: 00:00:01.01, bitrate: 1536 kb/s > size=N/A time=00:00:01.00 bitrate=N/A speed=1.02e+03x > > Duration: 00:00:01.01, bitrate: 1536 kb/s > size=N/A time=00:00:01.00 bitrate=N/A speed= 993x > Now try with filtering, loudnorm or dynaudnorm, there is even bigger difference. > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Never trust a computer, one day, it may think you are the virus. -- Compn > ___ > 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] [WANTED] Fix incorrect audio duration reporting
On Sat, Mar 13, 2021 at 03:11:34PM +0100, Paul B Mahol wrote: > On Sat, Mar 13, 2021 at 1:30 PM Michael Niedermayer > wrote: > > > On Thu, Mar 11, 2021 at 07:33:53PM +0100, Paul B Mahol wrote: > > > Hi, > > > > > > With latest master and with any audio only file, using "ffmpeg -i file -f > > > null -" reports incorrect duration. > > > > ./ffmpeg -i ~/videos/1sec-zero.mp3 -f null - > > shows durations at 2 points in the output > > Duration: 00:00:01.03, start: 0.023021, bitrate: 129 kb/s > > size=N/A time=00:00:00.98 bitrate=N/A speed= 620x > > > > the first is exactly the same in ffmpeg 4.3, 3.4 and 2.8.17 > > The 2nd is a regression since 50b49f833ae2f7d33bd2a99776fed6cb692c171a > > > > Check it with wav files. No difference between master and 4.3 or 3.4 ./ffmpeg -i ~/videos/1sec-zero.wav -f null - Duration: 00:00:01.01, bitrate: 1536 kb/s size=N/A time=00:00:01.00 bitrate=N/A speed=1.02e+03x Duration: 00:00:01.01, bitrate: 1536 kb/s size=N/A time=00:00:01.00 bitrate=N/A speed= 993x [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn 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] libavutil/timer: Fix clang reserved-user-defined-literal
On 3/13/2021 5:11 AM, Christopher Degawa wrote: On Sat, Mar 13, 2021 at 01:09 Chris Degawa wrote: On Mar 13, 2021, at 00:57, Anton Khirnov wrote: Quoting Christopher Degawa (2021-03-13 05:20:37) clang errors when compiling with C++11 about needing spaces between literal and identifier Why would you compile it with C++11? It's a private header, is it not? The error occurred when compiling decklink_dec.cpp Yeah, starting with 9e2e6f935bed329a7c2eabae7de02cccd88e2f26 decklink_dec.cpp includes libavutil/internal.h Will apply, thanks. ___ 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] RFC ffmpeg: exit demuxers earlier after signal received
On Sun, 07. Feb 15:04, Andriy Gelman wrote:
> On Sat, 28. Nov 14:46, Andriy Gelman wrote:
> > From: Andriy Gelman
> >
> > We currently use the same interrupt_callback function for both muxers
> > and demuxers to break out of potential infinite loops.
> >
> > The function decode_interrupt_cb() checks for how many SIGINT/SIGTERM
> > interrupts have been received, and (usually) two interrupts are needed to
> > break out of an infinite loop.
> >
> > If this condition is seen on the muxer, however, we will fail to flush the
> > avio buffers (see retry_transfer_wrapper()).
> > An example of this issue is seen in Ticket #9009 (which would be fixed
> > by this patch).
> >
> > A more robust alternative maybe to break out of demuxers with one
> > interrupt. The error should propagate through, close the muxers and
> > allow them to flush properly.
> > (If the infinite loop is present on the muxer then a second interrupt would
> > cause it break out and have the same behavior as before.)
> >
> > This patch adds this behavior. I've labelled it RFC because it
> > potentially touches many demuxers.
> > ---
> > fftools/ffmpeg.c | 6 ++
> > fftools/ffmpeg.h | 1 +
> > fftools/ffmpeg_opt.c | 2 +-
> > 3 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 01f4ef15d8..bb27eec879 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -510,7 +510,13 @@ static int decode_interrupt_cb(void *ctx)
> > return received_nb_signals > atomic_load(_init_done);
> > }
> >
> > +static int decode_interrupt_one_sig_cb(void *ctx)
> > +{
> > +return received_nb_signals > 0;
> > +}
> > +
> > const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL };
> > +const AVIOInterruptCB int_one_sig_cb = { decode_interrupt_one_sig_cb, NULL
> > };
> >
> > static void ffmpeg_cleanup(int ret)
> > {
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index 3b54dab7fc..c49af30009 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -627,6 +627,7 @@ extern int vstats_version;
> > extern int auto_conversion_filters;
> >
> > extern const AVIOInterruptCB int_cb;
> > +extern const AVIOInterruptCB int_one_sig_cb;
> >
> > extern const OptionDef options[];
> > extern const HWAccel hwaccels[];
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index 7ee034c9c9..2908f23010 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -1156,7 +1156,7 @@ static int open_input_file(OptionsContext *o, const
> > char *filename)
> > ic->flags |= AVFMT_FLAG_NONBLOCK;
> > if (o->bitexact)
> > ic->flags |= AVFMT_FLAG_BITEXACT;
> > -ic->interrupt_callback = int_cb;
> > +ic->interrupt_callback = int_one_sig_cb;
> >
> > if (!av_dict_get(o->g->format_opts, "scan_all_pmts", NULL,
> > AV_DICT_MATCH_CASE)) {
> > av_dict_set(>g->format_opts, "scan_all_pmts", "1",
> > AV_DICT_DONT_OVERWRITE);
> > --
> > 2.28.0
> >
>
> ping
>
ping
--
Andriy
___
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] [WANTED] Fix incorrect audio duration reporting
On Sat, Mar 13, 2021 at 1:30 PM Michael Niedermayer wrote: > On Thu, Mar 11, 2021 at 07:33:53PM +0100, Paul B Mahol wrote: > > Hi, > > > > With latest master and with any audio only file, using "ffmpeg -i file -f > > null -" reports incorrect duration. > > ./ffmpeg -i ~/videos/1sec-zero.mp3 -f null - > shows durations at 2 points in the output > Duration: 00:00:01.03, start: 0.023021, bitrate: 129 kb/s > size=N/A time=00:00:00.98 bitrate=N/A speed= 620x > > the first is exactly the same in ffmpeg 4.3, 3.4 and 2.8.17 > The 2nd is a regression since 50b49f833ae2f7d33bd2a99776fed6cb692c171a > Check it with wav files. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have often repented speaking, but never of holding my tongue. > -- Xenocrates > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec: add a mention about get_encode_buffer in the old encode API doxy
Direct users to the callback that should be used to keep supporting user provided buffers with the new encode API. Signed-off-by: James Almer --- libavcodec/avcodec.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index fbd4804160..8a71c04230 100644 --- a/libavcodec/avcodec.h +++ b/libavcodec/avcodec.h @@ -3680,7 +3680,9 @@ void av_parser_close(AVCodecParserContext *s); *not be used. * @return 0 on success, negative error code on failure * - * @deprecated use avcodec_send_frame()/avcodec_receive_packet() instead + * @deprecated use avcodec_send_frame()/avcodec_receive_packet() instead. + * If allowed and required, set AVCodecContext.get_encode_buffer to + * a custom function to pass user supplied output buffers. */ attribute_deprecated int avcodec_encode_audio2(AVCodecContext *avctx, AVPacket *avpkt, @@ -3719,7 +3721,9 @@ int avcodec_encode_audio2(AVCodecContext *avctx, AVPacket *avpkt, *not be used. * @return 0 on success, negative error code on failure * - * @deprecated use avcodec_send_frame()/avcodec_receive_packet() instead + * @deprecated use avcodec_send_frame()/avcodec_receive_packet() instead. + * If allowed and required, set AVCodecContext.get_encode_buffer to + * a custom function to pass user supplied output buffers. */ attribute_deprecated int avcodec_encode_video2(AVCodecContext *avctx, AVPacket *avpkt, -- 2.30.2 ___ 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] [WANTED] Fix incorrect audio duration reporting
On Thu, Mar 11, 2021 at 07:33:53PM +0100, Paul B Mahol wrote: > Hi, > > With latest master and with any audio only file, using "ffmpeg -i file -f > null -" reports incorrect duration. ./ffmpeg -i ~/videos/1sec-zero.mp3 -f null - shows durations at 2 points in the output Duration: 00:00:01.03, start: 0.023021, bitrate: 129 kb/s size=N/A time=00:00:00.98 bitrate=N/A speed= 620x the first is exactly the same in ffmpeg 4.3, 3.4 and 2.8.17 The 2nd is a regression since 50b49f833ae2f7d33bd2a99776fed6cb692c171a [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates 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] FFmpeg 4.4
On Sat, Mar 13, 2021 at 12:29 PM Michael Niedermayer wrote: > On Wed, Mar 10, 2021 at 10:06:49AM -0300, James Almer wrote: > > On 3/10/2021 7:37 AM, Michael Niedermayer wrote: > > > On Tue, Mar 09, 2021 at 05:55:55PM -0300, James Almer wrote: > > > > On 3/9/2021 5:47 PM, Michael Niedermayer wrote: > > > > > Hi all > > > > > > > > > > I will branch release/4.4 soon > > > > > then like always leave some time for testing, bugfixes, ... and > then > > > > > make FFmeg 4.4 from release/4.4, its too long since 4.3 > > > > > > > > > > Thanks > > > > > > > > I have three API changes/additions/deprecations on the ml, some for > months > > > > now, that i want in 4.4 in order for them to be present in the last > release > > > > using the current major library versions. This is so users have a > good > > > > amount of time to notice them and adapt their code. > > > > It's not be as nice if they start noticing any new deprecations > introduced > > > > today in a release made several months from now. > > > > > > > > These are "deprecate av_init_packet() and sizeof(AVPacket) as part > of the > > > > ABI", > > It seems this is still missing > > > > > >"avutil/buffer: change public function and struct size parameter types > > > > to size_t", and > > I see several 4 "size parameter type to size_t" commits in git now so these > seem applied > > > > > > "avcodec: add a get_encoder_buffer() callback to > > > > AVCodecContext". > > This was applied as 6e7e3a3820f0888ff92d6be44f40ff733bcce874 > > So it seems only one blocker is left for making the release branch > > If thats incorrect someone please correct me! > > thx > There is also one major blocker that is left: incorrect reporting of audio duration when demuxing/decoding. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > In fact, the RIAA has been known to suggest that students drop out > of college or go to community college in order to be able to afford > settlements. -- The RIAA > ___ > 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] FFmpeg 4.4
On Wed, Mar 10, 2021 at 10:06:49AM -0300, James Almer wrote: > On 3/10/2021 7:37 AM, Michael Niedermayer wrote: > > On Tue, Mar 09, 2021 at 05:55:55PM -0300, James Almer wrote: > > > On 3/9/2021 5:47 PM, Michael Niedermayer wrote: > > > > Hi all > > > > > > > > I will branch release/4.4 soon > > > > then like always leave some time for testing, bugfixes, ... and then > > > > make FFmeg 4.4 from release/4.4, its too long since 4.3 > > > > > > > > Thanks > > > > > > I have three API changes/additions/deprecations on the ml, some for months > > > now, that i want in 4.4 in order for them to be present in the last > > > release > > > using the current major library versions. This is so users have a good > > > amount of time to notice them and adapt their code. > > > It's not be as nice if they start noticing any new deprecations introduced > > > today in a release made several months from now. > > > > > > These are "deprecate av_init_packet() and sizeof(AVPacket) as part of the > > > ABI", It seems this is still missing > > >"avutil/buffer: change public function and struct size parameter types > > > to size_t", and I see several 4 "size parameter type to size_t" commits in git now so these seem applied > > > "avcodec: add a get_encoder_buffer() callback to > > > AVCodecContext". This was applied as 6e7e3a3820f0888ff92d6be44f40ff733bcce874 So it seems only one blocker is left for making the release branch If thats incorrect someone please correct me! thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via buf_size
On Sat, Jan 16, 2021 at 02:40:03PM +0100, Mark Plomer wrote: > Trying to fix https://trac.ffmpeg.org/ticket/8333 > > Some of my old DV AVI files have the DSF-Flag of frames set to 0, although > it is PAL (I think they were rendered with Ulead Media Studio Pro) ... this > causes ffmpeg/VLC-player to produce/play corrupted video. > > In other players/editors it works fine including: > > - VirtualDub > - Windows Media Player > - AVCutty > - Ulead Media Studio Pro (very old) > > I had a look at VirtualDub ... there the PAL/NTSC detection is based on the > frame rate from AVISTREAMINFO header (dwRate/dwScale) - see > https://github.com/Pavuucek/VirtualDub/blob/f47ebd2536f0034b048180d0b9cb9bde0ab10c73/src/VirtualDub/source/VideoSource.cpp#L1211 > > As I don't know, how to access the AVI header info inside > dvvideo_decode_frame()/ff_dv_frame_profile(), I tried another workaround by > checking the buf_size against the dv_profile. > > It works fine now, but I don't know, if this is really the best solution ... > > dv_profile.c |4 > 1 file changed, 4 insertions(+) > 9676b11bedef27c1c2a359c7617ecc6d30044b16 > 0001-avcodec-dv_profile-dv-files-with-wrong-dsf-flag.patch > From 9dd240e6700c28601014e79e55d3ddee5f6b13c7 Mon Sep 17 00:00:00 2001 > From: Mark Plomer > Date: Sat, 16 Jan 2021 14:04:44 +0100 > Subject: [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via > buf_size > > --- The commit message should mention "Fixes Ticket8333" if that is a bugfix for that ticket also maybe some of the other details you write in your mail could be moved into the commit message Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/dv_profile: maintainer of "dvvideo" module?
Hello, is there anyone who maintains the "dvvideo" module, who can review this patch and give me some feedback? Greets Mark Am 16.01.21 um 14:40 schrieb Mark Plomer: Trying to fix https://trac.ffmpeg.org/ticket/8333 Some of my old DV AVI files have the DSF-Flag of frames set to 0, although it is PAL (I think they were rendered with Ulead Media Studio Pro) ... this causes ffmpeg/VLC-player to produce/play corrupted video. In other players/editors it works fine including: - VirtualDub - Windows Media Player - AVCutty - Ulead Media Studio Pro (very old) I had a look at VirtualDub ... there the PAL/NTSC detection is based on the frame rate from AVISTREAMINFO header (dwRate/dwScale) - see https://github.com/Pavuucek/VirtualDub/blob/f47ebd2536f0034b048180d0b9cb9bde0ab10c73/src/VirtualDub/source/VideoSource.cpp#L1211 As I don't know, how to access the AVI header info inside dvvideo_decode_frame()/ff_dv_frame_profile(), I tried another workaround by checking the buf_size against the dv_profile. It works fine now, but I don't know, if this is really the best solution ... ___ 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] libavutil/timer: Fix clang reserved-user-defined-literal
On Sat, Mar 13, 2021 at 01:09 Chris Degawa wrote: > > > > On Mar 13, 2021, at 00:57, Anton Khirnov wrote: > > > > Quoting Christopher Degawa (2021-03-13 05:20:37) > >> clang errors when compiling with C++11 about needing spaces between > >> literal and identifier > > > > Why would you compile it with C++11? It's a private header, is it not? The error occurred when compiling decklink_dec.cpp > Since I realized my email did not send out based on looking at the ml archive, resending using the right email ___ 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] [REMINDER] FFmpeg dev meeting
Hello, Reminder, we're doing an FFmpeg dev meeting this afternoon, Berlin Time. On IRC and jitsi. Currently the topics are: - GA update - TC rules - hardware - GSoC - next major bump - next release Any other topic? Please add to the list. Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
