Re: [FFmpeg-devel] [PATCH 5/5] avformat:hlsenc.c: fix the output's duration smaller than input's in sub-range mode.
> 在 2018年10月11日，下午4:56，Charles Liu 写道：
>
> In fmp4 & sub-range mode, the output's duration always smaller than expected,
> because the size of the last #EXT-X-BYTERANGE is too small.
>
> Signed-off-by: Charles Liu
> ---
> libavformat/hlsenc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 8b3a9b78f4..f8f060d065 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2380,6 +2380,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
> if (ret < 0) {
> goto failed;
> }
> +vs->size = range_length;
> ff_format_io_close(s, >out);
> }
>
> @@ -2388,8 +2389,6 @@ failed:
> if (oc->pb) {
> if (hls->segment_type != SEGMENT_TYPE_FMP4) {
> vs->size = avio_tell(vs->avf->pb) - vs->start_pos;
> -} else {
> -vs->size = avio_tell(vs->avf->pb);
> }
> if (hls->segment_type != SEGMENT_TYPE_FMP4)
> ff_format_io_close(s, >pb);
> --
> 2.19.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Patchset will be pushed if there have no objections :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V2] avcodec-qsvdec-flush-the-buffered-data-before-reinit
Flush the buffered data in libmfx before video param reinit
in case the frames drop.
Cache the first frame causing the reinit and decode zero-size
pkt to flush the buffered pkt before reinit. After all the
buffered pkts being flushed, resume to reinit and decode.
Fix the issue in ticket #7399.
Modified in qsvdec_other.c as well.
[V2]: Move the definition of zero_pkt to where it is exactly
used.
Signed-off-by: Linjie Fu
Signed-off-by: Zhong Li
---
libavcodec/qsvdec.c | 12
libavcodec/qsvdec.h | 2 ++
libavcodec/qsvdec_h2645.c | 11 +++
libavcodec/qsvdec_other.c | 10 +++---
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 22e7a46a85..6753e596a1 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -372,6 +372,8 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
++q->zero_consume_run;
if (q->zero_consume_run > 1)
ff_qsv_print_warning(avctx, ret, "A decode call did not consume
any data");
+} else if (!*sync && bs.DataOffset) {
+++q->buffered_count;
} else {
q->zero_consume_run = 0;
}
@@ -526,6 +528,16 @@ int ff_qsv_process_data(AVCodecContext *avctx, QSVContext
*q,
AV_PIX_FMT_NONE,
AV_PIX_FMT_NONE };
enum AVPixelFormat qsv_format;
+AVPacket zero_pkt = {0};
+
+if (q->buffered_count) {
+q->reinit_flag = 1;
+/* decode zero-size pkt to flush the buffered pkt before reinit */
+q->buffered_count--;
+return qsv_decode(avctx, q, frame, got_frame, _pkt);
+}
+
+q->reinit_flag = 0;
qsv_format = ff_qsv_map_pixfmt(q->parser->format, >fourcc);
if (qsv_format < 0) {
diff --git a/libavcodec/qsvdec.h b/libavcodec/qsvdec.h
index 5b7b03a48b..111536caba 100644
--- a/libavcodec/qsvdec.h
+++ b/libavcodec/qsvdec.h
@@ -53,6 +53,8 @@ typedef struct QSVContext {
AVFifoBuffer *async_fifo;
int zero_consume_run;
+int buffered_count;
+int reinit_flag;
// the internal parser and codec context for parsing the data
AVCodecParserContext *parser;
diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
index d9d2318d1a..b8a78aa81b 100644
--- a/libavcodec/qsvdec_h2645.c
+++ b/libavcodec/qsvdec_h2645.c
@@ -146,10 +146,11 @@ static int qsv_decode_frame(AVCodecContext *avctx, void
*data,
/* no more data */
if (av_fifo_size(s->packet_fifo) < sizeof(AVPacket))
return avpkt->size ? avpkt->size : ff_qsv_process_data(avctx,
>qsv, frame, got_frame, avpkt);
-
-av_packet_unref(>buffer_pkt);
-
-av_fifo_generic_read(s->packet_fifo, >buffer_pkt,
sizeof(s->buffer_pkt), NULL);
+/* in progress of reinit, no read from fifo and keep the
buffer_pkt */
+if (!s->qsv.reinit_flag) {
+av_packet_unref(>buffer_pkt);
+av_fifo_generic_read(s->packet_fifo, >buffer_pkt,
sizeof(s->buffer_pkt), NULL);
+}
}
ret = ff_qsv_process_data(avctx, >qsv, frame, got_frame,
>buffer_pkt);
@@ -159,6 +160,8 @@ static int qsv_decode_frame(AVCodecContext *avctx, void
*data,
av_packet_unref(>buffer_pkt);
return ret;
}
+if (s->qsv.reinit_flag)
+continue;
s->buffer_pkt.size -= ret;
s->buffer_pkt.data += ret;
diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
index 993c7a8e80..b449bb21b7 100644
--- a/libavcodec/qsvdec_other.c
+++ b/libavcodec/qsvdec_other.c
@@ -132,9 +132,11 @@ static int qsv_decode_frame(AVCodecContext *avctx, void
*data,
/* no more data */
if (av_fifo_size(s->packet_fifo) < sizeof(AVPacket))
return avpkt->size ? avpkt->size : ff_qsv_process_data(avctx,
>qsv, frame, got_frame, avpkt);
-
-av_packet_unref(>input_ref);
-av_fifo_generic_read(s->packet_fifo, >input_ref,
sizeof(s->input_ref), NULL);
+/* in progress of reinit, no read from fifo and keep the
buffer_pkt */
+if (!s->qsv.reinit_flag) {
+av_packet_unref(>input_ref);
+av_fifo_generic_read(s->packet_fifo, >input_ref,
sizeof(s->input_ref), NULL);
+}
}
ret = ff_qsv_process_data(avctx, >qsv, frame, got_frame,
>input_ref);
@@ -145,6 +147,8 @@ static int qsv_decode_frame(AVCodecContext *avctx, void
*data,
return ret;
}
+if (s->qsv.reinit_flag)
+continue;
s->input_ref.size -= ret;
s->input_ref.data += ret;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: remove myself as hls demuxer maintainer
Anssi Hannula kirjoitti 2018-10-15 00:07: --- Unfortunately I haven't really had the time lately to maintain the HLS demuxer properly and I don't see that changing in the near future. So I intend to apply this removal tomorrow. If anyone is interested in taking over, please do :) I'll continue to maintain the lower-traffic spdif (de)muxers. Applied. MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3dd26e374f..bc2ae13320 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -413,7 +413,6 @@ Muxers/Demuxers: flvenc.c Michael Niedermayer, Steven Liu gxf.c Reimar Doeffinger gxfenc.c Baptiste Coudurier - hls.c Anssi Hannula hlsenc.c Christian Suloway, Steven Liu idcin.c Mike Melanson idroqdec.cMike Melanson -- Anssi Hannula ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: change OS X to macOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-10-15 14:27, James Almer wrote: > It's fine, but maybe instead of "doc" use "download" for the > commit message since that's the page you're updating. Thanks for the reply. Shall I send the patch again with a different commit message? The reason why I chose 'doc' was because it was a change to the documentation. I figured that's more than enough. Cheers, K. C. - -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE191csiqpm8f5Ln9WvgmFNJ1E3QAFAlvE3wMACgkQvgmFNJ1E 3QC4rQ/9EfKyod+UmK76IMAvf+l4yqGQ9fcUsinUNprBjZYZu2N3jFwFHnhDL6ak 1rfbvyP3VZ06lH7lwY4FH5aYkmLkdbrnJYGmiNM1CjjIqtlf6viHLspO9nv3XkI7 PHAZY1McTH1pFsQA/UNvEev9OYV0JhykJhUKCtAVTO7xDPnqKBtNRTGdtKXrNZMF zkNQk1TZSR8/DvqYqRbeMneoEnhCIz11wmGp0NcOlAR+EwCaOUs3xEDSbXAauqf5 Bt27D9oGJXD4tzXYKjGl5GfQ8HmJ2KihtGhyYoBKoGFMtrG0dH7XBxBsA1GDo2mn XaVja8r2uqOJMcLRdiOoX3A345m+9kX+ZiEkNNun8cDkvGP6pBKtw9ho1y4Of+wj J9iMFYww1vdjYNE7j1sf4QPWgO44mrMtb1lVKvxaPG59WCA4lFkL8dQj21myZF3Y /ShKOODCqlWx6ZKa2++8gH4faWg1Q5hqDbcL3vizQejPG81SjRU5+uan2ryphUjz hHp5skdbW3MLlOW8TQCgoBz4BbAFoAraeqC/KwQZ+W7pHpr9lPAAAc8o1bletRno deDRqMGAiS7iA4RZrvgOLWxdr3HAkup029/kqkOPaOtJBuo5ZUv3ydzRNlsN1FPf uWqkGqc9q5qM3SglnJwWIL87iRPAJxge+/6eIhrOhpKyTDxrFa0= =LkEN -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: change OS X to macOS
On 10/15/2018 1:33 PM, Helmut K. C. Tessarek wrote: > Just a quick question. Did I do everything right with the patch > submission? I haven't subitted anything for a very long time here, so > I hope the procedure hasn't changed. > > Cheers, > K. C. It's fine, but maybe instead of "doc" use "download" for the commit message since that's the page you're updating. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Thu, Oct 11, 2018 at 5:28 PM Jan Ekström wrote: > On Thu, Oct 11, 2018 at 10:58 PM Alex Sukhanov > wrote: > > > > Hi Mark, > > > > at Google we have some old service which is still running and it works > only > > with the IVF container. It would be great if ffmpeg could generate such > > videos so we could give them to the service then. Given that ffmpeg IVF > > demuxer already supports reading such files, I think it's reasonable to > > make IVF muxer be able to generate them. > > Hope it answers the question. > > > > Thank you > > Given the amount of code is not large I'm not against having it in, > but if it's not something that ever was meant to go into the public > I'd probably disable creation of such files unless you enable a less > standards-compliant strictness mode. > maybe creation of such files could be allowed only with a strict compliance flag? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: change OS X to macOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Just a quick question. Did I do everything right with the patch submission? I haven't subitted anything for a very long time here, so I hope the procedure hasn't changed. Cheers, K. C. On 2018-10-15 00:49, Helmut K. C. Tessarek wrote: > --- src/download | 2 +- 1 file changed, 1 insertion(+), 1 > deletion(-) - -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE191csiqpm8f5Ln9WvgmFNJ1E3QAFAlvEwU0ACgkQvgmFNJ1E 3QAuSw//cuCYPdE2GaVTEMObtDlRG6F2f0o2iox/vV2X42bXNy/4mIwchO8neSMb Nb9rS8zyr1ahpeObSVRzqmZ6pD7coDITWWm0MZlJKJbOFB4XrwrtqW1zWOtVFxRu MWH13Gkt3K1cUHWT0O9yQWkmd03K24NmA4vsuAuqC2Tm89DuZimvMRc6nAiwmIGE /+EaruEC6+16YOR6Sujl84WnCWa1ET6D9ZOszPN6noURmmiKLJA7xY9w/0A+PI3W jfeEza6qIhRTBQOyCOlrn9RNTgYQCyaBRFaVtpNVd890l0w3vPUHW9eYx/h4gNVz 2YvwUpg3sL7Itcxa4S1GvihU/7/0DNq8M497FqLYoBcKeyhQwzTGzsmII0tdUuta 0ayBVkDHw6VQudP/h9cuRW4PRPSRQwo4Mff/1VRhXNIbpMyIJt8kQtmaAk3eVDa/ j/0Vo6c+AzExujmKa+olSXr1G+HwbKJUhoSP/khRbBVFR368OfP15kFodEpIvSSU 6T6v9IaV6W2kCXa2J7gMAmVMtvH1B6Bp+nU6URhLzb1qwv13og0yyq1YKZq09BSj Ggn5LLND3Nmu0zhrB4pJaifAg719JHADCRkr7unZ7Nfv8NXPBRFJl+Ri1ngRqu4F UA0ARANfZlhKsQqy8CgMedl5/9OUeVnkAlPQdcCBbFB2m4l+/Gg= =jDTi -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V4 2/2] lavf/vc1test: add rcv to vc1test demuxer extensions
rcv is commonly used as extension for vc1 test stream files.
Signed-off-by: Jun Zhao
---
libavformat/vc1test.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index 2427660..8aaad93 100644
--- a/libavformat/vc1test.c
+++ b/libavformat/vc1test.c
@@ -122,5 +122,6 @@ AVInputFormat ff_vc1t_demuxer = {
.read_probe = vc1t_probe,
.read_header= vc1t_read_header,
.read_packet= vc1t_read_packet,
+.extensions = "rcv",
.flags = AVFMT_GENERIC_INDEX,
};
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V4 0/2] fix vc1test can't probe some RCV file
v4: - add size check to avoid overread v3: - add size check when probe as Michael's comments. - update commit msg - for Jerome's comments, I don't find a way to adjusted the handle for "0x000c" v2: - split the patch (Carl Eugen Hoyos's comments). Jun Zhao (2): lavf/vc1test: fix vc1test can't probe some RCV file. lavf/vc1test: add rcv to vc1test demuxer extensions libavformat/vc1test.c | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V4 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.
case 1:
use the hexdump -C SMM0005.rcv get:
size skip (size - 4)
||
VV
18 00 00 c5 05 00 00 00 4d f1 0a 11 00 e0 01 00
0010 00 d0 02 00 00 0c 00 00 00 88 13 00 00 c0 65 52
^
|
size + 16
case 2:
same the command for SMM0015.rcv get:
size
|
V
19 00 00 c5 04 00 00 00 41 f3 80 01 40 02 00 00
0010 d0 02 00 00 0c 00 00 00 00 00 00 10 00 00 00 00
^
|
size + 16
There are different the RCV file format for VC-1, vc1test
just handle the case 2 now, this fix will support the case 1.
(Both of test clips come from: SMPTE Recommended Practice -
VC-1 Decoder and Bitstream Conformance). And I think I got
a older VC-1 test clip in the case 1.
Reviewed-by: Carl Eugen Hoyos
Reviewed-by: Jerome Borsboom
Reviewed-by: Michael Niedermayer
Signed-off-by: Jun Zhao
Signed-off-by: Yan, FengX
---
libavformat/vc1test.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index a801f4b..2427660 100644
--- a/libavformat/vc1test.c
+++ b/libavformat/vc1test.c
@@ -34,9 +34,14 @@
static int vc1t_probe(AVProbeData *p)
{
+int size;
+
if (p->buf_size < 24)
return 0;
-if (p->buf[3] != 0xC5 || AV_RL32(>buf[4]) != 4 || AV_RL32(>buf[20])
!= 0xC)
+
+size = AV_RL32(>buf[4]);
+if (p->buf[3] != 0xC5 || size < 4 || size+16 > p->buf_size ||
+AV_RL32(>buf[size+16]) != 0xC)
return 0;
return AVPROBE_SCORE_EXTENSION;
@@ -48,9 +53,10 @@ static int vc1t_read_header(AVFormatContext *s)
AVStream *st;
int frames;
uint32_t fps;
+int size;
frames = avio_rl24(pb);
-if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)
+if (avio_r8(pb) != 0xC5 || ((size = avio_rl32(pb)) < 4))
return AVERROR_INVALIDDATA;
/* init video codec */
@@ -63,6 +69,8 @@ static int vc1t_read_header(AVFormatContext *s)
if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
return AVERROR(ENOMEM);
+
+avio_skip(pb, size - 4);
st->codecpar->height = avio_rl32(pb);
st->codecpar->width = avio_rl32(pb);
if(avio_rl32(pb) != 0xC)
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] fate: add api-h264-slice test
From: Josh de Kock
This test ensures that you are able to send N number of slice NALUs in slice
threaded mode to be decoded simultaneously
---
Tested on Linux 32/64, MinGW + WINE 32/64.
tests/api/Makefile | 1 +
tests/api/api-h264-slice-test.c | 216 ++
tests/fate/api.mak | 4 +
tests/ref/fate/api-h264-slice | 309
4 files changed, 530 insertions(+)
create mode 100644 tests/api/api-h264-slice-test.c
create mode 100644 tests/ref/fate/api-h264-slice
diff --git a/tests/api/Makefile b/tests/api/Makefile
index 759dd9d243..b5c4ccae23 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,5 +1,6 @@
APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
+APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264-slice
APITESTPROGS-yes += api-seek
APITESTPROGS-yes += api-codec-param
APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
new file mode 100644
index 00..2021996d78
--- /dev/null
+++ b/tests/api/api-h264-slice-test.c
@@ -0,0 +1,216 @@
+/*
+ * Copyright (c) 2001 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#define MAX_SLICES 8
+
+// ./fate 2 ./crew_cif out.y4m
+
+#include "config.h"
+
+#include
+#include
+#include
+#include
+
+#if HAVE_UNISTD_H
+#include
+#endif
+#if HAVE_IO_H
+#include
+#endif
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static int header = 0;
+
+static void decode(AVCodecContext *dec_ctx, AVFrame *frame,
+ AVPacket *pkt)
+{
+static uint64_t frame_cnt = 0;
+int ret;
+
+ret = avcodec_send_packet(dec_ctx, pkt);
+if (ret < 0) {
+fprintf(stderr, "Error sending a packet for decoding: %s\n",
av_err2str(ret));
+exit(1);
+}
+
+while (ret >= 0) {
+const AVPixFmtDescriptor *desc;
+char *sum;
+struct AVHashContext *hash;
+
+ret = avcodec_receive_frame(dec_ctx, frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
+return;
+} else if (ret < 0) {
+fprintf(stderr, "Error during decoding: %s\n", av_err2str(ret));
+exit(1);
+}
+
+if (!header) {
+printf(
+"#format: frame checksums\n"
+"#version: 2\n"
+"#hash: MD5\n"
+"#tb 0: 1/30\n"
+"#media_type 0: video\n"
+"#codec_id 0: rawvideo\n"
+"#dimensions 0: 352x288\n"
+"#sar 0: 128/117\n"
+"#stream#, dts,pts, duration, size, hash\n");
+header = 1;
+}
+desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+av_hash_alloc(, "md5");
+av_hash_init(hash);
+sum = av_mallocz(av_hash_get_size(hash) * 2 + 1);
+
+for (int i = 0; i < frame->height; i++)
+av_hash_update(hash, >data[0][i * frame->linesize[0]],
frame->width);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[1][i * frame->linesize[1]],
frame->width >> desc->log2_chroma_w);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[2][i * frame->linesize[2]],
frame->width >> desc->log2_chroma_w);
+
+av_hash_final_hex(hash, sum, av_hash_get_size(hash) * 2 + 1);
+printf("0, %10"PRId64", %10"PRId64",1, %8d, %s\n",
+frame_cnt, frame_cnt,
+(frame->width * frame->height + 2 * (frame->height >>
desc->log2_chroma_h) * (frame->width >> desc->log2_chroma_w)), sum);
+frame_cnt += 1;
+av_free(hash);
+av_free(sum);
+}
+}
+
+int main(int argc, char **argv)
+{
+const AVCodec *codec;
+AVCodecContext *c = NULL;
+AVFrame *frame;
+unsigned int threads;
+
Re: [FFmpeg-devel] Fixing rotation metadata override
Oh my bad, I had 2 tickets on this subject and the one that is still opened is: https://trac.ffmpeg.org/ticket/6370 Anyway, the issue is still around Le lun. 15 oct. 2018 à 13:27, Carl Eugen Hoyos a écrit : > 2018-10-15 12:11 GMT+02:00, Gilles : > > > the one in the first post: https://trac.ffmpeg.org/ticket/4560 > > Again: > This ticket was fixed years ago and is not reproducible with > current FFmpeg git head. > > Please stop top-posting here, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fixing rotation metadata override
2018-10-15 12:11 GMT+02:00, Gilles : > the one in the first post: https://trac.ffmpeg.org/ticket/4560 Again: This ticket was fixed years ago and is not reproducible with current FFmpeg git head. Please stop top-posting here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] prores_ks: use CodecContext for color information if specified
Le lun. 15 oct. 2018 à 11:24, Marc-Antoine ARNAUD < arnaud.marcanto...@gmail.com> a écrit : > Hi Martin, > > For my point of view, the AVFrame contains the colorspace for each frame, > which can be different (maybe not volunteer..). > The colorspace in AVCodecContext is the "pre-computed" colorspace, used to > generate the output file, as header/footer of wrappers can require > colorspace informations (like in MXF, MOV, etc.). > > So for me, the AVCodecContext is required and needed to be pre-processed to > wrote the header, and no AVFrame are processed at this stage. > The AVFrame colorspace is required to maybe change graph properties in > real-time (like a colorspace conversion can be set to convert the output > from different colorspace inputs). > > So both are differents, but on my point of view, regarding comments, I > purpose: > - AVCodecContext will overwrite the output colorspace (if present) > - AVFrame can be use in video encoder to setup frame headers packets (like > in Mpeg2, H.264, H.265, ProRes etc.) if no AVCodecContext is configured. > - a warning needs to be logged if: > - AVCodecContext colorspace don't match to the AVFrame colorspace > > Remark: colorspace mean here variables for colorspace, color primaries and > color transfer. > > So maybe for that, as Paul mentionned, it may require to patch that at an > upper level than encoder to be sure all works similary. But I don't know > where to be honest. > > Hello Marc, From a user point of view : - if i encode a prores file from a prores file which have different colorspace in each frame i expected to have the input colorspace of each frame in the target file. (So software which use this information will display original and reencode prores in the same way) Not sure it's correctly works right now (at least for the prores decoder part) In that case colorspace for the muxer, will not be the same than colorspace for the frame. - If i would like to set each frame to the right colorspace in a prores file without reencoding a bsf (Bitstream filter), can be use to set this info without decode/reencode ==> Probably not a lot of work, to add this kind of filter - If i would like to reencode a file, and fix this information at the same time, a filter which set the property without converting colorspace can be use (maybe with a special case to set it only if AVFrame have an unspecifed colorspace) (probably need to write one for this) - If i would like to convert the colorspace of each frame to be sure all the frames of a file are for example in Rec709 a filter can be use, to convert frame which have another colorspace, and bypass the frame which already have the right colorspace For the two last case, i don't know enough libavfilter, to know which is possible using existing filter, and what to be add. For your proposition, i'm not sure auto switching from one way to take colorspace to another silently (use AVCodecContext, if AVFrame don't have Colorspace information, for the frame header, is a good idea) Depending of the input file (have information or not for all frames), the behaviour will be different, probably little hard to use in practice For the warning if codec context doesn't match AVFrame colorspace, i agree in theory, but in practice, it can make one warning per frame, and make ffmpeg log unreadable. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fixing rotation metadata override
Hi, the one in the first post: https://trac.ffmpeg.org/ticket/4560 Le lun. 15 oct. 2018 à 11:40, Carl Eugen Hoyos a écrit : > 2018-10-15 10:29 GMT+02:00, Gilles : > > > it looks like to me that the issue is still present. > > Which issue? Please fix the commit message accordingly. > > Please do not top-post here, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fixing rotation metadata override
2018-10-15 10:29 GMT+02:00, Gilles : > it looks like to me that the issue is still present. Which issue? Please fix the commit message accordingly. Please do not top-post here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] prores_ks: use CodecContext for color information if specified
Hi Martin, For my point of view, the AVFrame contains the colorspace for each frame, which can be different (maybe not volunteer..). The colorspace in AVCodecContext is the "pre-computed" colorspace, used to generate the output file, as header/footer of wrappers can require colorspace informations (like in MXF, MOV, etc.). So for me, the AVCodecContext is required and needed to be pre-processed to wrote the header, and no AVFrame are processed at this stage. The AVFrame colorspace is required to maybe change graph properties in real-time (like a colorspace conversion can be set to convert the output from different colorspace inputs). So both are differents, but on my point of view, regarding comments, I purpose: - AVCodecContext will overwrite the output colorspace (if present) - AVFrame can be use in video encoder to setup frame headers packets (like in Mpeg2, H.264, H.265, ProRes etc.) if no AVCodecContext is configured. - a warning needs to be logged if: - AVCodecContext colorspace don't match to the AVFrame colorspace Remark: colorspace mean here variables for colorspace, color primaries and color transfer. So maybe for that, as Paul mentionned, it may require to patch that at an upper level than encoder to be sure all works similary. But I don't know where to be honest. Marc-Antoine Le sam. 13 oct. 2018 à 14:03, Martin Vignali a écrit : > Le mer. 10 oct. 2018 à 17:13, Marc-Antoine ARNAUD < > arnaud.marcanto...@gmail.com> a écrit : > > > I have updated the patch with our discussion. > > It took information only from the codec context. > > > > Marc-Antoine > > > > Hello, > > If i correctly understand (which is not sure :-) : > > the colorspace for AVCodecContext, is when all frame use the same > colorspace > > The colorspace in AVFrame, manage the case where colorspace can not be the > same inside each frame. > and this info is use inside filtering graph. > > If this is correct, then prores encoder need to use AVFrame colorspace for > each frame > and if the colorspace information is wrong, or if user need to set another > one, a filter need to be use to edit the frame (set colorspace information > or convert from one colorspace to another frame by frame) > (Or if just the colorspace metadata inside the compress prores frame need > to be fix, a bsf can be write to edit frame colorspace properties for > prores frame) > > Another way can be to add an option to the prores encoder, to take > colorspace information from CodecContext or from Frame. > > > But if other people think your way is better, > i will change my patch for prores_aw, in order to use the same way to set > colorspace for each prores frame. > > P.S. : Seems like png at least also use AVFrame information instead of > AVCodecContext > > Martin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer
On Sun, Oct 14, 2018 at 10:24:22AM -0300, James Almer wrote: > On 10/14/2018 9:59 AM, Michael Niedermayer wrote: > > On Sun, Oct 14, 2018 at 01:29:53PM +0300, Jan Ekström wrote: > >> On Sun, Oct 14, 2018 at 1:27 PM Jan Ekström wrote: > >>> > >>> On Sun, Oct 14, 2018 at 3:17 AM Michael Niedermayer > >>> wrote: > > On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote: > > On 11/10/2018 23:39, Alex Sukhanov wrote: > >> The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF > > > > Yeah, not really a spec. > > > > I have no strong objections, I guess. > > so IIUC noone is against this ? > if so i will apply the last patch in a few days unless i forget or > someone else does before > > thx > > >>> > >>> As mentioned, since this is nothing should have ever been used outside > >>> of one of GOOG's legacy systems, I would only apply this with a > >>> warning and strictness requirement of experimental or whatever level > >>> matches these sorts of cases. > >>> > >> > >> For the record, this was regarding the muxer so that unknowing people > >> will not generate such files that nothing else can read. > > > > If you choose a random container and store a random codec in it (which you > > can do) > > chances are theres not much that will play it. > > > > for example i just tried muxing a stream of png images into mpeg and FFmpeg > > does that without complaining. > > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec png test.mpeg > > > > So if we do not check this for a major format that has a proper > > specification > > which i belive nowhere allows png > > > > Why should we add a limitation on a format that has nothing saying that you > > cannot put some other codec into it ? > > The proper thing to do would be to effectively disallow such invalid > muxing scenarios, fixing this instead of adding even more wrong cases to > the pile. > I'm fairly sure we blocked a patch to allow muxing hevc into flv years > ago. That's what needs to be done in general. I think where we disagree is not that "we should disallow invalid muxing" but if this is invalid/wrong. And also it seems to me that people appear to be very quick in jumping onto such "lets block it" movments without doing much research about new codecs in IVF, which this thread is about, why is that invalid ? our ivf demuxer refers to itself as "On2 IVF" so i presume the format was created by On2 (googling for On2 IVF results in only strange results interrestingly) but presumably IVF was created by On2 In February 2010, On2 Technologies was acquired by Google (https://en.wikipedia.org/wiki/On2_Technologies) And google is using IVF apparently from what was said in this thread with more codecs. Well from how i understand it (please correct me if iam wrong) IVF is now a format "owned" by google. They certainly can add things to it. Theres nothing wrong or invalid on this. 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 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fixing rotation metadata override
Hi, it looks like to me that the issue is still present. source.mp4 is a vertical video from an iphone, with a 90degres rotation. mediainfo source.mp4 | grep -i rot Rotation : 90? I run: /usr/local/bin/ffmpeg -autorotate 0 -i ./source.mp4 -metadata:s:v:0 rotate=0 -an -vcodec libx264 -f mp4 out.mp4 ffmpeg version N-92179-gc27c7b49dc Copyright (c) 2000-2018 the FFmpeg developers built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3) configuration: --enable-libx264 --enable-gpl libavutil 56. 19.101 / 56. 19.101 libavcodec 58. 33.100 / 58. 33.100 libavformat58. 19.100 / 58. 19.100 libavdevice58. 4.105 / 58. 4.105 libavfilter 7. 33.101 / 7. 33.101 libswscale 5. 2.100 / 5. 2.100 libswresample 3. 2.100 / 3. 2.100 libpostproc55. 2.100 / 55. 2.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from './source.mp4': Metadata: major_brand : qt minor_version : 0 compatible_brands: qt com.apple.quicktime.make: Apple com.apple.quicktime.model: iPhone XS Max com.apple.quicktime.software: 12.0.1 com.apple.quicktime.creationdate: 2018-10-12T15:32:47+0200 Duration: 00:00:03.04, start: 0.00, bitrate: 23697 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 23504 kb/s, 59.93 fps, 59.94 tbr, 600 tbn, 1200 tbc (default) Metadata: rotate : 90 creation_time : 2018-10-12T13:32:47.00Z handler_name: Core Media Video encoder : H.264 Side data: displaymatrix: rotation of -90.00 degrees Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 170 kb/s (default) Metadata: creation_time : 2018-10-12T13:32:47.00Z handler_name: Core Media Audio Stream #0:2(und): Data: none (mebx / 0x7862656D), 0 kb/s (default) Metadata: creation_time : 2018-10-12T13:32:47.00Z handler_name: Core Media Metadata Stream #0:3(und): Data: none (mebx / 0x7862656D), 0 kb/s (default) Metadata: creation_time : 2018-10-12T13:32:47.00Z handler_name: Core Media Metadata Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Press [q] to stop, [?] for help [libx264 @ 0x3cbea80] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 [libx264 @ 0x3cbea80] profile High, level 4.2 [libx264 @ 0x3cbea80] 264 - core 142 r2389 956c8d8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=72 lookahead_threads=8 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to 'out.mp4': Metadata: major_brand : qt minor_version : 0 compatible_brands: qt com.apple.quicktime.creationdate: 2018-10-12T15:32:47+0200 com.apple.quicktime.location.ISO6709: +48.8848+002.3087+040.257/ com.apple.quicktime.make: Apple com.apple.quicktime.model: iPhone XS Max com.apple.quicktime.software: 12.0.1 encoder : Lavf58.19.100 Stream #0:0(und): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1920x1080, q=-1--1, 59.94 fps, 60k tbn, 59.94 tbc (default) Metadata: encoder : Lavc58.33.100 libx264 creation_time : 2018-10-12T13:32:47.00Z handler_name: Core Media Video Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1 displaymatrix: rotation of -90.00 degrees frame= 66 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x^Mframe= 118 fps=115 q=31.0 size= 0kB time=-00:00:00.01 bitrate=N/A speed=N/A^Mframe= 160 fps=105 q=31.0 size= 256kB time=00:00:00.68 bitrate=3066.4kbits/s speed=0.447x ^Mframe= 182 fps= 76 q=-1.0 Lsize=2130kB time=00:00:02.98 bitrate=5843.8kbits/s speed=1.25x video:2128kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.115240% [libx264 @ 0x3cbea80] frame I:1 Avg QP:25.69 size: 74747 [libx264 @ 0x3cbea80] frame P:130 Avg QP:26.60 size: 14220 [libx264 @ 0x3cbea80] frame B:51Avg QP:27.71 size: 4998 [libx264 @ 0x3cbea80] consecutive B-frames: 44.0% 56.0% 0.0% 0.0% [libx264 @ 0x3cbea80] mb I I16..4: 25.9% 49.8% 24.3% [libx264 @ 0x3cbea80] mb P I16..4: 6.4% 7.8% 0.3% P16..4: 34.9% 5.1% 2.5% 0.0% 0.0%skip:42.8% [libx264 @ 0x3cbea80] mb B I16..4: 0.3% 0.5% 0.0% B16..8: 37.1% 1.1% 0.1% direct: 0.7% skip:60.1% L0:48.1% L1:50.6% BI: 1.2% [libx264 @ 0x3cbea80] 8x8
Re: [FFmpeg-devel] [PATCH V3 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.
On Mon, Oct 15, 2018 at 3:15 PM Jerome Borsboom
wrote:
>
> > case 1:
> > use the hexdump -C SMM0005.rcv get:
> > size skip (size - 4)
> > ||
> > VV
> > 18 00 00 c5 05 00 00 00 4d f1 0a 11 00 e0 01 00
> > 0010 00 d0 02 00 00 0c 00 00 00 88 13 00 00 c0 65 52
> > ^
> >|
> >size + 16
> > case 2:
> > same the command for SMM0015.rcv get:
> > size
> > |
> > V
> > 19 00 00 c5 04 00 00 00 41 f3 80 01 40 02 00 00
> > 0010 d0 02 00 00 0c 00 00 00 00 00 00 10 00 00 00 00
> > ^
> > |
> > size + 16
> >
> > There are different the RCV file format for VC-1, vc1test
> > just handle the case 2 now, this fix will support the case 1.
> > (Both of test clips come from: SMPTE Recommended Practice -
> > VC-1 Decoder and Bitstream Conformance). And I think I got
> > a older VC-1 test clip in the case 1.
> >
> > Reviewed-by: Carl Eugen Hoyos
> > Reviewed-by: Jerome Borsboom
> > Reviewed-by: Michael Niedermayer
> > Signed-off-by: Jun Zhao
> > Signed-off-by: Yan, FengX
> > ---
> > libavformat/vc1test.c | 11 +--
> > 1 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
> > index a801f4b..e029ff4 100644
> > --- a/libavformat/vc1test.c
> > +++ b/libavformat/vc1test.c
> > @@ -34,9 +34,13 @@
> >
> > static int vc1t_probe(AVProbeData *p)
> > {
> > +int size;
> > +
> > if (p->buf_size < 24)
> > return 0;
> > -if (p->buf[3] != 0xC5 || AV_RL32(>buf[4]) != 4 ||
> AV_RL32(>buf[20]) != 0xC)
> > +
> > +size = AV_RL32(>buf[4]);
> > +if (p->buf[3] != 0xC5 || size < 4 || AV_RL32(>buf[size+16]) !=
> 0xC)
> > return 0;
> >
> > return AVPROBE_SCORE_EXTENSION;
> > @@ -48,9 +52,10 @@ static int vc1t_read_header(AVFormatContext *s)
> > AVStream *st;
> > int frames;
> > uint32_t fps;
> > +int size;
> >
> > frames = avio_rl24(pb);
> > -if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)
> > +if (avio_r8(pb) != 0xC5 || ((size = avio_rl32(pb)) < 4))
> > return AVERROR_INVALIDDATA;
> >
> > /* init video codec */
> > @@ -63,6 +68,8 @@ static int vc1t_read_header(AVFormatContext *s)
> >
> > if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
> > return AVERROR(ENOMEM);
> > +
> > +avio_skip(pb, size - 4);
> > st->codecpar->height = avio_rl32(pb);
> > st->codecpar->width = avio_rl32(pb);
> > if(avio_rl32(pb) != 0xC)
> > --
> > 1.7.1
>
> You may still overread the buffer as the first check on buf_size only
> checks for at least 24 bytes. The following p->buf[size+16] may read
> beyond the end of the buffer.
>
I see, need to double-check the size with " size < 4 || size + 20 >
p->buf_size" in probe
> Regards,
> Jerome
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V3 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.
> case 1:
> use the hexdump -C SMM0005.rcv get:
> size skip (size - 4)
> ||
> VV
> 18 00 00 c5 05 00 00 00 4d f1 0a 11 00 e0 01 00
> 0010 00 d0 02 00 00 0c 00 00 00 88 13 00 00 c0 65 52
> ^
>|
>size + 16
> case 2:
> same the command for SMM0015.rcv get:
> size
> |
> V
> 19 00 00 c5 04 00 00 00 41 f3 80 01 40 02 00 00
> 0010 d0 02 00 00 0c 00 00 00 00 00 00 10 00 00 00 00
> ^
> |
> size + 16
>
> There are different the RCV file format for VC-1, vc1test
> just handle the case 2 now, this fix will support the case 1.
> (Both of test clips come from: SMPTE Recommended Practice -
> VC-1 Decoder and Bitstream Conformance). And I think I got
> a older VC-1 test clip in the case 1.
>
> Reviewed-by: Carl Eugen Hoyos
> Reviewed-by: Jerome Borsboom
> Reviewed-by: Michael Niedermayer
> Signed-off-by: Jun Zhao
> Signed-off-by: Yan, FengX
> ---
> libavformat/vc1test.c | 11 +--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
> index a801f4b..e029ff4 100644
> --- a/libavformat/vc1test.c
> +++ b/libavformat/vc1test.c
> @@ -34,9 +34,13 @@
>
> static int vc1t_probe(AVProbeData *p)
> {
> +int size;
> +
> if (p->buf_size < 24)
> return 0;
> -if (p->buf[3] != 0xC5 || AV_RL32(>buf[4]) != 4 ||
AV_RL32(>buf[20]) != 0xC)
> +
> +size = AV_RL32(>buf[4]);
> +if (p->buf[3] != 0xC5 || size < 4 || AV_RL32(>buf[size+16]) !=
0xC)
> return 0;
>
> return AVPROBE_SCORE_EXTENSION;
> @@ -48,9 +52,10 @@ static int vc1t_read_header(AVFormatContext *s)
> AVStream *st;
> int frames;
> uint32_t fps;
> +int size;
>
> frames = avio_rl24(pb);
> -if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)
> +if (avio_r8(pb) != 0xC5 || ((size = avio_rl32(pb)) < 4))
> return AVERROR_INVALIDDATA;
>
> /* init video codec */
> @@ -63,6 +68,8 @@ static int vc1t_read_header(AVFormatContext *s)
>
> if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
> return AVERROR(ENOMEM);
> +
> +avio_skip(pb, size - 4);
> st->codecpar->height = avio_rl32(pb);
> st->codecpar->width = avio_rl32(pb);
> if(avio_rl32(pb) != 0xC)
> --
> 1.7.1
You may still overread the buffer as the first check on buf_size only
checks for at least 24 bytes. The following p->buf[size+16] may read
beyond the end of the buffer.
Regards,
Jerome
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
