Re: [FFmpeg-devel] [PATCH] avcodec/libdav1d: fix setting AVFrame reordered_opaque
On 2019-10-18 02:16, James Almer wrote:
On 10/17/2019 7:46 PM, Andrey Semashev wrote:
On 2019-10-18 01:28, James Almer wrote:
On 10/17/2019 7:13 PM, Andrey Semashev wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 8aa248e6cd..87abdb4569 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -191,6 +191,24 @@ static int libdav1d_receive_frame(AVCodecContext
*c, AVFrame *frame)
pkt.buf = NULL;
av_packet_unref(&pkt);
+
+ if (c->reordered_opaque != AV_NOPTS_VALUE) {
I'm not sure this comparison is valid. The default value of
reordered_opaque is 0, and there seems to be no convention whatsoever
about what this value represents (i.e. its semantics are completely
user-defined). I think, this check needs to be removed and the code
below should execute for any reordered_opaque values.
AVCodecContext->reordered_opaque is by default AV_NOPTS_VALUE, as set in
avcodec_alloc_context3(). This field is normally used for timestamps
(despite not being the only use), and 0 is a valid timestamp, so that
can't be considered a "not set" value.
Ok, I see. I was looking at AVFrame initialization, which sets it to 0
by default.
And I'd rather not make this code unconditional. It's an allocation per
frame in a zero copy optimized decoder, and i don't want that overhead
when reordered_opaque is rarely going to be used.
Fwiw, timestamps are properly reordered by libdav1d in this same
function and propagated in the output frame. reordered_opaque is not
really needed for them.
FWIW, I'm the reporter of #8300 and our main reason for using
reordered_opaque instead of pts is that we don't want to mess with
timestamp conversion between our time base and whatever time_base
libavcodec might select for a given codec. So, we use reordered_opaque
universally, and it just happened to break with libdav1d.
Testing for AV_NOPTS_VALUE is ok in our particular case, though I had
the impression that ffmpeg is not supposed to interpret
reordered_opaque, including not assume it contains a timestamp.
Unfortunately you're right, and the check is probably not proper use of
the field, even if valid for pretty much any normal use case for it.
Will remove it, and simply deal with the malloc overhead.
You could avoid malloc completely on 64-bit systems by passing
reordered_opaque inside the pointer to user data. It's not pretty, but
it would get the job done. 32-bit systems would still have to malloc,
unfortunately.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/qsvdec: remove unused check_dec_param
Signed-off-by: Linjie Fu
---
libavcodec/qsvdec.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index ae5023989c..0d34021b42 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -164,33 +164,6 @@ static inline unsigned int qsv_fifo_size(const
AVFifoBuffer* fifo)
return av_fifo_size(fifo) / qsv_fifo_item_size();
}
-static int check_dec_param(AVCodecContext *avctx, QSVContext *q, mfxVideoParam
*param_in)
-{
-mfxVideoParam param_out = { .mfx.CodecId = param_in->mfx.CodecId };
-mfxStatus ret;
-
-#define CHECK_MATCH(x) \
-do { \
- if (param_out.mfx.x != param_in->mfx.x) { \
- av_log(avctx, AV_LOG_WARNING, "Required "#x" %d is unsupported\n", \
- param_in->mfx.x); \
- } \
-} while (0)
-
-ret = MFXVideoDECODE_Query(q->session, param_in, ¶m_out);
-
-if (ret < 0) {
-CHECK_MATCH(CodecId);
-CHECK_MATCH(CodecProfile);
-CHECK_MATCH(CodecLevel);
-CHECK_MATCH(FrameInfo.Width);
-CHECK_MATCH(FrameInfo.Height);
-#undef CHECK_MATCH
-return 0;
-}
-return 1;
-}
-
static int qsv_decode_preinit(AVCodecContext *avctx, QSVContext *q, enum
AVPixelFormat pix_fmt, mfxVideoParam *param)
{
mfxSession session = NULL;
--
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] lavc/qsvenc: Fix bitrate_limit to allow AVC encode in limited bitrate
> -Original Message- > From: Fu, Linjie > Sent: Tuesday, October 15, 2019 15:56 > To: ffmpeg-devel@ffmpeg.org > Cc: Fu, Linjie > Subject: [PATCH] lavc/qsvenc: Fix bitrate_limit to allow AVC encode in limited > bitrate > > MFXVideoENCODE_Query calls CheckVideoParamQueryLike in MSDK and > will determine whether to set param.mfx.TargetKbps to the allowed > minTargetKbps according to the bitrate_limit in extco2 buffer. > > Thus q->param.ExtParam must be set before MFXVideoENCODE_Query in > case > minTargetKbps is written to TargetKbps by default. > > 1080P AVC encoding with option "-bitrate_limit 0 -b:v 100k": > Before patch: > 902 kbps > After patch: > 156 kbps > Signed-off-by: Linjie Fu > --- > libavcodec/qsvenc.c | 38 +++--- > 1 file changed, 19 insertions(+), 19 deletions(-) Ping. This is reported by Mann, J in: https://software.intel.com/en-us/forums/intel-media-sdk/topic/815938 - linjie ___ 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] avcodec/libdav1d: fix setting AVFrame reordered_opaque
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
Updated to avoid extra memory allocations on 64-bit platforms.
Signed-off-by: Andrey Semashev
---
libavcodec/libdav1d.c | 46 ++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 8aa248e6cd..ff94310b40 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -19,12 +19,14 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include
#include
#include "libavutil/avassert.h"
#include "libavutil/mastering_display_metadata.h"
#include "libavutil/imgutils.h"
#include "libavutil/opt.h"
+#include "libavutil/mem.h"
#include "avcodec.h"
#include "decode.h"
@@ -164,6 +166,12 @@ static void libdav1d_data_free(const uint8_t *data, void
*opaque) {
av_buffer_unref(&buf);
}
+static void libdav1d_user_data_free(const uint8_t *data, void *opaque) {
+#if UINTPTR_MAX < UINT64_MAX
+av_free((void *)data);
+#endif
+}
+
static int libdav1d_receive_frame(AVCodecContext *c, AVFrame *frame)
{
Libdav1dContext *dav1d = c->priv_data;
@@ -191,6 +199,35 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
pkt.buf = NULL;
av_packet_unref(&pkt);
+
+#if UINTPTR_MAX >= UINT64_MAX
+if (c->reordered_opaque != (int64_t)(intptr_t)(const uint8_t
*)NULL) {
+res = dav1d_data_wrap_user_data(data, (const uint8_t
*)(intptr_t)c->reordered_opaque,
+libdav1d_user_data_free, NULL);
+if (res < 0) {
+dav1d_data_unref(data);
+return res;
+}
+}
+#else
+if (c->reordered_opaque != AV_NOPTS_VALUE) {
+int64_t *reordered_opaque = av_malloc(sizeof(int64_t));
+
+if (!reordered_opaque) {
+dav1d_data_unref(data);
+return AVERROR(ENOMEM);
+}
+
+*reordered_opaque = c->reordered_opaque;
+res = dav1d_data_wrap_user_data(data, (const uint8_t
*)reordered_opaque,
+libdav1d_user_data_free, NULL);
+if (res < 0) {
+av_free(reordered_opaque);
+dav1d_data_unref(data);
+return res;
+}
+}
+#endif
}
}
@@ -260,7 +297,14 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
else
frame->format = c->pix_fmt = pix_fmt[p->p.layout][p->seq_hdr->hbd];
-frame->reordered_opaque = c->reordered_opaque;
+#if UINTPTR_MAX >= UINT64_MAX
+frame->reordered_opaque = (int64_t)(intptr_t)p->m.user_data.data;
+#else
+if (p->m.user_data.data)
+memcpy(&frame->reordered_opaque, p->m.user_data.data,
sizeof(frame->reordered_opaque));
+else
+frame->reordered_opaque = AV_NOPTS_VALUE;
+#endif
// match timestamps and packet size
frame->pts = frame->best_effort_timestamp = p->m.timestamp;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libdav1d: fix setting AVFrame reordered_opaque
On 2019-10-18 10:01, Andrey Semashev wrote:
On 2019-10-18 02:16, James Almer wrote:
On 10/17/2019 7:46 PM, Andrey Semashev wrote:
On 2019-10-18 01:28, James Almer wrote:
On 10/17/2019 7:13 PM, Andrey Semashev wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 8aa248e6cd..87abdb4569 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -191,6 +191,24 @@ static int libdav1d_receive_frame(AVCodecContext
*c, AVFrame *frame)
pkt.buf = NULL;
av_packet_unref(&pkt);
+
+ if (c->reordered_opaque != AV_NOPTS_VALUE) {
I'm not sure this comparison is valid. The default value of
reordered_opaque is 0, and there seems to be no convention whatsoever
about what this value represents (i.e. its semantics are completely
user-defined). I think, this check needs to be removed and the code
below should execute for any reordered_opaque values.
AVCodecContext->reordered_opaque is by default AV_NOPTS_VALUE, as
set in
avcodec_alloc_context3(). This field is normally used for timestamps
(despite not being the only use), and 0 is a valid timestamp, so that
can't be considered a "not set" value.
Ok, I see. I was looking at AVFrame initialization, which sets it to 0
by default.
And I'd rather not make this code unconditional. It's an allocation per
frame in a zero copy optimized decoder, and i don't want that overhead
when reordered_opaque is rarely going to be used.
Fwiw, timestamps are properly reordered by libdav1d in this same
function and propagated in the output frame. reordered_opaque is not
really needed for them.
FWIW, I'm the reporter of #8300 and our main reason for using
reordered_opaque instead of pts is that we don't want to mess with
timestamp conversion between our time base and whatever time_base
libavcodec might select for a given codec. So, we use reordered_opaque
universally, and it just happened to break with libdav1d.
Testing for AV_NOPTS_VALUE is ok in our particular case, though I had
the impression that ffmpeg is not supposed to interpret
reordered_opaque, including not assume it contains a timestamp.
Unfortunately you're right, and the check is probably not proper use of
the field, even if valid for pretty much any normal use case for it.
Will remove it, and simply deal with the malloc overhead.
You could avoid malloc completely on 64-bit systems by passing
reordered_opaque inside the pointer to user data. It's not pretty, but
it would get the job done. 32-bit systems would still have to malloc,
unfortunately.
I've posted v3 patch with what I had in mind.
___
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] avcodec/libdav1d: fix setting AVFrame reordered_opaque
On Fri, Oct 18, 2019 at 12:22 PM Andrey Semashev wrote: > > Actually reorder the values. > > Should effectively fix ticket #8300. > > Signed-off-by: James Almer > > Updated to avoid extra memory allocations on 64-bit platforms. > Lets not do this, the code for this is really ugly. - Hendrik ___ 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] Bye packets
Hi everyone, I have one question regarding bye packets. Actually I’m creating some project which depends on WIFI RAK5206 electronic board. I’m using ffmpeg library to obtain video and audio stream and I have issue where I can start and stop stream 4 times, but when I want to start 5th I get error Invalid data found when processing input when I call avformat_open_input function and I need to restart the electronic board. I figured out with Wireshark application that VLC is working and it is sending some BYE packets when TEARDOWN is called. I wonder if error depends to them, because from my application I’m not sending. How I can make setup to force ffmpeg to send BYE packets? Thanks in advance. Best, Djordje ___ 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] avcodec/libdav1d: fix setting AVFrame reordered_opaque
On 10/18/2019 7:22 AM, Andrey Semashev wrote: > Actually reorder the values. > > Should effectively fix ticket #8300. > > Signed-off-by: James Almer > > Updated to avoid extra memory allocations on 64-bit platforms. > > Signed-off-by: Andrey Semashev Please stop sending patches by other people with the authorship changed, even if you modified it somewhat. Suggest changes, or ask if I'm ok with you taking over the patch. Anything else will more likely than not be seen as rude by anyone. ___ 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] avcodec/libdav1d: fix setting AVFrame reordered_opaque
On 2019-10-18 15:52, James Almer wrote: On 10/18/2019 7:22 AM, Andrey Semashev wrote: Actually reorder the values. Should effectively fix ticket #8300. Signed-off-by: James Almer Updated to avoid extra memory allocations on 64-bit platforms. Signed-off-by: Andrey Semashev Please stop sending patches by other people with the authorship changed, even if you modified it somewhat. Suggest changes, or ask if I'm ok with you taking over the patch. Anything else will more likely than not be seen as rude by anyone. Sorry, I didn't mean to offend anyone. I honestly don't understand the problem. I didn't claim the credit for the original change and I did preserve your comment and Signed-off-by, didn't I? Is there something else that I should have done? My aim was to demonstrate my suggestion and perhaps simplify your work. I don't care if my changes are taken or modified, credited or not. If that is not wanted, that is fine, I won't send any more patches. ___ 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] avcodec/libdav1d: fix setting AVFrame reordered_opaque
On 10/18/2019 12:14 PM, Andrey Semashev wrote: > On 2019-10-18 15:52, James Almer wrote: >> On 10/18/2019 7:22 AM, Andrey Semashev wrote: >>> Actually reorder the values. >>> >>> Should effectively fix ticket #8300. >>> >>> Signed-off-by: James Almer >>> >>> Updated to avoid extra memory allocations on 64-bit platforms. >>> >>> Signed-off-by: Andrey Semashev >> >> Please stop sending patches by other people with the authorship changed, >> even if you modified it somewhat. >> >> Suggest changes, or ask if I'm ok with you taking over the patch. >> Anything else will more likely than not be seen as rude by anyone. > > Sorry, I didn't mean to offend anyone. I honestly don't understand the > problem. I didn't claim the credit for the original change and I did > preserve your comment and Signed-off-by, didn't I? Is there something > else that I should have done? Yes, you should have kept the original author name. "git commit --author="foo " or just "git commit --amend" should be enough to preserve authorship. If this patch was committed as is, it would be under your name. > > My aim was to demonstrate my suggestion and perhaps simplify your work. > I don't care if my changes are taken or modified, credited or not. If > that is not wanted, that is fine, I won't send any more patches. Patches are welcome, always. Just keep etiquette in mind (Don't take over patches without asking first, don't change authorship, etc). ___ 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/rtsp: fix rtsp multicasts
If an rtsp server offers a udp multicast address as response of a DESCRIBE command the rtsp client is expected to issue SETUP with "Transport: RTP/AVP/UDP;multicast". Some rtsp servers bail out otherwise. --- libavformat/rtsp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c index 859defa592..3f0cbfc98b 100644 --- a/libavformat/rtsp.c +++ b/libavformat/rtsp.c @@ -1913,6 +1913,9 @@ redirect: && (rt->rtsp_flags & RTSP_FLAG_PREFER_TCP)) lower_transport = RTSP_LOWER_TRANSPORT_TCP; +if (ff_is_multicast_address((struct sockaddr*)&rt->rtsp_streams[rt->nb_rtsp_streams-1]->sdp_ip)) +lower_transport = RTSP_LOWER_TRANSPORT_UDP_MULTICAST; + err = ff_rtsp_make_setup_request(s, host, port, lower_transport, rt->server_type == RTSP_SERVER_REAL ? real_challenge : NULL); -- 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 2/4] avcodec/ffv1: Implementation of the CRC proposal for v4
On Fri, Oct 18, 2019 at 03:09:48AM +0200, Lynne wrote: > Oct 17, 2019, 23:25 by mich...@niedermayer.cc: > Signed-off-by: Michael Niedermayer > --- > libavcodec/ffv1.h| 1 + > libavcodec/ffv1dec.c | 10 +++--- > libavcodec/ffv1enc.c | 10 +++--- > 3 files changed, 15 insertions(+), 6 deletions(-) > > Why 0x4964AF46 instead of 0x? CRC32 of 0x4964AF46 is 0x its effect is just to apply a 0x flip where its needed on the decoder side This is the result of building a block [data] + [32bit checksum] which as a whole has a CRC of 0. So the code can be made simpler on the decoder side, the checksum no longer represents a special case and if you want to apply error correction also the checksum is not a special case If theres a more beautifull way to achive the same then iam certainly interrested in that Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk 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 v4] avformat/movenc: split empty text sample when duration overflow
On Wed, Oct 9, 2019 at 3:42 PM Jun Li wrote:
>
>
> On Mon, Oct 7, 2019 at 6:36 PM Jun Li wrote:
>
>>
>>
>> On Mon, Oct 7, 2019 at 6:34 PM Jun Li wrote:
>>
>>> Fix #7637
>>> One empty/end sample is created and inserted between two caption lines
>>> when there is a gap.
>>> This patch is to split the sample into multiple ones when its duration
>>> is too long (>= INT_MAX)
>>>
>>> Signed-off-by: Jun Li
>>> ---
>>> libavformat/movenc.c | 26 ++-
>>> tests/fate/subtitles.mak | 6 +
>>> tests/ref/fate/binsub-movtextenc-long-dur | 1 +
>>> .../fate/binsub-movtextenc-long-dur-timebase | 1 +
>>> 4 files changed, 28 insertions(+), 6 deletions(-)
>>> create mode 100644 tests/ref/fate/binsub-movtextenc-long-dur
>>> create mode 100644 tests/ref/fate/binsub-movtextenc-long-dur-timebase
>>>
>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> index 715bec1c2f..5dc2a19c3c 100644
>>> --- a/libavformat/movenc.c
>>> +++ b/libavformat/movenc.c
>>> @@ -5750,7 +5750,8 @@ static int mov_write_packet(AVFormatContext *s,
>>> AVPacket *pkt)
>>> *
>>> * 2) For each subtitle track, check if the current packet's
>>> * dts is past the duration of the last subtitle sample. If
>>> - * so, we now need to write an end sample for that subtitle.
>>> + * so, we now need to write one or multiple end samples for
>>> + * that subtitle.
>>> *
>>> * This must be done conditionally to allow for subtitles that
>>> * immediately replace each other, in which case an end sample
>>> @@ -5764,11 +5765,24 @@ static int mov_write_packet(AVFormatContext *s,
>>> AVPacket *pkt)
>>> int ret;
>>>
>>> if (trk->par->codec_id == AV_CODEC_ID_MOV_TEXT &&
>>> -trk->track_duration < pkt->dts &&
>>> -(trk->entry == 0 || !trk->last_sample_is_subtitle_end))
>>> {
>>> -ret = mov_write_subtitle_end_packet(s, i,
>>> trk->track_duration);
>>> -if (ret < 0) return ret;
>>> -trk->last_sample_is_subtitle_end = 1;
>>> +trk->track_duration < pkt->dts) {
>>> +int max_duration = INT_MAX - 1;
>>> +if (trk->entry == 0 ||
>>> !trk->last_sample_is_subtitle_end) {
>>> +ret = mov_write_subtitle_end_packet(s, i,
>>> trk->track_duration);
>>> +if (ret < 0)
>>> +return ret;
>>> +trk->last_sample_is_subtitle_end = 1;
>>> +}
>>> +if (trk->last_sample_is_subtitle_end &&
>>> +pkt->dts - trk->track_duration > max_duration) {
>>> +int64_t dts = trk->track_duration;
>>> +while(pkt->dts - dts > max_duration) {
>>> +dts += max_duration;
>>> +ret = mov_write_subtitle_end_packet(s, i, dts);
>>> +if (ret < 0)
>>> +return ret;
>>> +}
>>> +}
>>> }
>>> }
>>>
>>> diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
>>> index 0042902161..4c2b34c431 100644
>>> --- a/tests/fate/subtitles.mak
>>> +++ b/tests/fate/subtitles.mak
>>> @@ -34,6 +34,12 @@ fate-sub-movtext: CMD = fmtstdout ass -i
>>> $(TARGET_SAMPLES)/sub/MovText_capabilit
>>> FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) += fate-binsub-movtextenc
>>> fate-binsub-movtextenc: CMD = md5 -i
>>> $(TARGET_SAMPLES)/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text
>>> -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
>>>
>>> +FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) +=
>>> fate-binsub-movtextenc-long-dur
>>> +fate-binsub-movtextenc-long-dur: CMD = md5 -i
>>> $(TARGET_SAMPLES)/sub/WebVTT_movtext_long_dur.vtt -map 0 -scodec mov_text
>>> -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
>>> +
>>> +FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) +=
>>> fate-binsub-movtextenc-long-dur-timebase
>>> +fate-binsub-movtextenc-long-dur-timebase: CMD = md5 -i
>>> $(TARGET_SAMPLES)/sub/WebVTT_movtext_long_dur.vtt -map 0 -scodec mov_text
>>> -time_base 1000 -f mp4 -flags +bitexact -fflags +bitexact -movflags
>>> frag_keyframe+empty_moov
>>> +
>>> FATE_SUBTITLES_ASS-$(call DEMDEC, MPL2, MPL2) += fate-sub-mpl2
>>> fate-sub-mpl2: CMD = fmtstdout ass -i
>>> $(TARGET_SAMPLES)/sub/MPL2_capability_tester.txt
>>>
>>> diff --git a/tests/ref/fate/binsub-movtextenc-long-dur
>>> b/tests/ref/fate/binsub-movtextenc-long-dur
>>> new file mode 100644
>>> index 00..eb8a3f8fc7
>>> --- /dev/null
>>> +++ b/tests/ref/fate/binsub-movtextenc-long-dur
>>> @@ -0,0 +1 @@
>>> +7f78c11bb4a6b16335540ef31ba10219
>>> diff --git a/tests/ref/fate/binsub-movtextenc-long-dur-timebase
>>> b/tests/ref/fate/binsub-movtextenc-long-dur-timebase
>>> new file mode 100644
>>>
[FFmpeg-devel] [PATCH 3/4] tools/target_dec_fuzzer: Adjust threshold for VP9
The threshold is chosen so that the worse frames would together not take
excessive time.
A better solution is welcome!
Fixes: Timeout (308sec ->102ms)
Fixes:
18314/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5701689176227840
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 2a8a35d9da..152b4037e4 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -158,6 +158,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_TGV: maxpixels /= 32;break;
case AV_CODEC_ID_TRUEMOTION2: maxpixels /= 1024; break;
case AV_CODEC_ID_VP7: maxpixels /= 256; break;
+case AV_CODEC_ID_VP9: maxpixels /= 4096; break;
}
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] avcodec/wmadec: Check block_align
Fixes: null pointer dereference
Fixes:
18326/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMAV2_fuzzer-5071752362721280
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wmadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c
index 78b51e5871..a2ea930350 100644
--- a/libavcodec/wmadec.c
+++ b/libavcodec/wmadec.c
@@ -822,7 +822,7 @@ static int wma_decode_superframe(AVCodecContext *avctx,
void *data,
s->last_superframe_len = 0;
return 0;
}
-if (buf_size < avctx->block_align) {
+if (buf_size < avctx->block_align || avctx->block_align < 0) {
av_log(avctx, AV_LOG_ERROR,
"Input packet size too small (%d < %d)\n",
buf_size, avctx->block_align);
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avcodec/decode: Also consider channels in max_samples check
Fixes: Timeout (109sec -> 0.6sec)
Fixes:
18309/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INTERPLAY_ACM_fuzzer-6226598168100864
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a7b37c6917..0883c7209c 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1925,7 +1925,7 @@ static int get_buffer_internal(AVCodecContext *avctx,
AVFrame *frame, int flags)
return AVERROR(EINVAL);
}
} else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
-if (frame->nb_samples > avctx->max_samples) {
+if (frame->nb_samples * avctx->channels > avctx->max_samples) {
av_log(avctx, AV_LOG_ERROR, "samples per frame %d, exceeds
max_samples %"PRId64"\n", frame->nb_samples, avctx->max_samples);
return AVERROR(EINVAL);
}
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/vp3: sanity check cropping
This check is not based on the specification, which allows instead arbitrary
croping
Fixes: Timeout (32sec -> 0.1sec)
Fixes:
18207/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5666242274263040
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp3.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index a2bd2ef07d..a28b9b6c6b 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -2991,6 +2991,8 @@ static int theora_decode_header(AVCodecContext *avctx,
GetBitContext *gb)
/* sanity check */
if (av_image_check_size(visible_width, visible_height, 0, avctx) < 0 ||
+visible_width + offset_x + 256 < s->width ||
+visible_height + offset_y + 256 < s->height ||
visible_width + offset_x > s->width ||
visible_height + offset_y > s->height) {
av_log(avctx, AV_LOG_ERROR,
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mpegts: add support for non-standard NIT pid
On Sun, 13 Oct 2019, Anthony Delannoy wrote: Ping I have mixed feelings about this, definitely seems less useful than EPG. I am asking other developers, should we add NIT as a data stream to the mpegts demuxer? 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".
