[FFmpeg-devel] [PATCH] libavformat/mux: Fix mixed delarations and code
This commit fixes mixed declarations and code introduced in 1889e316.
Signed-off-by: Andreas Rheinhardt
---
Sorry for the oversight.
libavformat/mux.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 5e1ecd8485..21f10caf53 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1005,10 +1005,11 @@ static int interleave_compare_dts(AVFormatContext *s,
AVPacket *next,
int preload = st ->codecpar->codec_type == AVMEDIA_TYPE_AUDIO;
int preload2 = st2->codecpar->codec_type == AVMEDIA_TYPE_AUDIO;
if (preload != preload2) {
+int64_t ts, ts2;
preload *= s->audio_preload;
preload2 *= s->audio_preload;
-int64_t ts = av_rescale_q(pkt ->dts, st ->time_base,
AV_TIME_BASE_Q) - preload;
-int64_t ts2= av_rescale_q(next->dts, st2->time_base,
AV_TIME_BASE_Q) - preload2;
+ts = av_rescale_q(pkt ->dts, st ->time_base, AV_TIME_BASE_Q) -
preload;
+ts2= av_rescale_q(next->dts, st2->time_base, AV_TIME_BASE_Q) -
preload2;
if (ts == ts2) {
ts = ((uint64_t)pkt ->dts*st ->time_base.num*AV_TIME_BASE -
(uint64_t)preload *st ->time_base.den)*st2->time_base.den
- ((uint64_t)next->dts*st2->time_base.num*AV_TIME_BASE -
(uint64_t)preload2*st2->time_base.den)*st ->time_base.den;
--
2.21.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] avcodec: add delayer bitstream filter
On Thu, 27 Jun 2019, Andreas Håkon wrote: Hi Reimar, Minor note: I'd suggest a different name, "delayer" is too easily read as e.g. "de-layer". Could be something like add_delay for example. Good point! Or perhaps "timer" will be preferable. Ideas? Maybe it's too much work for little benefit, but instead of this a more generic "setts" bitstream filter might be implemented which can be used to set both PTS and DTS similar to how the setpts/asetpts filter works for frames. 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 2/3] lavc/mjpeg_parser: use ff_mjpeg_decode_header to parse frame info
Am Do., 27. Juni 2019 um 14:59 Uhr schrieb Zhong Li :
> +/* return the 8 bit start code value and update the search
> + state. Return -1 if no start code found */
> +static int find_frame_header_marker(const uint8_t **pbuf_ptr, const uint8_t
> *buf_end)
> +{
> +const uint8_t *buf_ptr;
> +unsigned int v, v2;
> +int val;
> +int skipped = 0;
> +
> +buf_ptr = *pbuf_ptr;
> +while (buf_end - buf_ptr > 1) {
> +v = *buf_ptr++;
> +v2 = *buf_ptr;
> +if ((v == 0xff) && buf_ptr < buf_end &&
> +((v2 >= SOF0) && (v2 <= SOF3)) ) {
> +val = *buf_ptr++;
> +goto found;
> +}
> +skipped++;
> +}
> +buf_ptr = buf_end;
> +val = -1;
> +found:
> +ff_dlog(NULL, "find_marker skipped %d bytes\n", skipped);
> +*pbuf_ptr = buf_ptr;
> +return val;
> +}
Sorry for not realizing this earlier (I searched for "SOF0"):
Why is this function duplicated?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec: Implement Acorn Replay IMA ADPCM decoder
Signed-off-by: Cameron Cawley
---
doc/general.texi| 1 +
libavcodec/Makefile | 1 +
libavcodec/adpcm.c | 14 ++
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/utils.c | 1 +
7 files changed, 26 insertions(+)
diff --git a/doc/general.texi b/doc/general.texi
index ed3cdfcf99..fbbbc24753 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1070,6 +1070,7 @@ following image formats are supported:
@item ADPCM Electronic Arts XAS @tab @tab X
@item ADPCM G.722@tab X @tab X
@item ADPCM G.726@tab X @tab X
+@item ADPCM IMA Acorn Replay @tab @tab X
@item ADPCM IMA AMV @tab @tab X
@tab Used in AMV files
@item ADPCM IMA Electronic Arts EACS @tab @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index edccd73037..9c0dd5d189 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -825,6 +825,7 @@ OBJS-$(CONFIG_ADPCM_G726_DECODER) += g726.o
OBJS-$(CONFIG_ADPCM_G726_ENCODER) += g726.o
OBJS-$(CONFIG_ADPCM_G726LE_DECODER) += g726.o
OBJS-$(CONFIG_ADPCM_G726LE_ENCODER) += g726.o
+OBJS-$(CONFIG_ADPCM_IMA_ACORN_DECODER)+= adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_AMV_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_APC_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_DAT4_DECODER) += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index ede0130bf1..1d4b4d2c22 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -594,6 +594,7 @@ static int get_nb_samples(AVCodecContext *avctx,
GetByteContext *gb,
switch (avctx->codec->id) {
case AV_CODEC_ID_ADPCM_4XM:
case AV_CODEC_ID_ADPCM_AGM:
+case AV_CODEC_ID_ADPCM_IMA_ACORN:
case AV_CODEC_ID_ADPCM_IMA_DAT4:
case AV_CODEC_ID_ADPCM_IMA_ISS: header_size = 4 * ch; break;
case AV_CODEC_ID_ADPCM_IMA_AMV: header_size = 8; break;
@@ -1412,6 +1413,18 @@ static int adpcm_decode_frame(AVCodecContext *avctx,
void *data,
}
}
break;
+case AV_CODEC_ID_ADPCM_IMA_ACORN:
+for (i=0; i<=st; i++) {
+bytestream2_skip(, 2); // TODO: What does this do?
+c->status[i].step_index = bytestream2_get_le16u();
+}
+
+for (n = nb_samples >> (1 - st); n > 0; n--) {
+int byte = bytestream2_get_byteu();
+*samples++ = adpcm_ima_expand_nibble(>status[0], byte & 0x0F,
6);
+*samples++ = adpcm_ima_expand_nibble(>status[st], byte >> 4,
6);
+}
+break;
case AV_CODEC_ID_ADPCM_IMA_AMV:
c->status[0].predictor = sign_extend(bytestream2_get_le16u(), 16);
c->status[0].step_index = bytestream2_get_byteu();
@@ -1796,6 +1809,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_R1,
sample_fmts_s16p, adpcm_ea_r1,
ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_R2, sample_fmts_s16p, adpcm_ea_r2,
"ADPCM Electronic Arts R2");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_R3, sample_fmts_s16p, adpcm_ea_r3,
"ADPCM Electronic Arts R3");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_XAS, sample_fmts_s16p, adpcm_ea_xas,
"ADPCM Electronic Arts XAS");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_ACORN, sample_fmts_s16,
adpcm_ima_acorn, "ADPCM IMA Acorn Replay");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_AMV, sample_fmts_s16, adpcm_ima_amv,
"ADPCM IMA AMV");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_APC, sample_fmts_s16, adpcm_ima_apc,
"ADPCM IMA CRYO APC");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DAT4,sample_fmts_s16, adpcm_ima_dat4,
"ADPCM IMA Eurocom DAT4");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39ce5..78177a1255 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -592,6 +592,7 @@ extern AVCodec ff_adpcm_g726_encoder;
extern AVCodec ff_adpcm_g726_decoder;
extern AVCodec ff_adpcm_g726le_encoder;
extern AVCodec ff_adpcm_g726le_decoder;
+extern AVCodec ff_adpcm_ima_acorn_decoder;
extern AVCodec ff_adpcm_ima_amv_decoder;
extern AVCodec ff_adpcm_ima_apc_decoder;
extern AVCodec ff_adpcm_ima_dat4_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 586bbbca4e..f2e8f27c75 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -542,6 +542,7 @@ enum AVCodecID {
AV_CODEC_ID_ADPCM_IMA_DAT4,
AV_CODEC_ID_ADPCM_MTAF,
AV_CODEC_ID_ADPCM_AGM,
+AV_CODEC_ID_ADPCM_IMA_ACORN,
/* AMR */
AV_CODEC_ID_AMR_NB = 0x12000,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 4d033c20ff..dc39b50e33 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2276,6 +2276,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("ADPCM AmuseGraphics Movie AGM"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id=
[FFmpeg-devel] [PATCH 2/2] avformat/rpl: Support files containing Replay IMA ADPCM audio
---
libavformat/rpl.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavformat/rpl.c b/libavformat/rpl.c
index dbbcd13b41..b4859320f4 100644
--- a/libavformat/rpl.c
+++ b/libavformat/rpl.c
@@ -121,6 +121,7 @@ static int rpl_read_header(AVFormatContext *s)
int error = 0;
const char *endptr;
char audio_type[RPL_LINE_LENGTH];
+char audio_codec[RPL_LINE_LENGTH];
uint32_t i;
@@ -189,7 +190,9 @@ static int rpl_read_header(AVFormatContext *s)
// ARMovie supports multiple audio tracks; I don't have any
// samples, though. This code will ignore additional tracks.
-audio_format = read_line_and_int(pb, ); // audio format ID
+error |= read_line(pb, line, sizeof(line));
+audio_format = read_int(line, , ); // audio format ID
+strcpy(audio_codec, endptr);
if (audio_format) {
ast = avformat_new_stream(s, NULL);
if (!ast)
@@ -229,6 +232,14 @@ static int rpl_read_header(AVFormatContext *s)
break;
}
}
+break;
+case 2:
+if (av_strcasecmp(audio_codec," adpcm") == 0) {
+ast->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_ACORN;
+} else {
+avpriv_report_missing_feature(s, "Audio format %"PRId32"
(%s)",
+ audio_format, audio_codec);
+}
// There are some other formats listed as legal per the spec;
// samples needed.
break;
--
2.11.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 1/3] avcodec/cfhd: remove unused function
On 27.06.2019, at 17:35, Vittorio Giovara wrote: > On Thu, Jun 27, 2019 at 9:44 AM Nicolas George wrote: > >> Kieran Kunhya (12019-06-27): >>> I'm happy to do it now that I am aware of the issue. I will do it when I >> am >>> at home in a few days. >> >> Thanks. I am sure Steven will not mind waiting a few days. >> >>> This absolutism is absurd. >> >> Do you have an example of situation where dead code is good? >> > > If i could add my 2 cents, for a reverse engineered codec it's important to > leave unused functions purely for documentation purposes, so that future > maintainers could implement and read about it right away, rather than > digging in a large and messy git history. > Additionally most compilers run passes that drop dead code already in a way > that does not affect runtime one bit. So I really don't see any gains in > removing these 14 lines of code. I'd note that intentionally dead code should at least have a comment, and maybe even a #if 0 would make sense (though has the disadvantage of not even compile-testing the code). In case of an actual bug like here I would say dead code if nothing else is a reminder of the bug, though admittedly a very poor one. Either way I suggest to discuss such things more relaxed, a few days more or less hardly matters and there might be useful insights from other people (of course I don't mean to delay non-controversial stuff nobody has any comments/objections on). Best regards, Reimar Döffinger ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add delayer bitstream filter
Hi Reimar, > Minor note: I'd suggest a different name, "delayer" is too easily read as > e.g. "de-layer". > Could be something like add_delay for example. Good point! Or perhaps "timer" will be preferable. Ideas? Regards. A.H. --- ___ 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] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
Am Do., 27. Juni 2019 um 16:28 Uhr schrieb Linjie Fu : > > Previously, media driver provided planar format(like 420 8 bit), but > for HEVC Range Extension (422/444 8/10 bit), the decoded image > is produced in packed format. (The question "why" and the answer "because Windows expects it" come to mind.) > Y210/AYUV/Y410 are packed formats which are needed in HEVC > Rext decoding for both VAAPI and QSV: > - Y210: 422 10 BIT > - AYUV: 444 8 BIT > - Y410: 444 10 BIT Could you explain the relation between an alpha channel and hevc? Imo, for this patch to be acceptable, a conversion function in libswscale is needed. Thank you, Carl Eugen ___ 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] lavc/mjpegdec: add function ff_mjpeg_decode_header
Am Do., 27. Juni 2019 um 14:59 Uhr schrieb Zhong Li :
> -if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt && !size_change) {
> +if (!(s->got_picture && s->interlaced && (s->bottom_field ==
> !s->interlace_polarity))) {
> +if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt && !s->size_change) {
Is this an (unrelated) bug fix or only vaapi-related?
I wonder if it should be in this patch for both cases.
> s->avctx->pix_fmt = s->hwaccel_pix_fmt;
> +s->size_change = 0;
Thank you, Carl Eugen
___
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/3] lavc/mjpeg_parser: use ff_mjpeg_decode_header to parse frame info
Am Do., 27. Juni 2019 um 14:59 Uhr schrieb Zhong Li :
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/mjpeg_parser.c | 158
> +-
> 1 file changed, 157 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
> index 07a6b2b..f59aa3e 100644
> --- a/libavcodec/mjpeg_parser.c
> +++ b/libavcodec/mjpeg_parser.c
> @@ -27,12 +27,131 @@
> */
>
> #include "parser.h"
> +#include "mjpeg.h"
> +#include "mjpegdec.h"
> +#include "get_bits.h"
>
> typedef struct MJPEGParserContext{
> ParseContext pc;
> +MJpegDecodeContext dec_ctx;
> int size;
> }MJPEGParserContext;
>
> +/* return the 8 bit start code value and update the search
> + state. Return -1 if no start code found */
> +static int find_frame_header_marker(const uint8_t **pbuf_ptr, const uint8_t
> *buf_end)
> +{
> +const uint8_t *buf_ptr;
> +unsigned int v, v2;
> +int val;
> +int skipped = 0;
> +
> +buf_ptr = *pbuf_ptr;
> +while (buf_end - buf_ptr > 1) {
> +v = *buf_ptr++;
> +v2 = *buf_ptr;
> +if ((v == 0xff) && buf_ptr < buf_end &&
> +((v2 >= SOF0) && (v2 <= SOF3)) ) {
It may be just me but there are too many parentheses in these
lines (and not enough braces in the rest of the patch).
> +val = *buf_ptr++;
> +goto found;
> +}
> +skipped++;
> +}
> +buf_ptr = buf_end;
> +val = -1;
> +found:
> +ff_dlog(NULL, "find_marker skipped %d bytes\n", skipped);
> +*pbuf_ptr = buf_ptr;
> +return val;
> +}
> +
> +static void jpeg_set_interlace_polarity(AVCodecContext *avctx,
> MJpegDecodeContext *dec_ctx)
> +{
> +if (avctx->extradata_size > 14
> +&& AV_RL32(avctx->extradata) == 0x2C
> +&& AV_RL32(avctx->extradata+4) == 0x18) {
> +if (avctx->extradata[12] == 1) /* NTSC */
> +dec_ctx->interlace_polarity = 1;
> +if (avctx->extradata[12] == 2) /* PAL */
> +dec_ctx->interlace_polarity = 0;
> +}
> +}
> +
> +static int jpeg_parse_header(AVCodecParserContext *s, AVCodecContext *avctx,
> + const uint8_t *buf, int buf_size)
> +{
> +MJPEGParserContext *m = s->priv_data;
> +MJpegDecodeContext *dec_ctx = >dec_ctx;
> +int start_code;
> +const uint8_t *start, *end;
> +int ret=0;
> +
> +start = buf;
> +end = buf + buf_size;
> +start_code = find_frame_header_marker(, end);
> +if (start_code < 0) {
> +av_log(avctx, AV_LOG_ERROR, "parse header failure:"
> +"can't find supported marker type (%x)\n", start_code);
> +
> +return -1;
> +} else
> +av_log(avctx, AV_LOG_DEBUG, "marker=%x\n", start_code);
> +
> +jpeg_set_interlace_polarity(avctx, dec_ctx);
> +init_get_bits8(_ctx->gb, start, end - start);
> +dec_ctx->avctx = avctx;
> +
> +switch(start_code) {
> +case SOF0:
> +avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_BASELINE_DCT;
> +dec_ctx->lossless= 0;
> +dec_ctx->progressive = 0;
> +break;
> +case SOF1:
> +avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_EXTENDED_SEQUENTIAL_DCT;
> +dec_ctx->lossless= 0;
> +dec_ctx->progressive = 0;
> +break;
> +case SOF2:
> +avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_PROGRESSIVE_DCT;
> +dec_ctx->lossless= 0;
> +dec_ctx->progressive = 1;
> +break;
> +case SOF3:
> +avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_LOSSLESS;
> +dec_ctx->lossless= 1;
> +dec_ctx->progressive = 0;
> +break;
> +default:
> + assert(0);
> +}
> +
> +ret = ff_mjpeg_decode_header(dec_ctx);
> +if (ret < 0) {
> +av_log(avctx, AV_LOG_WARNING, "Failed to parse header\n");
> +return ret;
> +}
> +
> +s->height = dec_ctx->height;
> +s->width = dec_ctx->width;
> +s->coded_height = s->height;
> +s->coded_width = s->width;
> +s->format = avctx->pix_fmt;
> +s->pict_type= AV_PICTURE_TYPE_I;
> +s->key_frame= 1;
> +
> +if (dec_ctx->interlaced) {
> +if (dec_ctx->bottom_field)
> +s->field_order = AV_FIELD_BB;
> +else
> +s->field_order = AV_FIELD_TT;
> +} else
> +s->field_order = AV_FIELD_PROGRESSIVE;
> +
> +return 0;
> +}
> +
> +
> /**
> * Find the end of the current frame in the bitstream.
> * @return the position of the first byte of the next frame, or -1
> @@ -99,6 +218,40 @@ static int find_frame_end(MJPEGParserContext *m, const
> uint8_t *buf, int buf_siz
> return END_NOT_FOUND;
> }
>
> +static av_cold int jpeg_parse_init(AVCodecParserContext *s)
> +{
> +MJPEGParserContext *m = s->priv_data;
> +MJpegDecodeContext *dec_ctx = >dec_ctx;
> +
> +if (!dec_ctx->picture_ptr) {
> +dec_ctx->picture = av_frame_alloc();
> +if (!dec_ctx->picture)
> +
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: temp_file usage for master playlist and vtt playlist
ping 2019.06.24. 18:01 keltezéssel, Bodecs Bela írta: Dear All, currently master playlist and subtitle playlist creation does not use temporary files even when temp_file flag is set. Most of the use cases it is not a problem because master playlist creation happens once on the beginning of the whole process. But if master playlist is periodically re-created because of master_pl_refresh_rate is set, non-atomic playlist creation may cause problems in case of live streaming. This poblem (i.e non-atomic playlist creation) may also apply for subtitle playlist (vtt) creation in live streaming. This patch correct this behavior by adding missing functionality. please review this patch. thank you in advance, best regards, Bela ___ 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 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
Am Do., 27. Juni 2019 um 16:31 Uhr schrieb Linjie Fu : > > Currently, ChromaFormat passed to libmfx is set to YUV42O by default. > > Modify to choose ChromaFormat according to fourCC. Sorry if I misunderstand: Doesn't 3/5 depend on this patch? Carl Eugen ___ 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 11/12] lavf/sccdec: fix timestamps and demux one eai608 frame at a time
On 11/25/18, Paul B Mahol wrote: > On 7/4/18, Baptiste Coudurier wrote: >> --- >> libavformat/sccdec.c | 100 --- >> 1 file changed, 56 insertions(+), 44 deletions(-) >> > > Will those scc patches be applied? > This one breaks FATE. Forcing positive first timestamp drops initial captions. ___ 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] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
On Thu, Jun 27, 2019 at 10:26:46PM -0400, Linjie Fu wrote: > Previously, media driver provided planar format(like 420 8 bit), but > for HEVC Range Extension (422/444 8/10 bit), the decoded image is > produced in packed format. > > Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding > for both VAAPI and QSV: > - Y210: 422 10 BIT > - AYUV: 444 8 BIT > - Y410: 444 10 BIT > > Signed-off-by: Linjie Fu > --- > libavutil/pixdesc.c | 62 > + > libavutil/pixfmt.h | 6 ++ > libavutil/version.h | 2 +- > 3 files changed, 69 insertions(+), 1 deletion(-) this breaks TESTpixelutils --- ./tests/ref/fate/pixelutils 2019-06-27 21:08:23.873241529 +0200 +++ tests/data/fate/pixelutils 2019-06-27 21:58:45.501332809 +0200 @@ -1,60 +0,0 @@ -[OK] [UU] SAD [random] 2x2=409 ref=409 -[OK] [UU] SAD [random] 4x4=1370 ref=1370 -[OK] [UU] SAD [random] 8x8=5178 ref=5178 -[OK] [UU] SAD [random] 16x16=20946 ref=20946 -[OK] [UU] SAD [random] 32x32=83150 ref=83150 -[OK] [AU] SAD [random] 2x2=320 ref=320 -[OK] [AU] SAD [random] 4x4=1522 ref=1522 -[OK] [AU] SAD [random] 8x8=5821 ref=5821 -[OK] [AU] SAD [random] 16x16=21951 ref=21951 -[OK] [AU] SAD [random] 32x32=86983 ref=86983 -[OK] [AA] SAD [random] 2x2=276 ref=276 -[OK] [AA] SAD [random] 4x4=1521 ref=1521 -[OK] [AA] SAD [random] 8x8=5130 ref=5130 -[OK] [AA] SAD [random] 16x16=20775 ref=20775 -[OK] [AA] SAD [random] 32x32=83402 ref=83402 -[OK] [UU] SAD [max] 2x2=1020 ref=1020 -[OK] [UU] SAD [max] 4x4=4080 ref=4080 -[OK] [UU] SAD [max] 8x8=16320 ref=16320 -[OK] [UU] SAD [max] 16x16=65280 ref=65280 -[OK] [UU] SAD [max] 32x32=261120 ref=261120 -[OK] [AU] SAD [max] 2x2=1020 ref=1020 -[OK] [AU] SAD [max] 4x4=4080 ref=4080 -[OK] [AU] SAD [max] 8x8=16320 ref=16320 -[OK] [AU] SAD [max] 16x16=65280 ref=65280 -[OK] [AU] SAD [max] 32x32=261120 ref=261120 -[OK] [AA] SAD [max] 2x2=1020 ref=1020 -[OK] [AA] SAD [max] 4x4=4080 ref=4080 -[OK] [AA] SAD [max] 8x8=16320 ref=16320 -[OK] [AA] SAD [max] 16x16=65280 ref=65280 -[OK] [AA] SAD [max] 32x32=261120 ref=261120 -[OK] [UU] SAD [min] 2x2=0 ref=0 -[OK] [UU] SAD [min] 4x4=0 ref=0 -[OK] [UU] SAD [min] 8x8=0 ref=0 -[OK] [UU] SAD [min] 16x16=0 ref=0 -[OK] [UU] SAD [min] 32x32=0 ref=0 -[OK] [AU] SAD [min] 2x2=0 ref=0 -[OK] [AU] SAD [min] 4x4=0 ref=0 -[OK] [AU] SAD [min] 8x8=0 ref=0 -[OK] [AU] SAD [min] 16x16=0 ref=0 -[OK] [AU] SAD [min] 32x32=0 ref=0 -[OK] [AA] SAD [min] 2x2=0 ref=0 -[OK] [AA] SAD [min] 4x4=0 ref=0 -[OK] [AA] SAD [min] 8x8=0 ref=0 -[OK] [AA] SAD [min] 16x16=0 ref=0 -[OK] [AA] SAD [min] 32x32=0 ref=0 -[OK] [UU] SAD [small] 2x2=400 ref=400 -[OK] [AU] SAD [small] 2x2=384 ref=384 -[OK] [AA] SAD [small] 2x2=409 ref=409 -[OK] [UU] SAD [small] 4x4=1144 ref=1144 -[OK] [AU] SAD [small] 4x4=1156 ref=1156 -[OK] [AA] SAD [small] 4x4=1086 ref=1086 -[OK] [UU] SAD [small] 8x8=6510 ref=6510 -[OK] [AU] SAD [small] 8x8=5755 ref=5755 -[OK] [AA] SAD [small] 8x8=6156 ref=6156 -[OK] [UU] SAD [small] 16x16=19490 ref=19490 -[OK] [AU] SAD [small] 16x16=21037 ref=21037 -[OK] [AA] SAD [small] 16x16=22986 ref=22986 -[OK] [UU] SAD [small] 32x32=86550 ref=86550 -[OK] [AU] SAD [small] 32x32=83656 ref=83656 -[OK] [AA] SAD [small] 32x32=85164 ref=85164 Test pixelutils failed. Look at tests/data/fate/pixelutils.err for details. make: *** [fate-pixelutils] Error 134 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato 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/cfhd: remove unused function
On 6/27/2019 10:44 AM, Nicolas George wrote: > Kieran Kunhya (12019-06-27): >> I'm happy to do it now that I am aware of the issue. I will do it when I am >> at home in a few days. > > Thanks. I am sure Steven will not mind waiting a few days. > >> This absolutism is absurd. > > Do you have an example of situation where dead code is good? At least for this specific case, not littering the git history with commits removing something that's going to be readded in a couple days when a proper fix to a known bug is implemented instead, and not ruining the usefulness of git blame for debug/bisect/backtracking purposes. ___ 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/cfhd: remove unused function
On Thu, Jun 27, 2019 at 9:44 AM Nicolas George wrote: > Kieran Kunhya (12019-06-27): > > I'm happy to do it now that I am aware of the issue. I will do it when I > am > > at home in a few days. > > Thanks. I am sure Steven will not mind waiting a few days. > > > This absolutism is absurd. > > Do you have an example of situation where dead code is good? > If i could add my 2 cents, for a reverse engineered codec it's important to leave unused functions purely for documentation purposes, so that future maintainers could implement and read about it right away, rather than digging in a large and messy git history. Additionally most compilers run passes that drop dead code already in a way that does not affect runtime one bit. So I really don't see any gains in removing these 14 lines of code. -- Vittorio ___ 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] Add DICOM Support
On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote: > > On 6/26/19 4:37 PM, Michael Niedermayer wrote: > >On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: > >>On 6/26/19, Michael Niedermayer wrote: > >>>On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: > On 6/25/19 2:12 AM, Michael Niedermayer wrote: > >On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: > >>Hi! > >> > >> The code is to add DICOM Support. The patch is only for > >>uncompressed > >>dicom files using explicit value representation. I would extend it, once > >>i > >>clarify some doubts. As dicom image files contain lots of metadata > >>about > >>the patient. So, should i display that data while demuxing or should i > >>ignore and only demux the image data ?. In the current patch, i have > >>made an > >>option "-metadata", which when used will print the data on the terminal > >>while demuxing. > >metadata should be exported to be usable by applications. > > > >For teh API design a one test is that it should be possible to have a > >dicom file as input and a format with similar features as output and not > >loose any significant data. > >Printing to the terminal cannot achieve that easily. > So, should i export it to a csv file ? > >>>does it fit into the metadata system we have ? > >>> > >>To clarify, you mean frame metadata system? > >data that is specific to a frame would belong in the frame metadata > >data that is specific to a stream would belong into that streams metadata > >data that is specific to the container would belong to its metadata > > > >iam not sure if multiple streams or frames can be in a single dicom > >"container" / file. If they can then it should be clear what goes where > >if not then all 3 options would from the point of view of dicom be the > >same. And in that case what is most convenient for interoperation with > >other formats should be picked. That is lets introduce the least amount > >of differences to how similar data is handled in other formats > > Dicom files contain multiple frames, but number of streams is always one > (video) like GIF,( I haven't done multiframe support yet i am working on it > ), The data specific to image/frames/pixels can be fit in the three > categories of our metadata system, > but their is extradata in DICOM files > like : patient_name, medical_device_name , medical_procedure_done, > study_date why could this not be fit in metadata ? thx [...] -- 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/3] avcodec/cfhd: remove unused function
> > If it is so easy, you could do it instead of arguing. If it is not so > easy, you cannot demand somebody do it. > I'm happy to do it now that I am aware of the issue. I will do it when I am at home in a few days. > > It is beyond comprehension how removing more code and making the > situation > > worse improves things. > > Dead code is never good. > This absolutism is absurd. Kieran ___ 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/cfhd: remove unused function
Kieran Kunhya (12019-06-27): > I'm happy to do it now that I am aware of the issue. I will do it when I am > at home in a few days. Thanks. I am sure Steven will not mind waiting a few days. > This absolutism is absurd. Do you have an example of situation where dead code is good? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] lavc/qsv: add decode support for HEVC Rext
Add support for YUV422P/YUV422P10, YUV444P/YUV444P10 in qsv_map_pixfmt.
Allow qsv to choose correct fourc from format.
Add support for YUYV422/Y210/AYUV/Y410 to map frame to surface and
allowed hwdownload.
HEVC Rext decode is supported on ICL+ platform.
Cmdline for 444 8 bit decode:
ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD128 -c:v
hevc_qsv -load_plugin hevc_hw -i HEVCRext_444_8bit.bin -vf
hwdownload,format=ayuv -pix_fmt ayuv -vsync passthrough out.yuv
Signed-off-by: Linjie Fu
---
libavcodec/qsv.c | 12
libavutil/hwcontext_qsv.c | 25 ++---
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 986d4f6..87f4aae 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -225,6 +225,18 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t
*fourcc)
case AV_PIX_FMT_NV12:
*fourcc = MFX_FOURCC_NV12;
return AV_PIX_FMT_NV12;
+case AV_PIX_FMT_YUV422P:
+*fourcc = MFX_FOURCC_YUY2;
+return AV_PIX_FMT_YUYV422;
+case AV_PIX_FMT_YUV422P10:
+*fourcc = MFX_FOURCC_Y210;
+return AV_PIX_FMT_Y210LE;
+case AV_PIX_FMT_YUV444P:
+*fourcc = MFX_FOURCC_AYUV;
+return AV_PIX_FMT_AYUV;
+case AV_PIX_FMT_YUV444P10:
+*fourcc = MFX_FOURCC_Y410;
+return AV_PIX_FMT_Y410LE;
case AV_PIX_FMT_YUV420P10:
case AV_PIX_FMT_P010:
*fourcc = MFX_FOURCC_P010;
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 59e4ed9..f0be4bb 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -103,6 +103,14 @@ static const struct {
{ AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4 },
{ AV_PIX_FMT_P010, MFX_FOURCC_P010 },
{ AV_PIX_FMT_PAL8, MFX_FOURCC_P8 },
+{ AV_PIX_FMT_YUYV422,
+ MFX_FOURCC_YUY2 },
+{ AV_PIX_FMT_Y210LE,
+ MFX_FOURCC_Y210 },
+{ AV_PIX_FMT_AYUV,
+ MFX_FOURCC_AYUV },
+{ AV_PIX_FMT_Y410LE,
+ MFX_FOURCC_Y410 },
};
static uint32_t qsv_fourcc_from_pix_fmt(enum AVPixelFormat pix_fmt)
@@ -760,20 +768,31 @@ static int map_frame_to_surface(const AVFrame *frame,
mfxFrameSurface1 *surface)
surface->Data.Y = frame->data[0];
surface->Data.UV = frame->data[1];
break;
-
case AV_PIX_FMT_YUV420P:
surface->Data.Y = frame->data[0];
surface->Data.U = frame->data[1];
surface->Data.V = frame->data[2];
break;
-
case AV_PIX_FMT_BGRA:
+case AV_PIX_FMT_AYUV:
surface->Data.B = frame->data[0];
surface->Data.G = frame->data[0] + 1;
surface->Data.R = frame->data[0] + 2;
surface->Data.A = frame->data[0] + 3;
break;
-
+case AV_PIX_FMT_YUYV422:
+surface->Data.Y = frame->data[0];
+surface->Data.U = frame->data[0] + 1;
+surface->Data.V = frame->data[0] + 3;
+break;
+case AV_PIX_FMT_Y210LE:
+surface->Data.Y16 = frame->data[0];
+surface->Data.U16 = frame->data[0] + 2;
+surface->Data.V16 = frame->data[0] + 6;
+break;
+case AV_PIX_FMT_Y410LE:
+surface->Data.U = frame->data[0];
+break;
default:
return MFX_ERR_UNSUPPORTED;
}
--
2.7.4
___
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] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Thursday, June 27, 2019 22:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] lavu/pixfmt: add Y210/AYUV/Y410
> pixel formats
>
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 8b54c94..6a6a36a 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -209,6 +209,12 @@ enum AVPixelFormat {
> >
> > AV_PIX_FMT_YVYU422, ///< packed YUV 4:2:2, 16bpp, Y0 Cr Y1 Cb
> >
> > +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> > little-
> endian
> > +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, big-
> endian
> > +AV_PIX_FMT_AYUV, ///< packed YUV 4:4:4, 32bpp, A Y Cb Cr
> > +AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A, little-
> endian
> > +AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A, big-
> endian
>
> This is an ABI break, as you're shifting the enum values for every entry
> under these.
>
> You need to add new values at the end, right above AV_PIX_FMT_NB.
>
Oh yes ABI break.
will follow, 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] Avoid integer to float point domain crossing penalties
On 6/27/2019 3:01 AM, Adrian Tong wrote:
> Anyone interested in reviewing this patch ?
>
> Thanks
> -Adrian
>
> On Mon, 24 Jun 2019 at 13:57, wrote:
>
>> From: Adrian Tong
>>
>> On internal benchmark, I see a noisy-level difference (more likely to be
>> an improvement) in ff_h264_decode_mb_cabac which calls this function.
>> ---
>> libavutil/x86/intreadwrite.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavutil/x86/intreadwrite.h b/libavutil/x86/intreadwrite.h
>> index 4061d19231..df0bf45ae1 100644
>> --- a/libavutil/x86/intreadwrite.h
>> +++ b/libavutil/x86/intreadwrite.h
>> @@ -68,8 +68,8 @@ static av_always_inline void AV_COPY128(void *d, const
>> void *s)
>> {
>> struct v {uint64_t v[2];};
>>
>> -__asm__("movaps %1, %%xmm0 \n\t"
>> -"movaps %%xmm0, %0 \n\t"
>> +__asm__("movdqa %1, %%xmm0 \n\t"
>> +"movdqa %%xmm0, %0 \n\t"
movdqa is an sse2 instruction, and this function is used when sse is the
minimum required instruction set configured in the compiler. There's no
warranty that sse2 will be present at runtime on builds that use this
function right now.
Either change the function's preprocessor check from __SSE__ to
__SSE2__, or use new wrappers here to choose between movaps and movdqa
depending on __SSE2__ being defined or not. In both cases, movdqa will
be used only on builds where sse2 support is required.
>> : "=m"(*(struct v*)d)
>> : "m" (*(const struct v*)s)
>> : "xmm0");
>> --
>> 2.20.1 (Apple Git-117)
>>
>>
> ___
> 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 1/5] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
Previously, media driver provided planar format(like 420 8 bit), but
for HEVC Range Extension (422/444 8/10 bit), the decoded image is
produced in packed format.
Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding
for both VAAPI and QSV:
- Y210: 422 10 BIT
- AYUV: 444 8 BIT
- Y410: 444 10 BIT
Signed-off-by: Linjie Fu
---
libavutil/pixdesc.c | 62 +
libavutil/pixfmt.h | 6 ++
libavutil/version.h | 2 +-
3 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index b97b066..bde49f9 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -205,6 +205,68 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
{ 0, 4, 1, 0, 8, 3, 7, 2 },/* V */
},
},
+[AV_PIX_FMT_Y210LE] = {
+.name = "y210le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 6, 10, 1, 9, 1 },/* Y */
+{ 0, 8, 1, 6, 10, 3, 9, 2 },/* U */
+{ 0, 8, 3, 6, 10, 3, 9, 4 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA,
+},
+[AV_PIX_FMT_Y210BE] = {
+.name = "y210be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 6, 10, 1, 9, 1 },/* Y */
+{ 0, 8, 1, 6, 10, 3, 9, 2 },/* U */
+{ 0, 8, 3, 6, 10, 3, 9, 4 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_ALPHA,
+},
+[AV_PIX_FMT_AYUV] = {
+.name = "ayuv",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 1, 0, 8, 3, 7, 2 },/* Y */
+{ 0, 4, 2, 0, 8, 3, 7, 1 },/* U */
+{ 0, 4, 3, 0, 8, 3, 7, 3 },/* V */
+{ 0, 4, 0, 0, 8, 3, 7, 4 },/* A */
+},
+},
+[AV_PIX_FMT_Y410LE] = {
+.name = "y410le",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 1, 0, 10, 3, 9, 2 },/* Y */
+{ 0, 4, 0, 0, 10, 3, 9, 1 },/* U */
+{ 0, 4, 2, 0, 10, 3, 9, 3 },/* V */
+{ 0, 4, 3, 0, 2, 3, 1, 4 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA,
+},
+[AV_PIX_FMT_Y410BE] = {
+.name = "y410be",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 1, 0, 10, 3, 9, 2 },/* Y */
+{ 0, 4, 0, 0, 10, 3, 9, 1 },/* U */
+{ 0, 4, 2, 0, 10, 3, 9, 3 },/* V */
+{ 0, 4, 3, 0, 2, 3, 1, 4 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_ALPHA,
+},
[AV_PIX_FMT_RGB24] = {
.name = "rgb24",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 8b54c94..6a6a36a 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -209,6 +209,12 @@ enum AVPixelFormat {
AV_PIX_FMT_YVYU422, ///< packed YUV 4:2:2, 16bpp, Y0 Cr Y1 Cb
+AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
little-endian
+AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, big-endian
+AV_PIX_FMT_AYUV, ///< packed YUV 4:4:4, 32bpp, A Y Cb Cr
+AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A,
little-endian
+AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A, big-endian
+
AV_PIX_FMT_YA16BE, ///< 16 bits gray, 16 bits alpha (big-endian)
AV_PIX_FMT_YA16LE, ///< 16 bits gray, 16 bits alpha (little-endian)
diff --git a/libavutil/version.h b/libavutil/version.h
index dccbb38..e16b93e 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 29
+#define LIBAVUTIL_VERSION_MINOR 30
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.7.4
___
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/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
Signed-off-by: Linjie Fu
---
libavutil/hwcontext_vaapi.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 4227c3c..6378d0e 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = {
#endif
MAP(UYVY, YUV422, UYVY422, 0),
MAP(YUY2, YUV422, YUYV422, 0),
+#ifdef VA_FOURCC_Y210
+MAP(Y210, YUV422_10,Y210LE, 0),
+#endif
+#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
+MAP(AYUV, AYUV, AYUV, 0),
+#ifdef VA_FOURCC_Y410
+MAP(Y410, YUV444_10,Y410LE, 0),
+#endif
MAP(411P, YUV411, YUV411P, 0),
MAP(422V, YUV422, YUV440P, 0),
MAP(444P, YUV444, YUV444P, 0),
--
2.7.4
___
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/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Friday, June 28, 2019 10:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
>
> Signed-off-by: Linjie Fu
> ---
> libavutil/hwcontext_vaapi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> 4227c3c..6378d0e 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor
> vaapi_format_map[] = { #endif
> MAP(UYVY, YUV422, UYVY422, 0),
> MAP(YUY2, YUV422, YUYV422, 0),
> +#ifdef VA_FOURCC_Y210
> +MAP(Y210, YUV422_10,Y210LE, 0),
> +#endif
> +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
Probably you want to add "#ifdef VA_FOURCC_AYUV" too.
And would better to #undef VA_RT_FORMAT_AYUV here once map is done.
(If you want to get a longer life cycle, would better define it outside)
> +MAP(AYUV, AYUV, AYUV, 0),
> +#ifdef VA_FOURCC_Y410
> +MAP(Y410, YUV444_10,Y410LE, 0),
> +#endif
> MAP(411P, YUV411, YUV411P, 0),
> MAP(422V, YUV422, YUV440P, 0),
> MAP(444P, YUV444, YUV444P, 0),
> --
> 2.7.4
___
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/5] libav/qsv: set Info.Shift according to the setting in desc
Currently, Info.Shift in libmfx is set according to the depth of the pixfmt. As QSV now supports Y410 (depth > 8 but shift = 0), it doesn't work any more. Modify to set Info.Shift according to the setting in desc. Signed-off-by: Linjie Fu --- libavcodec/qsvdec.c | 2 +- libavutil/hwcontext_qsv.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index 7650325..0f45a34 100644 --- a/libavcodec/qsvdec.c +++ b/libavcodec/qsvdec.c @@ -208,7 +208,7 @@ static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q) param.mfx.FrameInfo.BitDepthLuma = desc->comp[0].depth; param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth; -param.mfx.FrameInfo.Shift = desc->comp[0].depth > 8; +param.mfx.FrameInfo.Shift = desc->comp[0].shift > 0; param.mfx.FrameInfo.FourCC = q->fourcc; param.mfx.FrameInfo.Width = frame_width; param.mfx.FrameInfo.Height = frame_height; diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index f0be4bb..ab484b6 100644 --- a/libavutil/hwcontext_qsv.c +++ b/libavutil/hwcontext_qsv.c @@ -323,7 +323,7 @@ static int qsv_init_surface(AVHWFramesContext *ctx, mfxFrameSurface1 *surf) surf->Info.BitDepthLuma = desc->comp[0].depth; surf->Info.BitDepthChroma = desc->comp[0].depth; -surf->Info.Shift = desc->comp[0].depth > 8; +surf->Info.Shift = desc->comp[0].shift > 0; if (desc->log2_chroma_w && desc->log2_chroma_h) surf->Info.ChromaFormat = MFX_CHROMAFORMAT_YUV420; -- 2.7.4 ___ 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/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
Modify to choose ChromaFormat according to fourCC.
Signed-off-by: Linjie Fu
---
libavcodec/qsvdec.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 46aa2d6..7650325 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -40,6 +40,7 @@
#include "qsv.h"
#include "qsv_internal.h"
#include "qsvdec.h"
+#include
const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
&(const AVCodecHWConfigInternal) {
@@ -211,7 +212,24 @@ static int qsv_decode_init(AVCodecContext *avctx,
QSVContext *q)
param.mfx.FrameInfo.FourCC = q->fourcc;
param.mfx.FrameInfo.Width = frame_width;
param.mfx.FrameInfo.Height = frame_height;
-param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
+
+switch (q->fourcc) {
+case VA_FOURCC_YUY2:
+#ifdef VA_FOURCC_Y210
+case VA_FOURCC_Y210:
+#endif
+param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV422;
+break;
+case VA_FOURCC_AYUV:
+#ifdef VA_FOURCC_Y410
+case VA_FOURCC_Y410:
+#endif
+param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV444;
+break;
+default:
+param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
+break;
+}
switch (avctx->field_order) {
case AV_FIELD_PROGRESSIVE:
--
2.7.4
___
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] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
On 6/27/2019 11:26 PM, Linjie Fu wrote:
> Previously, media driver provided planar format(like 420 8 bit), but
> for HEVC Range Extension (422/444 8/10 bit), the decoded image is
> produced in packed format.
>
> Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding
> for both VAAPI and QSV:
> - Y210: 422 10 BIT
> - AYUV: 444 8 BIT
> - Y410: 444 10 BIT
>
> Signed-off-by: Linjie Fu
> ---
> libavutil/pixdesc.c | 62
> +
> libavutil/pixfmt.h | 6 ++
> libavutil/version.h | 2 +-
> 3 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index b97b066..bde49f9 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -205,6 +205,68 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> { 0, 4, 1, 0, 8, 3, 7, 2 },/* V */
> },
> },
> +[AV_PIX_FMT_Y210LE] = {
> +.name = "y210le",
> +.nb_components = 3,
> +.log2_chroma_w = 1,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 6, 10, 1, 9, 1 },/* Y */
> +{ 0, 8, 1, 6, 10, 3, 9, 2 },/* U */
> +{ 0, 8, 3, 6, 10, 3, 9, 4 },/* V */
> +},
> +.flags = AV_PIX_FMT_FLAG_ALPHA,
> +},
> +[AV_PIX_FMT_Y210BE] = {
> +.name = "y210be",
> +.nb_components = 3,
> +.log2_chroma_w = 1,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 6, 10, 1, 9, 1 },/* Y */
> +{ 0, 8, 1, 6, 10, 3, 9, 2 },/* U */
> +{ 0, 8, 3, 6, 10, 3, 9, 4 },/* V */
> +},
> +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_ALPHA,
> +},
> +[AV_PIX_FMT_AYUV] = {
> +.name = "ayuv",
> +.nb_components = 4,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 1, 0, 8, 3, 7, 2 },/* Y */
> +{ 0, 4, 2, 0, 8, 3, 7, 1 },/* U */
> +{ 0, 4, 3, 0, 8, 3, 7, 3 },/* V */
> +{ 0, 4, 0, 0, 8, 3, 7, 4 },/* A */
> +},
> +},
> +[AV_PIX_FMT_Y410LE] = {
> +.name = "y410le",
> +.nb_components = 4,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 1, 0, 10, 3, 9, 2 },/* Y */
> +{ 0, 4, 0, 0, 10, 3, 9, 1 },/* U */
> +{ 0, 4, 2, 0, 10, 3, 9, 3 },/* V */
> +{ 0, 4, 3, 0, 2, 3, 1, 4 },/* A */
> +},
> +.flags = AV_PIX_FMT_FLAG_ALPHA,
> +},
> +[AV_PIX_FMT_Y410BE] = {
> +.name = "y410be",
> +.nb_components = 4,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 1, 0, 10, 3, 9, 2 },/* Y */
> +{ 0, 4, 0, 0, 10, 3, 9, 1 },/* U */
> +{ 0, 4, 2, 0, 10, 3, 9, 3 },/* V */
> +{ 0, 4, 3, 0, 2, 3, 1, 4 },/* A */
> +},
> +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_ALPHA,
> +},
> [AV_PIX_FMT_RGB24] = {
> .name = "rgb24",
> .nb_components = 3,
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 8b54c94..6a6a36a 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -209,6 +209,12 @@ enum AVPixelFormat {
>
> AV_PIX_FMT_YVYU422, ///< packed YUV 4:2:2, 16bpp, Y0 Cr Y1 Cb
>
> +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> little-endian
> +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> big-endian
> +AV_PIX_FMT_AYUV, ///< packed YUV 4:4:4, 32bpp, A Y Cb Cr
> +AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A,
> little-endian
> +AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A, big-endian
This is an ABI break, as you're shifting the enum values for every entry
under these.
You need to add new values at the end, right above AV_PIX_FMT_NB.
> +
> AV_PIX_FMT_YA16BE, ///< 16 bits gray, 16 bits alpha (big-endian)
> AV_PIX_FMT_YA16LE, ///< 16 bits gray, 16 bits alpha (little-endian)
>
> diff --git a/libavutil/version.h b/libavutil/version.h
> index dccbb38..e16b93e 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
> */
>
> #define LIBAVUTIL_VERSION_MAJOR 56
> -#define LIBAVUTIL_VERSION_MINOR 29
> +#define LIBAVUTIL_VERSION_MINOR 30
> #define LIBAVUTIL_VERSION_MICRO 100
>
> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: temp_file usage for master playlist and vtt playlist
> 在 2019年6月28日，04:36，Bodecs Bela 写道： > > ping Wait, i’m testing it. > > 2019.06.24. 18:01 keltezéssel, Bodecs Bela írta: >> Dear All, >> >> currently master playlist and subtitle playlist creation does not use >> temporary files even when temp_file flag is set. Most of the use cases >> it is not a problem because master playlist creation happens once on the >> beginning of the whole process. But if master playlist is periodically >> re-created because of master_pl_refresh_rate is set, non-atomic playlist >> creation may cause problems in case of live streaming. This poblem (i.e >> non-atomic playlist >> creation) may also apply for subtitle playlist (vtt) creation in live >> streaming. >> This patch correct this behavior by adding missing functionality. >> >> please review this patch. >> >> thank you in advance, >> >> best regards, >> >> Bela >> >> >> ___ >> 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". Thanks Steven ___ 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] libavformat/mux: Fix mixed delarations and code
On 6/27/2019 2:47 PM, Andreas Rheinhardt wrote:
> This commit fixes mixed declarations and code introduced in 1889e316.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Sorry for the oversight.
>
> libavformat/mux.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 5e1ecd8485..21f10caf53 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -1005,10 +1005,11 @@ static int interleave_compare_dts(AVFormatContext *s,
> AVPacket *next,
> int preload = st ->codecpar->codec_type == AVMEDIA_TYPE_AUDIO;
> int preload2 = st2->codecpar->codec_type == AVMEDIA_TYPE_AUDIO;
> if (preload != preload2) {
> +int64_t ts, ts2;
> preload *= s->audio_preload;
> preload2 *= s->audio_preload;
> -int64_t ts = av_rescale_q(pkt ->dts, st ->time_base,
> AV_TIME_BASE_Q) - preload;
> -int64_t ts2= av_rescale_q(next->dts, st2->time_base,
> AV_TIME_BASE_Q) - preload2;
> +ts = av_rescale_q(pkt ->dts, st ->time_base, AV_TIME_BASE_Q) -
> preload;
> +ts2= av_rescale_q(next->dts, st2->time_base, AV_TIME_BASE_Q) -
> preload2;
> if (ts == ts2) {
> ts = ((uint64_t)pkt ->dts*st ->time_base.num*AV_TIME_BASE -
> (uint64_t)preload *st ->time_base.den)*st2->time_base.den
> - ((uint64_t)next->dts*st2->time_base.num*AV_TIME_BASE -
> (uint64_t)preload2*st2->time_base.den)*st ->time_base.den;
Pushed, 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 1/5] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
On Fri, Jun 28, 2019 at 1:26 AM James Darnley wrote: > > On 2019-06-28 04:26, Linjie Fu wrote: > > Previously, media driver provided planar format(like 420 8 bit), but > > for HEVC Range Extension (422/444 8/10 bit), the decoded image is > > produced in packed format. > > > > Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding > > for both VAAPI and QSV: > > - Y210: 422 10 BIT > > - AYUV: 444 8 BIT > > - Y410: 444 10 BIT > > > > > Why am I suspicious that at least one of those is a re-ordered v210? I > seem to recall that we rejected adding v210 to this list. Either they > don't belong in this list or they don't belong because libavcodec has a > proper decoder (at least for v210). > They are not quite as bad as v210 (and not related). Microsoft documents them here as the recommended formats to be used on Windows: https://docs.microsoft.com/en-us/windows/desktop/medfound/recommended-8-bit-yuv-formats-for-video-rendering#444-formats-32-bits-per-pixel https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats - 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] libavformat/segment: add an option to split the rest of stream after the segment_times is set
Hi all:
Add an option to split the rest of stream after the segment_times is set.
It's very useful to set the first some segments to a little small, and then
split with a clear duration.
Signed-off-by: hectorqin
---
doc/muxers.texi | 5 +
libavformat/segment.c | 21 +++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 59c93bc687..7a0f7d2a52 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1930,6 +1930,11 @@ Specify a list of split points. @var{times} contains a
list of comma
separated duration specifications, in increasing order. See also
the @option{segment_time} option.
+@item segment_rest_duration @var{rest_duration}
+Set the rest segment duration to @var{rest_duration} when the
@var{segment_times} is set, the value must be a duration
+specification. Default value is "0", which means don't split the rest part.
See also the
+@option{segment_time} option.
+
@item segment_frames @var{frames}
Specify a list of split video frame numbers. @var{frames} contains a
list of comma separated integer numbers, in increasing order.
diff --git a/libavformat/segment.c b/libavformat/segment.c
index e3082063d8..8a325cd5e9 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -100,6 +100,9 @@ typedef struct SegmentContext {
int64_t *times;///< list of segment interval specification
int nb_times; ///< number of elments in the times array
+char *rest_duration_str; ///< rest segment duration specification string
+int64_t rest_duration; ///< rest segment duration
+
char *frames_str; ///< segment frame numbers specification string
int *frames; ///< list of frame number specification
int nb_frames; ///< number of elments in the frames array
@@ -698,6 +701,14 @@ static int seg_init(AVFormatContext *s)
if (seg->times_str) {
if ((ret = parse_times(s, >times, >nb_times,
seg->times_str)) < 0)
return ret;
+if (seg->rest_duration_str) {
+if ((ret = av_parse_time(>rest_duration,
seg->rest_duration_str, 1)) < 0) {
+av_log(s, AV_LOG_ERROR,
+"Invalid time duration specification '%s' for
segment_rest_duration option\n",
+seg->rest_duration_str);
+return ret;
+}
+}
} else if (seg->frames_str) {
if ((ret = parse_frames(s, >frames, >nb_frames,
seg->frames_str)) < 0)
return ret;
@@ -898,8 +909,13 @@ static int seg_write_packet(AVFormatContext *s, AVPacket
*pkt)
calc_times:
if (seg->times) {
-end_pts = seg->segment_count < seg->nb_times ?
-seg->times[seg->segment_count] : INT64_MAX;
+if (seg->segment_count < seg->nb_times) {
+end_pts = seg->times[seg->segment_count];
+} else if (seg->rest_duration > 0) {
+end_pts = seg->times[seg->nb_times - 1] + seg->rest_duration *
(seg->segment_count + 1 - seg->nb_times);
+} else {
+end_pts = INT64_MAX;
+}
} else if (seg->frames) {
start_frame = seg->segment_count < seg->nb_frames ?
seg->frames[seg->segment_count] : INT_MAX;
@@ -1084,6 +1100,7 @@ static const AVOption options[] = {
{ "segment_time", "set segment duration",
OFFSET(time_str),AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E },
{ "segment_time_delta","set approximation value used for the segment
times", OFFSET(time_delta), AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX, E },
{ "segment_times", "set segment split time points",
OFFSET(times_str),AV_OPT_TYPE_STRING,{.str = NULL}, 0, 0, E },
+{ "segment_rest_duration", "set rest segment duration after out of the
segment_times", OFFSET(rest_duration_str), AV_OPT_TYPE_STRING,{.str = NULL},
0, 0, E },
{ "segment_frames","set segment split frame numbers",
OFFSET(frames_str),AV_OPT_TYPE_STRING,{.str = NULL}, 0, 0, E },
{ "segment_wrap", "set number after which the index wraps",
OFFSET(segment_idx_wrap), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, E },
{ "segment_list_entry_prefix", "set base url prefix for segments",
OFFSET(entry_prefix), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E },
--
2.17.2 (Apple Git-113)
0001-Add-libavformat-segment_rest_duration-option.patch
Description: Binary data
___
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/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Linjie Fu
> Sent: Friday, June 28, 2019 10:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
>
> Signed-off-by: Linjie Fu
> ---
> libavutil/hwcontext_vaapi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> 4227c3c..6378d0e 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor
> vaapi_format_map[] = { #endif
> MAP(UYVY, YUV422, UYVY422, 0),
> MAP(YUY2, YUV422, YUYV422, 0),
> +#ifdef VA_FOURCC_Y210
> +MAP(Y210, YUV422_10,Y210LE, 0),
> +#endif
> +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
> +MAP(AYUV, AYUV, AYUV, 0),
> +#ifdef VA_FOURCC_Y410
> +MAP(Y410, YUV444_10,Y410LE, 0),
> +#endif
> MAP(411P, YUV411, YUV411P, 0),
> MAP(422V, YUV422, YUV440P, 0),
> MAP(444P, YUV444, YUV444P, 0),
> --
are you also considering to add Y210/AYUV/Y410 support in vaapi_drm_format_map
in libavutil/hwcontext_vaapi.c ?
Thanks,
Zachary
> 2.7.4
>
> ___
> 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/cfhd: fix compiling warning message and leave the code
Signed-off-by: Steven Liu
---
libavcodec/cfhd.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334b9b..1e2ab28dfb 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -136,6 +136,11 @@ static inline void peak_table(int16_t *band, Peak *peak,
int length)
band[i] = bytestream2_get_le16(>base);
}
+#if 0
+/* NOTE:
+ *There have no caller now,
+ *but maybe it will be used in the future.
+ * */
static inline void process_alpha(int16_t *alpha, int width)
{
int i, channel;
@@ -149,7 +154,7 @@ static inline void process_alpha(int16_t *alpha, int width)
alpha[i] = channel;
}
}
-
+#endif
static inline void filter(int16_t *output, ptrdiff_t out_stride,
int16_t *low, ptrdiff_t low_stride,
int16_t *high, ptrdiff_t high_stride,
--
2.15.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 1/5] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats
On 2019-06-28 04:26, Linjie Fu wrote: > Previously, media driver provided planar format(like 420 8 bit), but > for HEVC Range Extension (422/444 8/10 bit), the decoded image is > produced in packed format. > > Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding > for both VAAPI and QSV: > - Y210: 422 10 BIT > - AYUV: 444 8 BIT > - Y410: 444 10 BIT > Why am I suspicious that at least one of those is a re-ordered v210? I seem to recall that we rejected adding v210 to this list. Either they don't belong in this list or they don't belong because libavcodec has a proper decoder (at least for v210). This might be the thread I was remembering but March seems too recent > https://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241549.html No real conclusion was reached there. Do bit-packed formats belong in an AVPixelFormat? signature.asc Description: OpenPGP digital 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 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, June 28, 2019 09:09
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat
> support for YUV422/YUV444
>
> On Thu, Jun 27, 2019 at 4:31 PM Linjie Fu wrote:
> >
> > Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
> >
> > Modify to choose ChromaFormat according to fourCC.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavcodec/qsvdec.c | 20 +++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index 46aa2d6..7650325 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -40,6 +40,7 @@
> > #include "qsv.h"
> > #include "qsv_internal.h"
> > #include "qsvdec.h"
> > +#include
> >
> > const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
> > &(const AVCodecHWConfigInternal) {
> > @@ -211,7 +212,24 @@ static int qsv_decode_init(AVCodecContext *avctx,
> QSVContext *q)
> > param.mfx.FrameInfo.FourCC = q->fourcc;
> > param.mfx.FrameInfo.Width = frame_width;
> > param.mfx.FrameInfo.Height = frame_height;
> > -param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV420;
> > +
> > +switch (q->fourcc) {
> > +case VA_FOURCC_YUY2:
> > +#ifdef VA_FOURCC_Y210
> > +case VA_FOURCC_Y210:
> > +#endif
> > +param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV422;
> > +break;
> > +case VA_FOURCC_AYUV:
> > +#ifdef VA_FOURCC_Y410
> > +case VA_FOURCC_Y410:
> > +#endif
> > +param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV444;
> > +break;
> > +default:
> > +param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV420;
> > +break;
> > +}
> >
> > switch (avctx->field_order) {
> > case AV_FIELD_PROGRESSIVE:
>
> VA_FOURCC_ sounds like VAAPI, that doesn't seem like it belongs in qsv
> code which is supposed to work on multiple platforms.
Yes, it should be MFX_FOURCC_.
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 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
On Thu, Jun 27, 2019 at 4:31 PM Linjie Fu wrote:
>
> Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
>
> Modify to choose ChromaFormat according to fourCC.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/qsvdec.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 46aa2d6..7650325 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -40,6 +40,7 @@
> #include "qsv.h"
> #include "qsv_internal.h"
> #include "qsvdec.h"
> +#include
>
> const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
> &(const AVCodecHWConfigInternal) {
> @@ -211,7 +212,24 @@ static int qsv_decode_init(AVCodecContext *avctx,
> QSVContext *q)
> param.mfx.FrameInfo.FourCC = q->fourcc;
> param.mfx.FrameInfo.Width = frame_width;
> param.mfx.FrameInfo.Height = frame_height;
> -param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
> +
> +switch (q->fourcc) {
> +case VA_FOURCC_YUY2:
> +#ifdef VA_FOURCC_Y210
> +case VA_FOURCC_Y210:
> +#endif
> +param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV422;
> +break;
> +case VA_FOURCC_AYUV:
> +#ifdef VA_FOURCC_Y410
> +case VA_FOURCC_Y410:
> +#endif
> +param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV444;
> +break;
> +default:
> +param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
> +break;
> +}
>
> switch (avctx->field_order) {
> case AV_FIELD_PROGRESSIVE:
VA_FOURCC_ sounds like VAAPI, that doesn't seem like it belongs in qsv
code which is supposed to work on multiple platforms.
- 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".
Re: [FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update context in child thread in multi-thread mode
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, June 27, 2019 20:32
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update
> context in child thread in multi-thread mode
>
> Am Do., 27. Juni 2019 um 13:56 Uhr schrieb Linjie Fu :
>
> > libavcodec/internal.h | 7 +++
> > libavcodec/pthread_frame.c | 21 ++---
> > 2 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index 5096ffa..a85 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -162,6 +162,13 @@ typedef struct AVCodecInternal {
> >
> > void *thread_ctx;
> >
> > +/**
> > + * User thread AVCodecContext pointer and
> > + * context mutex
> > + */
> > +void *user_avctx;
>
> Sorry if this was already answered:
> Why is this not an AVCodecContext* ?
Followed the behavior of :
void *thread_ctx;
void *frame_thread_encoder
Since it will only be used as AVCodecContext* (not like void *hwaccel_priv_data)
AVCodecContext *user_avctx seems to be more directly.
I'm not strongly insist on this unless there are some other concerns or
differents.
___
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 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Friday, June 28, 2019 02:43 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat > support for YUV422/YUV444 > > Am Do., 27. Juni 2019 um 16:31 Uhr schrieb Linjie Fu : > > > > Currently, ChromaFormat passed to libmfx is set to YUV42O by default. > > > > Modify to choose ChromaFormat according to fourCC. > > Sorry if I misunderstand: > Doesn't 3/5 depend on this patch? The whole patch set enables HEVC Rext decode in QSV, and yes 3/5 won't take effect without 4/5 or 5/5. It seems I'd better adjust the patch sequence in the patch set according to dependency. 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 1/3] avcodec/cfhd: remove unused function
> 在 2019年6月28日，04:25，Reimar Döffinger 写道： > > On 27.06.2019, at 17:35, Vittorio Giovara wrote: > >> On Thu, Jun 27, 2019 at 9:44 AM Nicolas George wrote: >> >>> Kieran Kunhya (12019-06-27): I'm happy to do it now that I am aware of the issue. I will do it when I >>> am at home in a few days. >>> >>> Thanks. I am sure Steven will not mind waiting a few days. >>> This absolutism is absurd. >>> >>> Do you have an example of situation where dead code is good? >>> >> >> If i could add my 2 cents, for a reverse engineered codec it's important to >> leave unused functions purely for documentation purposes, so that future >> maintainers could implement and read about it right away, rather than >> digging in a large and messy git history. >> Additionally most compilers run passes that drop dead code already in a way >> that does not affect runtime one bit. So I really don't see any gains in >> removing these 14 lines of code. > > I'd note that intentionally dead code should at least have a comment, and > maybe even a #if 0 Yes, i think if the maintainers want use the unused code shortly time, maybe #if 0 is better way to fix the compiling waring. Because that is means the code is not in use now, perhaps it will be used In the future, so should add comment for that. not just stay it here, compiler give me warning, that is true, it’s dirty when compiling the project. If there have much more warning when compiling, i think no people like full screen warning message. perhaps there will have second, three, four, and so on if ignore the first one with this kind of message. Make the code clean, At the very least, no warning when compiling. > would make sense (though has the disadvantage of not > even compile-testing the code). > In case of an actual bug like here I would say dead code if nothing else is a > reminder of the > bug, though admittedly a very poor one.1 > Either way I suggest to discuss such things more relaxed, a few days more or > less hardly matters and there might be useful insights from other people (of > course I don't mean to delay non-controversial stuff nobody has any > comments/objections on). > > Best regards, > Reimar Döffinger > ___ > 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 Steven ___ 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/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
> -Original Message-
> From: Li, Zhong
> Sent: Thursday, June 27, 2019 23:41
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Friday, June 28, 2019 10:27 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> > vaapi_format_map for Y210/AYUV/Y410
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavutil/hwcontext_vaapi.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> > 4227c3c..6378d0e 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor
> > vaapi_format_map[] = { #endif
> > MAP(UYVY, YUV422, UYVY422, 0),
> > MAP(YUY2, YUV422, YUYV422, 0),
> > +#ifdef VA_FOURCC_Y210
> > +MAP(Y210, YUV422_10,Y210LE, 0),
> > +#endif
> > +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
>
> Probably you want to add "#ifdef VA_FOURCC_AYUV" too.
Since VA_FOURCC_AYUV was defined in libva early (same with YUY2 and UYVY
in commit bd592e38, 2009), I didn't add #ifdef query for AYUV.
> And would better to #undef VA_RT_FORMAT_AYUV here once map is done.
> (If you want to get a longer life cycle, would better define it outside)
I prefer to put the macro #define just ahead of the usage in vaapi_format_map
to make it more directly.
Will add #undef.
> > +MAP(AYUV, AYUV, AYUV, 0),
> > +#ifdef VA_FOURCC_Y410
> > +MAP(Y410, YUV444_10,Y410LE, 0),
> > +#endif
> > MAP(411P, YUV411, YUV411P, 0),
> > MAP(422V, YUV422, YUV440P, 0),
> > MAP(444P, YUV444, YUV444P, 0),
> > --
> > 2.7.4
___
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] lavc/mjpegdec: add function ff_mjpeg_decode_header
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, June 28, 2019 2:56 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavc/mjpegdec: add function
> ff_mjpeg_decode_header
>
> Am Do., 27. Juni 2019 um 14:59 Uhr schrieb Zhong Li :
>
> > -if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt
> && !size_change) {
> > +if (!(s->got_picture && s->interlaced && (s->bottom_field
> == !s->interlace_polarity))) {
> > +if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt &&
> > + !s->size_change) {
>
> Is this an (unrelated) bug fix or only vaapi-related?
> I wonder if it should be in this patch for both cases.
Hi Carl:
This is not to fix any issue, just a tailing after refact with
ff_mjpeg_decode_header():
Original code:
if (s->got_picture && s->interlaced && (s->bottom_field ==
!s->interlace_polarity)) {
if (s->progressive) {
avpriv_request_sample(s->avctx, "progressively coded interlaced
picture");
return AVERROR_INVALIDDATA;
}
} else {
...
if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt && !size_change) {
s->avctx->pix_fmt = s->hwaccel_pix_fmt;
} else {
enum AVPixelFormat pix_fmts[] = {
#if CONFIG_MJPEG_NVDEC_HWACCEL
AV_PIX_FMT_CUDA,
#endif
#if CONFIG_MJPEG_VAAPI_HWACCEL
AV_PIX_FMT_VAAPI,
#endif
s->avctx->pix_fmt,
AV_PIX_FMT_NONE,
};
s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
...
}
Thanks
Zhong
___
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] lavc/pthread_frame: update context in child thread in multi-thread mode
On Thu, Jun 27, 2019 at 1:56 PM Linjie Fu wrote: > > Currently in ff_thread_decode_frame, context is updated from child thread > to user thread, and user thread releases the context in avcodec_close() > when decode finishes. > > However, when resolution/format changes, ff_get_format is called, and > hwaccel_uninit() and hwaccel_init will be used to destroy and re-create > the context. Due to the async between user-thread and child-thread, > user-thread updates its context from child earlier than the context > is refreshed in child-thread. And it will lead to: > 1. memory leak in child-thread. > 2. double free in user-thread while calling avcodec_close(). > > Can be reproduced with a resolution change case, and use -vframes > to terminate the decode between the dynamic resolution changing frames: > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v > verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync > passthrough -vframes 6 -y out.yuv > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i > ./reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo > -vsync passthrough -vframes 45 -y out.yuv > > Move update_context_from_thread from ff_thread_decode_frame(user thread) > to frame_worker_thread(child thread), update the context in child thread > right after the context is refreshed to avoid the async issue. > I think the undelying issue that Michael mentioned remains - you are changing the user context from a worker thread, at which point the user might be accessing his context simultaneously. You cannot prevent that with a mutex, since the user does not use your mutex. Additionally, the user context should reflect the state of the last frame that was output to the user, if a worker thread changes it immediately as it sees the size change, wouldn't it be possible for frames of the old size to be output after the context was already updated? That sounds like trouble to me. - 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".
Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, June 28, 2019 9:09 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat
> support for YUV422/YUV444
>
> On Thu, Jun 27, 2019 at 4:31 PM Linjie Fu wrote:
> >
> > Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
> >
> > Modify to choose ChromaFormat according to fourCC.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavcodec/qsvdec.c | 20 +++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > 46aa2d6..7650325 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -40,6 +40,7 @@
> > #include "qsv.h"
> > #include "qsv_internal.h"
> > #include "qsvdec.h"
> > +#include
> >
> > const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
> > &(const AVCodecHWConfigInternal) { @@ -211,7 +212,24 @@
> static
> > int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > param.mfx.FrameInfo.FourCC = q->fourcc;
> > param.mfx.FrameInfo.Width = frame_width;
> > param.mfx.FrameInfo.Height = frame_height;
> > -param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV420;
> > +
> > +switch (q->fourcc) {
> > +case VA_FOURCC_YUY2:
> > +#ifdef VA_FOURCC_Y210
> > +case VA_FOURCC_Y210:
> > +#endif
> > +param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV422;
> > +break;
> > +case VA_FOURCC_AYUV:
> > +#ifdef VA_FOURCC_Y410
> > +case VA_FOURCC_Y410:
> > +#endif
> > +param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV444;
> > +break;
> > +default:
> > +param.mfx.FrameInfo.ChromaFormat =
> MFX_CHROMAFORMAT_YUV420;
> > +break;
> > +}
> >
> > switch (avctx->field_order) {
> > case AV_FIELD_PROGRESSIVE:
>
> VA_FOURCC_ sounds like VAAPI, that doesn't seem like it belongs in qsv code
> which is supposed to work on multiple platforms.
>
> - Hendrik
Good point, shouldn't use any VAAPI definition if without checking Linux
platform or CONFIG_VAAPI.
___
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] lavc/qsvenc: fix the incorrent map from bits to bytes
Reported-by：Maggie Sun Signed-off-by: Zhong Li --- V2: bump an new micro version since it changes the API usage. libavcodec/qsvenc.c | 2 +- libavcodec/version.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index 8dbad71..9bf8574 100644 --- a/libavcodec/qsvenc.c +++ b/libavcodec/qsvenc.c @@ -577,7 +577,7 @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q) //libmfx BRC parameters are 16 bits thus maybe overflow, then BRCParamMultiplier is needed buffer_size_in_kilobytes = avctx->rc_buffer_size / 8000; -initial_delay_in_kilobytes = avctx->rc_initial_buffer_occupancy / 1000; +initial_delay_in_kilobytes = avctx->rc_initial_buffer_occupancy / 8000; target_bitrate_kbps= avctx->bit_rate / 1000; max_bitrate_kbps = avctx->rc_max_rate / 1000; brc_param_multiplier = (FFMAX(FFMAX3(target_bitrate_kbps, max_bitrate_kbps, buffer_size_in_kilobytes), diff --git a/libavcodec/version.h b/libavcodec/version.h index 2709163..3583499 100644 --- a/libavcodec/version.h +++ b/libavcodec/version.h @@ -29,7 +29,7 @@ #define LIBAVCODEC_VERSION_MAJOR 58 #define LIBAVCODEC_VERSION_MINOR 53 -#define LIBAVCODEC_VERSION_MICRO 100 +#define LIBAVCODEC_VERSION_MICRO 101 #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ LIBAVCODEC_VERSION_MINOR, \ -- 2.7.4 ___ 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/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
> -Original Message-
> From: Zhou, Zachary
> Sent: Friday, June 28, 2019 11:33
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> > 4227c3c..6378d0e 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor
> > vaapi_format_map[] = { #endif
> > MAP(UYVY, YUV422, UYVY422, 0),
> > MAP(YUY2, YUV422, YUYV422, 0),
> > +#ifdef VA_FOURCC_Y210
> > +MAP(Y210, YUV422_10,Y210LE, 0),
> > +#endif
> > +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
> > +MAP(AYUV, AYUV, AYUV, 0),
> > +#ifdef VA_FOURCC_Y410
> > +MAP(Y410, YUV444_10,Y410LE, 0),
> > +#endif
> > MAP(411P, YUV411, YUV411P, 0),
> > MAP(422V, YUV422, YUV440P, 0),
> > MAP(444P, YUV444, YUV444P, 0),
> > --
>
> are you also considering to add Y210/AYUV/Y410 support in
> vaapi_drm_format_map in libavutil/hwcontext_vaapi.c ?
>
It could be added in vaapi_drm_format_map, however is not quite relevant with
the enabling of HEVC Rext decoding.
Maybe a separate patch can be sent and not include in this patch set.
___
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/cfhd: remove unused function
Nicolas George: > Paul B Mahol (12019-06-27): >> No, code is not dead and should be kept, ask maintainer for confirmation. > > The compiler says it is. I am sorry, but your statement without any > proof seems less reliable than the diagnostics of the compiler and > Steven's judgement. > > As is, the code can and should be removed, unless there is a technical > reason nobody mentioned yet. > > Regards, The code is indeed dead atm. To quote myself from ticket 7886: "Commit c64c97b972c7325a71440a352a7d541a8c92b2da has added support for alpha channel decoding in Cineform HD (thereby fixing #6265), but commit 9cefb9e7ec508900ba147e6977590f03456aa15c broke it again (the function process_alpha introduced in the first commit is now not even used any more -- thanks to Clang for reporting this). The sample cineform_rgba_12b.mov from #6265 now decodes as before c64c97b972c7325a71440a352a7d541a8c92b2da." - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update context in child thread in multi-thread mode
Currently in ff_thread_decode_frame, context is updated from child thread
to user thread, and user thread releases the context in avcodec_close()
when decode finishes.
However, when resolution/format changes, ff_get_format is called, and
hwaccel_uninit() and hwaccel_init will be used to destroy and re-create
the context. Due to the async between user-thread and child-thread,
user-thread updates its context from child earlier than the context
is refreshed in child-thread. And it will lead to:
1. memory leak in child-thread.
2. double free in user-thread while calling avcodec_close().
Can be reproduced with a resolution change case, and use -vframes
to terminate the decode between the dynamic resolution changing frames:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
passthrough -vframes 6 -y out.yuv
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i
./reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo
-vsync passthrough -vframes 45 -y out.yuv
Move update_context_from_thread from ff_thread_decode_frame(user thread)
to frame_worker_thread(child thread), update the context in child thread
right after the context is refreshed to avoid the async issue.
Signed-off-by: Linjie Fu
---
libavcodec/internal.h | 7 +++
libavcodec/pthread_frame.c | 21 ++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 5096ffa..a85 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -162,6 +162,13 @@ typedef struct AVCodecInternal {
void *thread_ctx;
+/**
+ * User thread AVCodecContext pointer and
+ * context mutex
+ */
+void *user_avctx;
+pthread_mutex_t context_mutex;
+
DecodeSimpleContext ds;
DecodeFilterContext filter;
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 36ac0ac..60110f2 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -140,6 +140,8 @@ typedef struct FrameThreadContext {
#define THREAD_SAFE_CALLBACKS(avctx) \
((avctx)->thread_safe_callbacks || (avctx)->get_buffer2 ==
avcodec_default_get_buffer2)
+static int update_context_from_thread(AVCodecContext *dst, AVCodecContext
*src, int for_user);
+
static void async_lock(FrameThreadContext *fctx)
{
pthread_mutex_lock(>async_mutex);
@@ -157,7 +159,6 @@ static void async_unlock(FrameThreadContext *fctx)
pthread_cond_broadcast(>async_cond);
pthread_mutex_unlock(>async_mutex);
}
-
/**
* Codec worker thread.
*
@@ -169,6 +170,7 @@ static attribute_align_arg void *frame_worker_thread(void
*arg)
{
PerThreadContext *p = arg;
AVCodecContext *avctx = p->avctx;
+AVCodecContext *user_avctx = p->avctx->internal->user_avctx;
const AVCodec *codec = avctx->codec;
pthread_mutex_lock(>mutex);
@@ -200,6 +202,12 @@ static attribute_align_arg void *frame_worker_thread(void
*arg)
p->got_frame = 0;
p->result = codec->decode(avctx, p->frame, >got_frame, >avpkt);
+if (user_avctx) {
+pthread_mutex_lock(_avctx->internal->context_mutex);
+update_context_from_thread(user_avctx, p->avctx, 1);
+pthread_mutex_unlock(_avctx->internal->context_mutex);
+}
+
if ((p->result < 0 || !p->got_frame) && p->frame->buf[0]) {
if (avctx->internal->allocate_progress)
av_log(avctx, AV_LOG_ERROR, "A frame threaded decoder did not "
@@ -390,7 +398,9 @@ static int submit_packet(PerThreadContext *p,
AVCodecContext *user_avctx,
pthread_mutex_lock(>mutex);
+pthread_mutex_lock(_avctx->internal->context_mutex);
ret = update_context_from_user(p->avctx, user_avctx);
+pthread_mutex_unlock(_avctx->internal->context_mutex);
if (ret) {
pthread_mutex_unlock(>mutex);
return ret;
@@ -540,8 +550,6 @@ int ff_thread_decode_frame(AVCodecContext *avctx,
if (finished >= avctx->thread_count) finished = 0;
} while (!avpkt->size && !*got_picture_ptr && err >= 0 && finished !=
fctx->next_finished);
-update_context_from_thread(avctx, p->avctx, 1);
-
if (fctx->next_decoding >= avctx->thread_count) fctx->next_decoding = 0;
fctx->next_finished = finished;
@@ -713,6 +721,8 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
thread_count)
pthread_mutex_destroy(>async_mutex);
pthread_cond_destroy(>async_cond);
+pthread_mutex_destroy(>internal->context_mutex);
+
av_freep(>internal->thread_ctx);
if (avctx->priv_data && avctx->codec && avctx->codec->priv_class)
@@ -728,6 +738,8 @@ int ff_frame_thread_init(AVCodecContext *avctx)
FrameThreadContext *fctx;
int i, err = 0;
+avctx->internal->user_avctx = avctx;
+
if (!thread_count) {
int nb_cpus = av_cpu_count();
#if FF_API_DEBUG_MV
@@ -761,6 +773,8 @@ int
[FFmpeg-devel] [PATCH 2/3] lavc/mjpeg_parser: use ff_mjpeg_decode_header to parse frame info
Signed-off-by: Zhong Li
---
libavcodec/mjpeg_parser.c | 158 +-
1 file changed, 157 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
index 07a6b2b..f59aa3e 100644
--- a/libavcodec/mjpeg_parser.c
+++ b/libavcodec/mjpeg_parser.c
@@ -27,12 +27,131 @@
*/
#include "parser.h"
+#include "mjpeg.h"
+#include "mjpegdec.h"
+#include "get_bits.h"
typedef struct MJPEGParserContext{
ParseContext pc;
+MJpegDecodeContext dec_ctx;
int size;
}MJPEGParserContext;
+/* return the 8 bit start code value and update the search
+ state. Return -1 if no start code found */
+static int find_frame_header_marker(const uint8_t **pbuf_ptr, const uint8_t
*buf_end)
+{
+const uint8_t *buf_ptr;
+unsigned int v, v2;
+int val;
+int skipped = 0;
+
+buf_ptr = *pbuf_ptr;
+while (buf_end - buf_ptr > 1) {
+v = *buf_ptr++;
+v2 = *buf_ptr;
+if ((v == 0xff) && buf_ptr < buf_end &&
+((v2 >= SOF0) && (v2 <= SOF3)) ) {
+val = *buf_ptr++;
+goto found;
+}
+skipped++;
+}
+buf_ptr = buf_end;
+val = -1;
+found:
+ff_dlog(NULL, "find_marker skipped %d bytes\n", skipped);
+*pbuf_ptr = buf_ptr;
+return val;
+}
+
+static void jpeg_set_interlace_polarity(AVCodecContext *avctx,
MJpegDecodeContext *dec_ctx)
+{
+if (avctx->extradata_size > 14
+&& AV_RL32(avctx->extradata) == 0x2C
+&& AV_RL32(avctx->extradata+4) == 0x18) {
+if (avctx->extradata[12] == 1) /* NTSC */
+dec_ctx->interlace_polarity = 1;
+if (avctx->extradata[12] == 2) /* PAL */
+dec_ctx->interlace_polarity = 0;
+}
+}
+
+static int jpeg_parse_header(AVCodecParserContext *s, AVCodecContext *avctx,
+ const uint8_t *buf, int buf_size)
+{
+MJPEGParserContext *m = s->priv_data;
+MJpegDecodeContext *dec_ctx = >dec_ctx;
+int start_code;
+const uint8_t *start, *end;
+int ret=0;
+
+start = buf;
+end = buf + buf_size;
+start_code = find_frame_header_marker(, end);
+if (start_code < 0) {
+av_log(avctx, AV_LOG_ERROR, "parse header failure:"
+"can't find supported marker type (%x)\n", start_code);
+
+return -1;
+} else
+av_log(avctx, AV_LOG_DEBUG, "marker=%x\n", start_code);
+
+jpeg_set_interlace_polarity(avctx, dec_ctx);
+init_get_bits8(_ctx->gb, start, end - start);
+dec_ctx->avctx = avctx;
+
+switch(start_code) {
+case SOF0:
+avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_BASELINE_DCT;
+dec_ctx->lossless= 0;
+dec_ctx->progressive = 0;
+break;
+case SOF1:
+avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_EXTENDED_SEQUENTIAL_DCT;
+dec_ctx->lossless= 0;
+dec_ctx->progressive = 0;
+break;
+case SOF2:
+avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_PROGRESSIVE_DCT;
+dec_ctx->lossless= 0;
+dec_ctx->progressive = 1;
+break;
+case SOF3:
+avctx->profile = FF_PROFILE_MJPEG_HUFFMAN_LOSSLESS;
+dec_ctx->lossless= 1;
+dec_ctx->progressive = 0;
+break;
+default:
+ assert(0);
+}
+
+ret = ff_mjpeg_decode_header(dec_ctx);
+if (ret < 0) {
+av_log(avctx, AV_LOG_WARNING, "Failed to parse header\n");
+return ret;
+}
+
+s->height = dec_ctx->height;
+s->width = dec_ctx->width;
+s->coded_height = s->height;
+s->coded_width = s->width;
+s->format = avctx->pix_fmt;
+s->pict_type= AV_PICTURE_TYPE_I;
+s->key_frame= 1;
+
+if (dec_ctx->interlaced) {
+if (dec_ctx->bottom_field)
+s->field_order = AV_FIELD_BB;
+else
+s->field_order = AV_FIELD_TT;
+} else
+s->field_order = AV_FIELD_PROGRESSIVE;
+
+return 0;
+}
+
+
/**
* Find the end of the current frame in the bitstream.
* @return the position of the first byte of the next frame, or -1
@@ -99,6 +218,40 @@ static int find_frame_end(MJPEGParserContext *m, const
uint8_t *buf, int buf_siz
return END_NOT_FOUND;
}
+static av_cold int jpeg_parse_init(AVCodecParserContext *s)
+{
+MJPEGParserContext *m = s->priv_data;
+MJpegDecodeContext *dec_ctx = >dec_ctx;
+
+if (!dec_ctx->picture_ptr) {
+dec_ctx->picture = av_frame_alloc();
+if (!dec_ctx->picture)
+return AVERROR(ENOMEM);
+dec_ctx->picture_ptr = dec_ctx->picture;
+}
+
+dec_ctx->first_picture = 1;
+dec_ctx->got_picture = 0;
+dec_ctx->org_height= 0;
+dec_ctx->ls= 0;
+return 0;
+}
+
+static av_cold void jpeg_parse_close(AVCodecParserContext *s)
+{
+MJPEGParserContext *m = s->priv_data;
+ParseContext *pc = >pc;
+MJpegDecodeContext *dec_ctx = >dec_ctx;
+
+av_freep(>buffer);
+
+if (dec_ctx->picture)
[FFmpeg-devel] [PATCH 1/3] lavc/mjpegdec: add function ff_mjpeg_decode_header
It will be reused in the following mjpeg_parser patch
Signed-off-by: Zhong Li
---
Mark Thompson: This seems suspicious - MJPEG is generally 4:2:2 (e.g. UVC
requires it), so I would expect a 4:2:2 format to be the default here? (Or
maybe a longer list - VAAPI certainly supports 4:2:2, 4:2:0 and 4:4:4 on the
same hardware.)
Zhong: libmfx can support jpeg baseline profile with more output formats, but
current ffmpeg-qsv decoder/vpp can't. Will extend supported format list as
separated patch.
libavcodec/mjpegdec.c | 37 -
libavcodec/mjpegdec.h | 4
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a65bc8d..5da66bb 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -157,6 +157,8 @@ av_cold int ff_mjpeg_decode_init(AVCodecContext *avctx)
s->start_code= -1;
s->first_picture = 1;
s->got_picture = 0;
+s->reinit_idct = 0;
+s->size_change = 0;
s->org_height= avctx->coded_height;
avctx->chroma_sample_location = AVCHROMA_LOC_CENTER;
avctx->colorspace = AVCOL_SPC_BT470BG;
@@ -302,9 +304,9 @@ int ff_mjpeg_decode_dht(MJpegDecodeContext *s)
return 0;
}
-int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
+int ff_mjpeg_decode_header(MJpegDecodeContext *s)
{
-int len, nb_components, i, width, height, bits, ret, size_change;
+int len, nb_components, i, width, height, bits, ret;
unsigned pix_fmt_id;
int h_count[MAX_COMPONENTS] = { 0 };
int v_count[MAX_COMPONENTS] = { 0 };
@@ -324,7 +326,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
if (s->avctx->bits_per_raw_sample != bits) {
av_log(s->avctx, s->avctx->bits_per_raw_sample > 0 ? AV_LOG_INFO :
AV_LOG_DEBUG, "Changing bps from %d to %d\n", s->avctx->bits_per_raw_sample,
bits);
s->avctx->bits_per_raw_sample = bits;
-init_idct(s->avctx);
+s->reinit_idct = 1;
}
if (s->pegasus_rct)
bits = 9;
@@ -417,7 +419,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
if (width != s->width || height != s->height || bits != s->bits ||
memcmp(s->h_count, h_count, sizeof(h_count))||
memcmp(s->v_count, v_count, sizeof(v_count))) {
-size_change = 1;
+s->size_change = 1;
s->width = width;
s->height = height;
@@ -444,8 +446,6 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return ret;
s->first_picture = 0;
-} else {
-size_change = 0;
}
if (s->got_picture && s->interlaced && (s->bottom_field ==
!s->interlace_polarity)) {
@@ -673,9 +673,28 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
av_log(s->avctx, AV_LOG_ERROR, "Could not get a pixel format
descriptor.\n");
return AVERROR_BUG;
}
+}
+
+return 0;
+}
+
+int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
+{
+int i, ret;
+
+ret = ff_mjpeg_decode_header(s);
+if (ret < 0)
+return ret;
+
+if (s->reinit_idct) {
+init_idct(s->avctx);
+s->reinit_idct = 0;
+}
-if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt && !size_change) {
+if (!(s->got_picture && s->interlaced && (s->bottom_field ==
!s->interlace_polarity))) {
+if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt && !s->size_change) {
s->avctx->pix_fmt = s->hwaccel_pix_fmt;
+s->size_change = 0;
} else {
enum AVPixelFormat pix_fmts[] = {
#if CONFIG_MJPEG_NVDEC_HWACCEL
@@ -728,8 +747,8 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
/* totally blank picture as progressive JPEG will only add details to it */
if (s->progressive) {
-int bw = (width + s->h_max * 8 - 1) / (s->h_max * 8);
-int bh = (height + s->v_max * 8 - 1) / (s->v_max * 8);
+int bw = (s->width + s->h_max * 8 - 1) / (s->h_max * 8);
+int bh = (s->height + s->v_max * 8 - 1) / (s->v_max * 8);
for (i = 0; i < s->nb_components; i++) {
int size = bw * bh * s->h_count[i] * s->v_count[i];
av_freep(>blocks[i]);
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 653fe7c..8f38767 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -114,6 +114,9 @@ typedef struct MJpegDecodeContext {
int restart_interval;
int restart_count;
+int reinit_idct;
+int size_change;
+
int buggy_avid;
int cs_itu601;
int interlace_polarity;
@@ -160,6 +163,7 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx,
AVPacket *avpkt);
int ff_mjpeg_decode_dqt(MJpegDecodeContext *s);
int ff_mjpeg_decode_dht(MJpegDecodeContext *s);
+int ff_mjpeg_decode_header(MJpegDecodeContext *s);
int ff_mjpeg_decode_sof(MJpegDecodeContext *s);
int ff_mjpeg_decode_sos(MJpegDecodeContext *s,
const uint8_t *mb_bitmask,int mb_bitmask_size,
--
2.7.4
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function
Liu Steven (12019-06-27): > I remove it because i cannot found the caller for this API. > I think there should have one caller for this API, It will not be used if > there have no caller, Isn’t it? I suppose you built the code and the compiler did not complain. I see no reason to keep dead code in the source tree. Regards, -- Nicolas George 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/cfhd: remove unused function
On 6/27/19, Paul B Mahol wrote: > On 6/27/19, Nicolas George wrote: >> Liu Steven (12019-06-27): >>> I remove it because i cannot found the caller for this API. >>> I think there should have one caller for this API, It will not be used >>> if >>> there have no caller, Isn’t it? >> >> I suppose you built the code and the compiler did not complain. >> >> I see no reason to keep dead code in the source tree. > > No, code is not dead and should be kept, ask maintainer for confirmation. Also, original author or this patch is actually Carl. > >> >> Regards, >> >> -- >> Nicolas George >> > ___ 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/cfhd: remove unused function
> 在 2019年6月27日，下午4:37，Paul B Mahol 写道：
>
> On 6/27/19, Paul B Mahol wrote:
>> On 6/27/19, Steven Liu wrote:
>>> Signed-off-by: Steven Liu
>>> ---
>>> libavcodec/cfhd.c | 14 --
>>> 1 file changed, 14 deletions(-)
>>>
>>> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
>>> index 846d334b9b..616f5af193 100644
>>> --- a/libavcodec/cfhd.c
>>> +++ b/libavcodec/cfhd.c
>>> @@ -136,20 +136,6 @@ static inline void peak_table(int16_t *band, Peak
>>> *peak, int length)
>>> band[i] = bytestream2_get_le16(>base);
>>> }
>>>
>>> -static inline void process_alpha(int16_t *alpha, int width)
>>> -{
>>> -int i, channel;
>>> -for (i = 0; i < width; i++) {
>>> -channel = alpha[i];
>>> -channel -= ALPHA_COMPAND_DC_OFFSET;
>>> -channel <<= 3;
>>> -channel *= ALPHA_COMPAND_GAIN;
>>> -channel >>= 16;
>>> -channel = av_clip_uintp2(channel, 12);
>>> -alpha[i] = channel;
>>> -}
>>> -}
>>> -
>>> static inline void filter(int16_t *output, ptrdiff_t out_stride,
>>> int16_t *low, ptrdiff_t low_stride,
>>> int16_t *high, ptrdiff_t high_stride,
>>> --
>>> 2.17.2 (Apple Git-113)
>>>
>>>
>>>
>>> ___
>>> 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".
>>
>> NAK
>>
>
> This code is needed for processing alpha, and should not be removed.
I remove it because i cannot found the caller for this API.
I think there should have one caller for this API, It will not be used if there
have no caller, Isn’t it?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavf/vf_find_rect: add the dual input support function
On Thu, Jun 27, 2019 at 09:40:22AM +0200, Moritz Barsnick wrote: > On Thu, Jun 27, 2019 at 10:12:35 +0800, lance.lmw...@gmail.com wrote: > > +This filter takes in two video input, the first input is considered > ^ inputs > > +the "main" source and is passed unchanged to the output. The "second" > > +input is used as a rectangular object for finding, now the "second" > ^ Now? > The part from "now" - once you have clarified why the word "now" > belongs here - should be a separate sentence. Please help to check my updated words for the v3 patch > > -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover > > new.mkv > > +ffmpeg -i file.ts -newref.pgm -filter_complex > > find_rect,cover_rect=cover.jpg:mode=cover new.mkv > This is certainly wrong. > > > -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover > > new.mkv > > +ffmpeg -i file.ts -newref.pgm -filter_complex > > find_rect,cover_rect=cover.jpg:mode=cover new.mkv > ditto > Yes, it's typo, fixed. > If you change the options behavior of a filter, you should bump > libavfilter micro version. Fixed. > > I can't just on most of the rest of your changes. > > 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". ___ 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] lavc/pthread_frame: update context in child thread in multi-thread mode
Am Do., 27. Juni 2019 um 13:56 Uhr schrieb Linjie Fu :
> libavcodec/internal.h | 7 +++
> libavcodec/pthread_frame.c | 21 ++---
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 5096ffa..a85 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -162,6 +162,13 @@ typedef struct AVCodecInternal {
>
> void *thread_ctx;
>
> +/**
> + * User thread AVCodecContext pointer and
> + * context mutex
> + */
> +void *user_avctx;
Sorry if this was already answered:
Why is this not an AVCodecContext* ?
Carl Eugen
___
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/cfhd: remove unused function
On Thu, 27 Jun 2019 at 20:01, Nicolas George wrote: > Andreas Rheinhardt (12019-06-27): > > The code is indeed dead atm. To quote myself from ticket 7886: > > "Commit c64c97b972c7325a71440a352a7d541a8c92b2da has added support for > > alpha channel decoding in Cineform HD (thereby fixing #6265), but > > commit 9cefb9e7ec508900ba147e6977590f03456aa15c broke it again (the > > function process_alpha introduced in the first commit is now not even > > used any more -- thanks to Clang for reporting this). The sample > > cineform_rgba_12b.mov from #6265 now decodes as before > > c64c97b972c7325a71440a352a7d541a8c92b2da." > > Thanks for clarifying. If it is dead, it can be removed. If it is needed > back, then it can be added back. Steven, go ahead if you want. > Why can this not be fixed properly? If the call to the function has been removed accidentally, why make things worse and remove the function completely? This makes no sense at all. Kieran ___ 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] lavc/mjpegdec: add function ff_mjpeg_decode_header
> From: Li, Zhong > Sent: Thursday, June 27, 2019 8:59 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Li, Zhong > Subject: [PATCH 1/3] lavc/mjpegdec: add function ff_mjpeg_decode_header > > It will be reused in the following mjpeg_parser patch > > Signed-off-by: Zhong Li > --- > Mark Thompson: This seems suspicious - MJPEG is generally 4:2:2 (e.g. UVC > requires it), so I would expect a 4:2:2 format to be the default here? (Or > maybe a longer list - VAAPI certainly supports 4:2:2, 4:2:0 and 4:4:4 on the > same hardware.) > Zhong: libmfx can support jpeg baseline profile with more output formats, > but current ffmpeg-qsv decoder/vpp can't. Will extend supported format list > as separated patch. Sorry, this annotation should be part of patch 3/3. Please ignore here. ___ 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/cfhd: remove unused function
On 6/27/19, Paul B Mahol wrote:
> On 6/27/19, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> libavcodec/cfhd.c | 14 --
>> 1 file changed, 14 deletions(-)
>>
>> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
>> index 846d334b9b..616f5af193 100644
>> --- a/libavcodec/cfhd.c
>> +++ b/libavcodec/cfhd.c
>> @@ -136,20 +136,6 @@ static inline void peak_table(int16_t *band, Peak
>> *peak, int length)
>> band[i] = bytestream2_get_le16(>base);
>> }
>>
>> -static inline void process_alpha(int16_t *alpha, int width)
>> -{
>> -int i, channel;
>> -for (i = 0; i < width; i++) {
>> -channel = alpha[i];
>> -channel -= ALPHA_COMPAND_DC_OFFSET;
>> -channel <<= 3;
>> -channel *= ALPHA_COMPAND_GAIN;
>> -channel >>= 16;
>> -channel = av_clip_uintp2(channel, 12);
>> -alpha[i] = channel;
>> -}
>> -}
>> -
>> static inline void filter(int16_t *output, ptrdiff_t out_stride,
>>int16_t *low, ptrdiff_t low_stride,
>>int16_t *high, ptrdiff_t high_stride,
>> --
>> 2.17.2 (Apple Git-113)
>>
>>
>>
>> ___
>> 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".
>
> NAK
>
This code is needed for processing alpha, and should not be removed.
___
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/cfhd: remove unused function
On 6/27/19, Liu Steven wrote:
>
>
>> 在 2019年6月27日，下午4:37，Paul B Mahol 写道：
>>
>> On 6/27/19, Paul B Mahol wrote:
>>> On 6/27/19, Steven Liu wrote:
Signed-off-by: Steven Liu
---
libavcodec/cfhd.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334b9b..616f5af193 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -136,20 +136,6 @@ static inline void peak_table(int16_t *band, Peak
*peak, int length)
band[i] = bytestream2_get_le16(>base);
}
-static inline void process_alpha(int16_t *alpha, int width)
-{
-int i, channel;
-for (i = 0; i < width; i++) {
-channel = alpha[i];
-channel -= ALPHA_COMPAND_DC_OFFSET;
-channel <<= 3;
-channel *= ALPHA_COMPAND_GAIN;
-channel >>= 16;
-channel = av_clip_uintp2(channel, 12);
-alpha[i] = channel;
-}
-}
-
static inline void filter(int16_t *output, ptrdiff_t out_stride,
int16_t *low, ptrdiff_t low_stride,
int16_t *high, ptrdiff_t high_stride,
--
2.17.2 (Apple Git-113)
___
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".
>>>
>>> NAK
>>>
>>
>> This code is needed for processing alpha, and should not be removed.
> I remove it because i cannot found the caller for this API.
> I think there should have one caller for this API, It will not be used if
> there have no caller, Isn’t it?
This is not an API. Please leave this function alone. If you really
need to fix it,
look at prior commits to this file and re-add alpha support.
>
>> ___
>> 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 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/cfhd: remove unused function
Andreas Rheinhardt (12019-06-27): > The code is indeed dead atm. To quote myself from ticket 7886: > "Commit c64c97b972c7325a71440a352a7d541a8c92b2da has added support for > alpha channel decoding in Cineform HD (thereby fixing #6265), but > commit 9cefb9e7ec508900ba147e6977590f03456aa15c broke it again (the > function process_alpha introduced in the first commit is now not even > used any more -- thanks to Clang for reporting this). The sample > cineform_rgba_12b.mov from #6265 now decodes as before > c64c97b972c7325a71440a352a7d541a8c92b2da." Thanks for clarifying. If it is dead, it can be removed. If it is needed back, then it can be added back. Steven, go ahead if you want. Regards, -- Nicolas George 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/cfhd: remove unused function
Kieran Kunhya (12019-06-27): > Why can this not be fixed properly? It can. If you have time and motivation to do it, please go ahead. Barring that, removing dead code is still an improvement. Regards, -- Nicolas George 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/cfhd: remove unused function
On 6/27/19, Nicolas George wrote: > Liu Steven (12019-06-27): >> I remove it because i cannot found the caller for this API. >> I think there should have one caller for this API, It will not be used if >> there have no caller, Isn’t it? > > I suppose you built the code and the compiler did not complain. > > I see no reason to keep dead code in the source tree. No, code is not dead and should be kept, ask maintainer for confirmation. > > Regards, > > -- > Nicolas George > ___ 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] hlsenc: Add option to set custom HTTP headers
On 27/06/2019 05:16, Steven Liu wrote: > LGTM > Pushed. Thanks! - Derek ___ 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] avutil/hwcontext_vaapi: move kernel_driver into CONFIG_LIBDRM
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Steven Liu
> Sent: Thursday, June 27, 2019 3:38 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Steven Liu
> Subject: [FFmpeg-devel] [PATCH 3/3] avutil/hwcontext_vaapi: move
> kernel_driver into CONFIG_LIBDRM
>
> Signed-off-by: Steven Liu
> ---
> libavutil/hwcontext_vaapi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> 4227c3c090..cf117640f2 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -1514,10 +1514,12 @@ static int
> vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
> break;
> }
> } else {
> -const AVDictionaryEntry *kernel_driver;
> char path[64];
> int n, max_devices = 8;
> +#if CONFIG_LIBDRM
> +const AVDictionaryEntry *kernel_driver;
> kernel_driver = av_dict_get(opts, "kernel_driver", NULL, 0);
> +#endif
> for (n = 0; n < max_devices; n++) {
> snprintf(path, sizeof(path),
> "/dev/dri/renderD%d", 128 + n);
> --
> 2.17.2 (Apple Git-113)
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function
On 6/27/19, Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> libavcodec/cfhd.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 846d334b9b..616f5af193 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -136,20 +136,6 @@ static inline void peak_table(int16_t *band, Peak
> *peak, int length)
> band[i] = bytestream2_get_le16(>base);
> }
>
> -static inline void process_alpha(int16_t *alpha, int width)
> -{
> -int i, channel;
> -for (i = 0; i < width; i++) {
> -channel = alpha[i];
> -channel -= ALPHA_COMPAND_DC_OFFSET;
> -channel <<= 3;
> -channel *= ALPHA_COMPAND_GAIN;
> -channel >>= 16;
> -channel = av_clip_uintp2(channel, 12);
> -alpha[i] = channel;
> -}
> -}
> -
> static inline void filter(int16_t *output, ptrdiff_t out_stride,
>int16_t *low, ptrdiff_t low_stride,
>int16_t *high, ptrdiff_t high_stride,
> --
> 2.17.2 (Apple Git-113)
>
>
>
> ___
> 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".
NAK
___
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] lavf/vf_find_rect: add the dual input support function
From: Limin Wang
Please using the below command for the testing:
./ffmpeg -i input.ts -i ref.png -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover output.ts
I have updated the help document for the function change.
Reviewed-by: Moritz Barsnick
Signed-off-by: Limin Wang
---
doc/filters.texi | 12 +--
libavfilter/version.h | 2 +-
libavfilter/vf_find_rect.c | 173 +++--
3 files changed, 118 insertions(+), 69 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 2d9af46a6b..92e1dee07e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10156,12 +10156,14 @@ Set color for pixels in fixed mode. Default is
@var{black}.
Find a rectangular object
+This filter takes in two video inputs, the first input is considered
+the "main" source and is passed unchanged to the output. The "second"
+input is used as a rectangular object for finding. Now the "second"
+input will be auto converted to gray8 format.
+
It accepts the following options:
@table @option
-@item object
-Filepath of the object image, needs to be in gray8.
-
@item threshold
Detection threshold, default is 0.5.
@@ -10178,7 +10180,7 @@ Specifies the rectangle in which to search.
@item
Cover a rectangular object by the supplied image of a given video using
@command{ffmpeg}:
@example
-ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
new.mkv
+ffmpeg -i file.ts -i newref.pgm -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover new.mkv
@end example
@end itemize
@@ -10212,7 +10214,7 @@ Default value is @var{blur}.
@item
Cover a rectangular object by the supplied image of a given video using
@command{ffmpeg}:
@example
-ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover
new.mkv
+ffmpeg -i file.ts -i newref.pgm -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover new.mkv
@end example
@end itemize
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 91a5a1604e..c0a4b969f1 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
#define LIBAVFILTER_VERSION_MAJOR 7
#define LIBAVFILTER_VERSION_MINOR 55
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
index d7e6579af7..91757b666d 100644
--- a/libavfilter/vf_find_rect.c
+++ b/libavfilter/vf_find_rect.c
@@ -18,13 +18,10 @@
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
-/**
- * @todo switch to dualinput
- */
-
#include "libavutil/avassert.h"
#include "libavutil/imgutils.h"
#include "libavutil/opt.h"
+#include "framesync.h"
#include "internal.h"
#include "lavfutils.h"
@@ -36,9 +33,9 @@ typedef struct FOCContext {
float threshold;
int mipmaps;
int xmin, ymin, xmax, ymax;
-char *obj_filename;
int last_x, last_y;
-AVFrame *obj_frame;
+FFFrameSync fs;
+
AVFrame *needle_frame[MAX_MIPMAPS];
AVFrame *haystack_frame[MAX_MIPMAPS];
} FOCContext;
@@ -46,7 +43,6 @@ typedef struct FOCContext {
#define OFFSET(x) offsetof(FOCContext, x)
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
static const AVOption find_rect_options[] = {
-{ "object", "object bitmap filename", OFFSET(obj_filename),
AV_OPT_TYPE_STRING, {.str = NULL}, .flags = FLAGS },
{ "threshold", "set threshold", OFFSET(threshold), AV_OPT_TYPE_FLOAT,
{.dbl = 0.5}, 0, 1.0, FLAGS },
{ "mipmaps", "set mipmaps", OFFSET(mipmaps), AV_OPT_TYPE_INT, {.i64 = 3},
1, MAX_MIPMAPS, FLAGS },
{ "xmin", "", OFFSET(xmin), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS
},
@@ -56,17 +52,32 @@ static const AVOption find_rect_options[] = {
{ NULL }
};
-AVFILTER_DEFINE_CLASS(find_rect);
+FRAMESYNC_DEFINE_CLASS(find_rect, FOCContext, fs);
static int query_formats(AVFilterContext *ctx)
{
-static const enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_YUVJ420P,
-AV_PIX_FMT_NONE
-};
+static const enum AVPixelFormat in_fmts[]= {AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE};
+static const enum AVPixelFormat obj_fmts[] = {AV_PIX_FMT_GRAY8,
AV_PIX_FMT_NONE};
+static const enum AVPixelFormat out_fmts[] = {AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE};
+int ret;
+AVFilterFormats *in= ff_make_format_list(in_fmts);
+AVFilterFormats *obj = ff_make_format_list(obj_fmts);
+AVFilterFormats *out = ff_make_format_list(out_fmts);
+
+if (!in || !obj || !out) {
+av_freep();
+av_freep();
+av_freep();
+return AVERROR(ENOMEM);
+}
+
+if ((ret = ff_formats_ref(in , >inputs[0]->out_formats)) < 0 ||
+(ret = ff_formats_ref(obj , >inputs[1]->out_formats)) < 0 ||
+
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function
Paul B Mahol (12019-06-27): > No, code is not dead and should be kept, ask maintainer for confirmation. The compiler says it is. I am sorry, but your statement without any proof seems less reliable than the diagnostics of the compiler and Steven's judgement. As is, the code can and should be removed, unless there is a technical reason nobody mentioned yet. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/qsvenc: fix the incorrent map from bits to bytes
Signed-off-by: Zhong Li --- libavcodec/qsvenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index 8dbad71..9bf8574 100644 --- a/libavcodec/qsvenc.c +++ b/libavcodec/qsvenc.c @@ -577,7 +577,7 @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q) //libmfx BRC parameters are 16 bits thus maybe overflow, then BRCParamMultiplier is needed buffer_size_in_kilobytes = avctx->rc_buffer_size / 8000; -initial_delay_in_kilobytes = avctx->rc_initial_buffer_occupancy / 1000; +initial_delay_in_kilobytes = avctx->rc_initial_buffer_occupancy / 8000; target_bitrate_kbps= avctx->bit_rate / 1000; max_bitrate_kbps = avctx->rc_max_rate / 1000; brc_param_multiplier = (FFMAX(FFMAX3(target_bitrate_kbps, max_bitrate_kbps, buffer_size_in_kilobytes), -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] lavc/mjpegdec: make code aligned
Signed-off-by: Zhong Li
---
libavcodec/mjpegdec.c | 450 +-
1 file changed, 225 insertions(+), 225 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1030861..a65bc8d 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -453,268 +453,268 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
avpriv_request_sample(s->avctx, "progressively coded interlaced
picture");
return AVERROR_INVALIDDATA;
}
-} else{
+} else {
if (s->v_max == 1 && s->h_max == 1 && s->lossless==1 &&
(nb_components==3 || nb_components==4))
s->rgb = 1;
else if (!s->lossless)
s->rgb = 0;
-/* XXX: not complete test ! */
-pix_fmt_id = ((unsigned)s->h_count[0] << 28) | (s->v_count[0] << 24) |
- (s->h_count[1] << 20) | (s->v_count[1] << 16) |
- (s->h_count[2] << 12) | (s->v_count[2] << 8) |
- (s->h_count[3] << 4) | s->v_count[3];
-av_log(s->avctx, AV_LOG_DEBUG, "pix fmt id %x\n", pix_fmt_id);
-/* NOTE we do not allocate pictures large enough for the possible
- * padding of h/v_count being 4 */
-if (!(pix_fmt_id & 0xD0D0D0D0))
-pix_fmt_id -= (pix_fmt_id & 0xF0F0F0F0) >> 1;
-if (!(pix_fmt_id & 0x0D0D0D0D))
-pix_fmt_id -= (pix_fmt_id & 0x0F0F0F0F) >> 1;
-
-for (i = 0; i < 8; i++) {
-int j = 6 + (i&1) - (i&6);
-int is = (pix_fmt_id >> (4*i)) & 0xF;
-int js = (pix_fmt_id >> (4*j)) & 0xF;
-
-if (is == 1 && js != 2 && (i < 2 || i > 5))
-js = (pix_fmt_id >> ( 8 + 4*(i&1))) & 0xF;
-if (is == 1 && js != 2 && (i < 2 || i > 5))
-js = (pix_fmt_id >> (16 + 4*(i&1))) & 0xF;
-
-if (is == 1 && js == 2) {
-if (i & 1) s->upscale_h[j/2] = 1;
-else s->upscale_v[j/2] = 1;
-}
-}
-
-switch (pix_fmt_id) {
-case 0x1100:
-if (s->rgb)
-s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
-else {
-if ( s->adobe_transform == 0
-|| s->component_id[0] == 'R' - 1 && s->component_id[1] == 'G'
- 1 && s->component_id[2] == 'B' - 1) {
-s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP :
AV_PIX_FMT_GBRP16;
-} else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
-else s->avctx->pix_fmt = AV_PIX_FMT_YUV444P16;
-s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
+/* XXX: not complete test ! */
+pix_fmt_id = ((unsigned)s->h_count[0] << 28) | (s->v_count[0] << 24) |
+ (s->h_count[1] << 20) | (s->v_count[1] << 16) |
+ (s->h_count[2] << 12) | (s->v_count[2] << 8) |
+ (s->h_count[3] << 4) | s->v_count[3];
+av_log(s->avctx, AV_LOG_DEBUG, "pix fmt id %x\n", pix_fmt_id);
+/* NOTE we do not allocate pictures large enough for the possible
+ * padding of h/v_count being 4 */
+if (!(pix_fmt_id & 0xD0D0D0D0))
+pix_fmt_id -= (pix_fmt_id & 0xF0F0F0F0) >> 1;
+if (!(pix_fmt_id & 0x0D0D0D0D))
+pix_fmt_id -= (pix_fmt_id & 0x0F0F0F0F) >> 1;
+
+for (i = 0; i < 8; i++) {
+int j = 6 + (i&1) - (i&6);
+int is = (pix_fmt_id >> (4*i)) & 0xF;
+int js = (pix_fmt_id >> (4*j)) & 0xF;
+
+if (is == 1 && js != 2 && (i < 2 || i > 5))
+js = (pix_fmt_id >> ( 8 + 4*(i&1))) & 0xF;
+if (is == 1 && js != 2 && (i < 2 || i > 5))
+js = (pix_fmt_id >> (16 + 4*(i&1))) & 0xF;
+
+if (is == 1 && js == 2) {
+if (i & 1) s->upscale_h[j/2] = 1;
+else s->upscale_v[j/2] = 1;
}
}
-av_assert0(s->nb_components == 3);
-break;
-case 0x:
-if (s->rgb)
-s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_ABGR :
AV_PIX_FMT_RGBA64;
-else {
+
+switch (pix_fmt_id) {
+case 0x1100:
+if (s->rgb)
+s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
+else {
+if ( s->adobe_transform == 0
+|| s->component_id[0] == 'R' - 1 && s->component_id[1] ==
'G' - 1 && s->component_id[2] == 'B' - 1) {
+s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP :
AV_PIX_FMT_GBRP16;
+} else {
+if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+else s->avctx->pix_fmt = AV_PIX_FMT_YUV444P16;
+s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
+}
+}
+
[FFmpeg-devel] [PATCH 1/2] lavc/mjpegdec: replace number with marker name
Make it easier to read.
Signed-off-by: Zhong Li
---
libavcodec/mjpegdec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 20eeb96..1030861 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2115,7 +2115,7 @@ static int find_marker(const uint8_t **pbuf_ptr, const
uint8_t *buf_end)
while (buf_end - buf_ptr > 1) {
v = *buf_ptr++;
v2 = *buf_ptr;
-if ((v == 0xff) && (v2 >= 0xc0) && (v2 <= 0xfe) && buf_ptr < buf_end) {
+if ((v == 0xff) && (v2 >= SOF0) && (v2 <= COM) && buf_ptr < buf_end) {
val = *buf_ptr++;
goto found;
}
@@ -2180,7 +2180,7 @@ int ff_mjpeg_find_marker(MJpegDecodeContext *s,
src--;
}
-if (x < 0xd0 || x > 0xd7) {
+if (x < RST0 || x > RST7) {
copy_data_segment(1);
if (x)
break;
@@ -2319,7 +2319,7 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
av_log(avctx, AV_LOG_DEBUG, "startcode: %X\n", start_code);
/* process markers */
-if (start_code >= 0xd0 && start_code <= 0xd7) {
+if (start_code >= RST0 && start_code <= RST7) {
av_log(avctx, AV_LOG_DEBUG,
"restart marker: %d\n", start_code & 0x0f);
/* APP fields */
--
2.7.4
___
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/3] qsvdec: add mjpeg decoding support
Only baseline profile and NV12 output format supported right now.
---
Changelog | 1 +
configure | 2 ++
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/qsv.c | 2 ++
libavcodec/qsvdec.c | 2 ++
libavcodec/qsvdec.h | 1 +
libavcodec/qsvdec_other.c | 28 +++-
8 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index 57476c3..2bc1087 100644
--- a/Changelog
+++ b/Changelog
@@ -34,6 +34,7 @@ version :
- VP4 video decoder
- IFV demuxer
- derain filter
+- Intel QSV-accelerated MJPEG decoding
version 4.1:
diff --git a/configure b/configure
index 7cea9d4..8119a29 100755
--- a/configure
+++ b/configure
@@ -3028,6 +3028,8 @@ hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
hevc_v4l2m2m_decoder_select="hevc_mp4toannexb_bsf"
hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m"
mjpeg_cuvid_decoder_deps="cuvid"
+mjpeg_qsv_decoder_deps="libmfx"
+mjpeg_qsv_decoder_select="qsvdec mjpeg_parser"
mjpeg_qsv_encoder_deps="libmfx"
mjpeg_qsv_encoder_select="qsvenc"
mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index edccd73..95b7fc8 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -425,6 +425,7 @@ OBJS-$(CONFIG_METASOUND_DECODER) += metasound.o
metasound_data.o \
OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
OBJS-$(CONFIG_MIMIC_DECODER) += mimic.o
OBJS-$(CONFIG_MJPEG_DECODER) += mjpegdec.o
+OBJS-$(CONFIG_MJPEG_QSV_DECODER) += qsvdec_other.o
OBJS-$(CONFIG_MJPEG_ENCODER) += mjpegenc.o mjpegenc_common.o \
mjpegenc_huffman.o
OBJS-$(CONFIG_MJPEGB_DECODER) += mjpegbdec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39..cfc1d47 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -763,6 +763,7 @@ extern AVCodec ff_hevc_videotoolbox_encoder;
extern AVCodec ff_libkvazaar_encoder;
extern AVCodec ff_mjpeg_cuvid_decoder;
extern AVCodec ff_mjpeg_qsv_encoder;
+extern AVCodec ff_mjpeg_qsv_decoder;
extern AVCodec ff_mjpeg_vaapi_encoder;
extern AVCodec ff_mpeg1_cuvid_decoder;
extern AVCodec ff_mpeg2_cuvid_decoder;
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 986d4f6..69961b7 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -96,6 +96,8 @@ static const struct {
MAP(HEVC,HEVC_REXT, HEVC_REXT),
#endif
+MAP(MJPEG, MJPEG_HUFFMAN_LOSSLESS, JPEG_BASELINE ),
+
MAP(VC1, VC1_SIMPLE, VC1_SIMPLE ),
MAP(VC1, VC1_MAIN,VC1_MAIN ),
MAP(VC1, VC1_COMPLEX, VC1_ADVANCED ),
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 46aa2d6..d1ea056 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -212,6 +212,8 @@ static int qsv_decode_init(AVCodecContext *avctx,
QSVContext *q)
param.mfx.FrameInfo.Width = frame_width;
param.mfx.FrameInfo.Height = frame_height;
param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
+param.mfx.FrameInfo.CropW = avctx->width;
+param.mfx.FrameInfo.CropH = avctx->height;
switch (avctx->field_order) {
case AV_FIELD_PROGRESSIVE:
diff --git a/libavcodec/qsvdec.h b/libavcodec/qsvdec.h
index 111536c..3b44af9 100644
--- a/libavcodec/qsvdec.h
+++ b/libavcodec/qsvdec.h
@@ -27,6 +27,7 @@
#include
#include
+#include
#include "libavutil/fifo.h"
#include "libavutil/frame.h"
diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
index 03251d2..8c9c1e6 100644
--- a/libavcodec/qsvdec_other.c
+++ b/libavcodec/qsvdec_other.c
@@ -1,5 +1,5 @@
/*
- * Intel MediaSDK QSV based MPEG-2, VC-1 and VP8 decoders
+ * Intel MediaSDK QSV based MPEG-2, VC-1, VP8 and MJPEG decoders
*
* copyright (c) 2015 Anton Khirnov
*
@@ -255,3 +255,29 @@ AVCodec ff_vp8_qsv_decoder = {
.wrapper_name = "qsv",
};
#endif
+
+#if CONFIG_MJPEG_QSV_DECODER
+static const AVClass mjpeg_qsv_class = {
+.class_name = "mjpeg_qsv",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+AVCodec ff_mjpeg_qsv_decoder = {
+.name = "mjpeg_qsv",
+.long_name = NULL_IF_CONFIG_SMALL("MJPEG video (Intel Quick Sync
Video acceleration)"),
+.priv_data_size = sizeof(QSVOtherContext),
+.type = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_MJPEG,
+.init = qsv_decode_init,
+.decode = qsv_decode_frame,
+.flush = qsv_decode_flush,
+.close = qsv_decode_close,
+.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_AVOID_PROBING,
+.priv_class = _qsv_class,
+.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
+
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function
On Thu, 27 Jun 2019 at 20:52, Nicolas George wrote: > Kieran Kunhya (12019-06-27): > > Why can this not be fixed properly? > > It can. If you have time and motivation to do it, please go ahead. > Barring that, removing dead code is still an improvement. > > Regards, > It's not dead code, the GSOC student last year removed the call to the function by accident. It is beyond comprehension how removing more code and making the situation worse improves things. Kieran ___ 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/cfhd: remove unused function
Kieran Kunhya (12019-06-27): > It's not dead code, Right now, yes, it is dead. > the GSOC student last year removed the call to the > function by accident. If it is so easy, you could do it instead of arguing. If it is not so easy, you cannot demand somebody do it. > It is beyond comprehension how removing more code and making the situation > worse improves things. Dead code is never good. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avformat/rtpdec_rfc4175: Fix incorrect copy_offset calculation
The previous calculation code did not account for the fact that the copy_offset for the start of the frame array is at index 0, yet the scan line number from the rfc4175 RTP header starts at 1. This caused 2 issues to appear: - The first scan line was being copied into the array where the second scan line should be. This caused the resulting video to have a green line at the top of it. - Since the packet containing the last scan line would fail the calculation, the packet with the RTP marker would not be processed which caused a log message saying "Missed previous RTP marker" to be outputted for each frame. Signed-off-by: Jacob Siddall --- Changes in v2: - Don't handle packet if the line number is less than 1 Section 12 in the VSF technical recommendation TR-03 specifies that the video scan line numbers should start at 1. http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf Changes in v3: - Changed the commit hash abbreviation in the patch file diff to be 10 characters in length rather than 7. This was causing the patch file to fail when it was applied. libavformat/rtpdec_rfc4175.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c index e9c62c1389..490db87520 100644 --- a/libavformat/rtpdec_rfc4175.c +++ b/libavformat/rtpdec_rfc4175.c @@ -205,8 +205,11 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data, if (length > payload_len) length = payload_len; +if (line < 1) +return AVERROR_INVALIDDATA; + /* prevent ill-formed packets to write after buffer's end */ -copy_offset = (line * data->width + offset) * data->pgroup / data->xinc; +copy_offset = ((line - 1) * data->width + offset) * data->pgroup / data->xinc; if (copy_offset + length > data->frame_size) return AVERROR_INVALIDDATA; -- 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] Avoid integer to float point domain crossing penalties
Anyone interested in reviewing this patch ?
Thanks
-Adrian
On Mon, 24 Jun 2019 at 13:57, wrote:
> From: Adrian Tong
>
> On internal benchmark, I see a noisy-level difference (more likely to be
> an improvement) in ff_h264_decode_mb_cabac which calls this function.
> ---
> libavutil/x86/intreadwrite.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/x86/intreadwrite.h b/libavutil/x86/intreadwrite.h
> index 4061d19231..df0bf45ae1 100644
> --- a/libavutil/x86/intreadwrite.h
> +++ b/libavutil/x86/intreadwrite.h
> @@ -68,8 +68,8 @@ static av_always_inline void AV_COPY128(void *d, const
> void *s)
> {
> struct v {uint64_t v[2];};
>
> -__asm__("movaps %1, %%xmm0 \n\t"
> -"movaps %%xmm0, %0 \n\t"
> +__asm__("movdqa %1, %%xmm0 \n\t"
> +"movdqa %%xmm0, %0 \n\t"
> : "=m"(*(struct v*)d)
> : "m" (*(const struct v*)s)
> : "xmm0");
> --
> 2.20.1 (Apple Git-117)
>
>
___
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/4] avcodec/dxv: Check op_offset in both directions
On 6/27/19, Michael Niedermayer wrote: > Fixes: signed integer overflow: 61 + 2147483647 cannot be represented in > type 'int' > Fixes: > 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/dxv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c > index 5fd1844094..3506775560 100644 > --- a/libavcodec/dxv.c > +++ b/libavcodec/dxv.c > @@ -745,7 +745,7 @@ static int dxv_decompress_cocg(DXVContext *ctx, > GetByteContext *gb, > int skip0, skip1, oi0 = 0, oi1 = 0; > int ret, state0 = 0, state1 = 0; > > -if (op_offset < 12) > +if (op_offset < 12 || op_offset - 12 > bytestream2_get_bytes_left(gb)) > return AVERROR_INVALIDDATA; > > dst = tex_data; > -- > 2.22.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". Make sure this does not break any files. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavf/vf_find_rect: add the dual input support function
On Thu, Jun 27, 2019 at 10:12:35 +0800, lance.lmw...@gmail.com wrote: > +This filter takes in two video input, the first input is considered ^ inputs > +the "main" source and is passed unchanged to the output. The "second" > +input is used as a rectangular object for finding, now the "second" ^ Now? The part from "now" - once you have clarified why the word "now" belongs here - should be a separate sentence. > -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover > new.mkv > +ffmpeg -i file.ts -newref.pgm -filter_complex > find_rect,cover_rect=cover.jpg:mode=cover new.mkv This is certainly wrong. > -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover > new.mkv > +ffmpeg -i file.ts -newref.pgm -filter_complex > find_rect,cover_rect=cover.jpg:mode=cover new.mkv ditto If you change the options behavior of a filter, you should bump libavfilter micro version. I can't just on most of the rest of your changes. 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 v2] lavf/vf_find_rect: add the dual input support function
On Thu, Jun 27, 2019 at 09:40:22 +0200, Moritz Barsnick wrote: > I can't just on most of the rest of your changes. Whot? Meant to say: I can't judge most of the rest of your changes. M. ___ 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/3] avutil/hwcontext_vaapi: move kernel_driver into CONFIG_LIBDRM
Signed-off-by: Steven Liu
---
libavutil/hwcontext_vaapi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 4227c3c090..cf117640f2 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1514,10 +1514,12 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
const char *device,
break;
}
} else {
-const AVDictionaryEntry *kernel_driver;
char path[64];
int n, max_devices = 8;
+#if CONFIG_LIBDRM
+const AVDictionaryEntry *kernel_driver;
kernel_driver = av_dict_get(opts, "kernel_driver", NULL, 0);
+#endif
for (n = 0; n < max_devices; n++) {
snprintf(path, sizeof(path),
"/dev/dri/renderD%d", 128 + n);
--
2.17.2 (Apple Git-113)
___
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/3] avcodec/videotoolboxenc: remove unused variable
Signed-off-by: Steven Liu --- libavcodec/videotoolboxenc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index 3665581283..67faca4751 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -2395,8 +2395,6 @@ static int vtenc_populate_extradata(AVCodecContext *avctx, goto pe_cleanup; } -unsigned pbuftype = CVPixelBufferGetPixelFormatType(pix_buf); - time = CMTimeMake(0, avctx->time_base.den); status = VTCompressionSessionEncodeFrame(vtctx->session, pix_buf, -- 2.17.2 (Apple Git-113) ___ 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/3] avcodec/cfhd: remove unused function
Signed-off-by: Steven Liu
---
libavcodec/cfhd.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334b9b..616f5af193 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -136,20 +136,6 @@ static inline void peak_table(int16_t *band, Peak *peak,
int length)
band[i] = bytestream2_get_le16(>base);
}
-static inline void process_alpha(int16_t *alpha, int width)
-{
-int i, channel;
-for (i = 0; i < width; i++) {
-channel = alpha[i];
-channel -= ALPHA_COMPAND_DC_OFFSET;
-channel <<= 3;
-channel *= ALPHA_COMPAND_GAIN;
-channel >>= 16;
-channel = av_clip_uintp2(channel, 12);
-alpha[i] = channel;
-}
-}
-
static inline void filter(int16_t *output, ptrdiff_t out_stride,
int16_t *low, ptrdiff_t low_stride,
int16_t *high, ptrdiff_t high_stride,
--
2.17.2 (Apple Git-113)
___
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".
