[FFmpeg-devel] [Patch] lavf/mpeg: fix indent
From 2a2dc1dd417a78650675f327f6db832e58e229a8 Mon Sep 17 00:00:00 2001 From: wxf Date: Fri, 15 Feb 2019 09:41:29 +0800 Subject: [PATCH] lavf/mpeg: fix indent Signed-off-by: wxf --- libavformat/mpeg.c | 56 +++--- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c index d4369b49c2..c147fa72ed 100644 --- a/libavformat/mpeg.c +++ b/libavformat/mpeg.c @@ -525,34 +525,34 @@ redo: } es_type = m->psm_es_type[startcode & 0xff]; -if (es_type == STREAM_TYPE_VIDEO_MPEG1) { -codec_id = AV_CODEC_ID_MPEG2VIDEO; -type = AVMEDIA_TYPE_VIDEO; -} else if (es_type == STREAM_TYPE_VIDEO_MPEG2) { -codec_id = AV_CODEC_ID_MPEG2VIDEO; -type = AVMEDIA_TYPE_VIDEO; -} else if (es_type == STREAM_TYPE_AUDIO_MPEG1 || - es_type == STREAM_TYPE_AUDIO_MPEG2) { -codec_id = AV_CODEC_ID_MP3; -type = AVMEDIA_TYPE_AUDIO; -} else if (es_type == STREAM_TYPE_AUDIO_AAC) { -codec_id = AV_CODEC_ID_AAC; -type = AVMEDIA_TYPE_AUDIO; -} else if (es_type == STREAM_TYPE_VIDEO_MPEG4) { -codec_id = AV_CODEC_ID_MPEG4; -type = AVMEDIA_TYPE_VIDEO; -} else if (es_type == STREAM_TYPE_VIDEO_H264) { -codec_id = AV_CODEC_ID_H264; -type = AVMEDIA_TYPE_VIDEO; -} else if (es_type == STREAM_TYPE_VIDEO_HEVC) { -codec_id = AV_CODEC_ID_HEVC; -type = AVMEDIA_TYPE_VIDEO; -} else if (es_type == STREAM_TYPE_AUDIO_AC3) { -codec_id = AV_CODEC_ID_AC3; -type = AVMEDIA_TYPE_AUDIO; -} else if (m->imkh_cctv && es_type == 0x91) { -codec_id = AV_CODEC_ID_PCM_MULAW; -type = AVMEDIA_TYPE_AUDIO; +if (es_type == STREAM_TYPE_VIDEO_MPEG1) { +codec_id = AV_CODEC_ID_MPEG2VIDEO; +type = AVMEDIA_TYPE_VIDEO; +} else if (es_type == STREAM_TYPE_VIDEO_MPEG2) { +codec_id = AV_CODEC_ID_MPEG2VIDEO; +type = AVMEDIA_TYPE_VIDEO; +} else if (es_type == STREAM_TYPE_AUDIO_MPEG1 || + es_type == STREAM_TYPE_AUDIO_MPEG2) { +codec_id = AV_CODEC_ID_MP3; +type = AVMEDIA_TYPE_AUDIO; +} else if (es_type == STREAM_TYPE_AUDIO_AAC) { +codec_id = AV_CODEC_ID_AAC; +type = AVMEDIA_TYPE_AUDIO; +} else if (es_type == STREAM_TYPE_VIDEO_MPEG4) { +codec_id = AV_CODEC_ID_MPEG4; +type = AVMEDIA_TYPE_VIDEO; +} else if (es_type == STREAM_TYPE_VIDEO_H264) { +codec_id = AV_CODEC_ID_H264; +type = AVMEDIA_TYPE_VIDEO; +} else if (es_type == STREAM_TYPE_VIDEO_HEVC) { +codec_id = AV_CODEC_ID_HEVC; +type = AVMEDIA_TYPE_VIDEO; +} else if (es_type == STREAM_TYPE_AUDIO_AC3) { +codec_id = AV_CODEC_ID_AC3; +type = AVMEDIA_TYPE_AUDIO; +} else if (m->imkh_cctv && es_type == 0x91) { +codec_id = AV_CODEC_ID_PCM_MULAW; +type = AVMEDIA_TYPE_AUDIO; } else if (startcode >= 0x1e0 && startcode <= 0x1ef) { static const unsigned char avs_seqh[4] = { 0, 0, 1, 0xb0 }; unsigned char buf[8]; -- 2.16.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64
> > 2019-02-09 16:46 GMT+01:00, Wang Bin : > >> > >> 2019-02-05 0:59 GMT+01:00, James Almer : > >> > On 1/31/2019 4:23 PM, Carl Eugen Hoyos wrote: > >> >> 2019-01-31 17:04 GMT+01:00, Magnus Röös : > >> >>> Partial port of the ARM Neon for aarch64. > >> >> > >> >> Reproduced a >20% speedup for fate-vp8 and applied. > >> >> > >> >> Thank you, Carl Eugen > >> > > >> > This seems to have broken builds with Clang on aarch64. GCC seems > fine. > >> > > >> > > >> > http://fate.ffmpeg.org/report.cgi?time=20190204212326&slot=armv8-linux-clang-7 > >> > >> Yes. > >> > >> Do you know if Martin plans to push his patch? > >> I can do it but I cannot test MS. > >> > > > > This breaks android(clang), ios and msvc. > Please test Martin's patches or "--extra-cflags=-fno-integrated-as", > see ticket #7728. The patch in ticket #7728 works for ios and clang-cl, armasm and android clang w/o -fno-integrated-as are still broken. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimizetheora decoding with mmi.
>On Fri, Feb 15, 2019 at 12:13:43AM +0100, Michael Niedermayer wrote: > > On Wed, Feb 13, 2019 at 05:56:50PM +0800, Shiyou Yin wrote: > > > >-Original Message- > > > >From: ffmpeg-devel-boun...@ffmpeg.org > > > >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of gxw > > > >Sent: Tuesday, February 12, 2019 6:56 PM > > > >To: ffmpeg-devel@ffmpeg.org > > > >Cc: gxw > > > >Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora > > > >decoding with mmi. > > > > > > > >Optimize theora decoding with mmi in functions: > > > >1. ff_vp3_idct_add_mmi > > > >2. ff_vp3_idct_put_mmi > > > >3. ff_vp3_idct_dc_add_mmi > > > >4. ff_put_no_rnd_pixels_l2_mmi > > > > > > > >Theora decoding speed improved about 32%(from 88fps to 116fps, Tested on > > > >loongson 3A3000). > > > >--- > > > > libavcodec/mips/Makefile | 1 + > > > > libavcodec/mips/vp3dsp_idct_mmi.c | 769 > > > > + > > > > libavcodec/mips/vp3dsp_init_mips.c | 14 + > > > > libavcodec/mips/vp3dsp_mips.h | 6 + > > > > 4 files changed, 790 insertions(+) > > > > create mode 100644 libavcodec/mips/vp3dsp_idct_mmi.c > > > > > > > > > > Verified + 1, LGTM. > > > > will apply > one last minute issue i noticed > The author looks like a nick name or user name, is that intended: > "gxw " ? > I mean do you want "gxw" instead of your full name ? > > (iam asking as it cannot be changed after pushing ...) > > Thanks Thanks for you reminder, i want to use "gxw" . Warmest regards. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mpeg4videodec: Clear interlaced_dct for studio profile
Fixes: Out of array access Fixes: 13090/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5408668986638336 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/mpeg4videodec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c index f44ee76bd4..ecd028a87c 100644 --- a/libavcodec/mpeg4videodec.c +++ b/libavcodec/mpeg4videodec.c @@ -3057,6 +3057,7 @@ static int decode_studio_vop_header(Mpeg4DecContext *ctx, GetBitContext *gb) return 0; s->partitioned_frame = 0; +s->interlaced_dct = 0; s->decode_mb = mpeg4_decode_studio_mb; decode_smpte_tc(ctx, gb); -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On 15.02.2019 01:01, Carl Eugen Hoyos wrote: 2019-02-14 23:36 GMT+01:00, Carl Eugen Hoyos : please mention ticket #7735. Ping! I remembered the moment i pushed the patch, sorry. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT
2019-02-15 1:12 GMT+01:00, Carl Eugen Hoyos : > 2019-02-15 0:23 GMT+01:00, Hendrik Leppkes : >> On Thu, Feb 14, 2019 at 8:11 PM Carl Eugen Hoyos >> wrote: >>> >>> Hi! >>> >>> I created attached patch with a lot of help from Hendrik, fixes ticket >>> #7731. >>> >> >> Som general comments, since I can't replay inline in this mail client: >> >> - The pseudo-timestamps are unsigned 16-bit, personally I would make >> all types that reference them uint16_t and rely on unsigned overflow >> behavior, which is fully valid and specified - no need to handle >> negatives manually, etc. > > I had already changed this (only for the actual timestamp difference), > thank you! > >> - The distance between frames can be incredibly large in some streams, >> I've seen it be larger then one whole MAT frame, and the output works >> reliably (MAT start/middle/end codes need to be placed within the >> padding space, of course). > > That is not supported yet, could you provide such a problematic sample? > (Including the output if possible) > > New patch attached, Carl Eugen And inlined to simplify reviewing: diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c index 9514ff8..71708cf 100644 --- a/libavformat/spdifenc.c +++ b/libavformat/spdifenc.c @@ -76,6 +76,14 @@ typedef struct IEC61937Context { int dtshd_skip; ///< counter used for skipping DTS-HD frames +int last_ts;///< timestamp of the last TrueHD frame to calculate spacing +int remaining; ///< bytes to the next mat code +uint8_t *buf; ///< pointer into the mat frame +uint8_t *last_frame;///< buffer for remaining bytes of incompletely written frame +int last_frame_size; +int space; ///< current delta of expected and actual frame spacing +int ratebits; ///< TrueHD ratebits, needed to calculate frame spacing + /* AVOptions: */ int dtshd_rate; int dtshd_fallback; @@ -382,56 +390,118 @@ static int spdif_header_aac(AVFormatContext *s, AVPacket *pkt) /* - * It seems Dolby TrueHD frames have to be encapsulated in MAT frames before + * Dolby TrueHD frames have to be encapsulated in MAT frames before * they can be encapsulated in IEC 61937. - * Here we encapsulate 24 TrueHD frames in a single MAT frame, padding them - * to achieve constant rate. - * The actual format of a MAT frame is unknown, but the below seems to work. - * However, it seems it is not actually necessary for the 24 TrueHD frames to - * be in an exact alignment with the MAT frame. + * A specific alignment is required to fulfill buffering requirements + * in some cases, while the average frame distance has to be constant + * actual frame distances vary depending on timestamps and frame sizes. */ #define MAT_FRAME_SIZE 61424 #define TRUEHD_FRAME_OFFSET 2560 -#define MAT_MIDDLE_CODE_OFFSET -4 +#define MAT_HALF_FRAME 30688 +static const char mat_start_code[20] = { 0x07, 0x9E, 0x00, 0x03, 0x84, 0x01, 0x01, 0x01, 0x80, 0x00, 0x56, 0xA5, 0x3B, 0xF4, 0x81 , 0x83 , 0x49, 0x80, 0x77, 0xE0 }; +static const char mat_middle_code[12] = { 0xC3, 0xC1, 0x42, 0x49, 0x3B, 0xFA, 0x82, 0x83, 0x49, 0x80, 0x77, 0xE0 }; +static const char mat_end_code[16] = { 0xC3, 0xC2, 0xC0, 0xC4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x11 }; static int spdif_header_truehd(AVFormatContext *s, AVPacket *pkt) { IEC61937Context *ctx = s->priv_data; -int mat_code_length = 0; -static const char mat_end_code[16] = { 0xC3, 0xC2, 0xC0, 0xC4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x1 1 }; - -if (!ctx->hd_buf_count) { -static const char mat_start_code[20] = { 0x07, 0x9E, 0x00, 0x03, 0x84, 0x01, 0x01, 0x01, 0x80, 0x00, 0x56, 0xA5, 0x3B, 0xF4, 0x8 1, 0x83, 0x49, 0x80, 0x77, 0xE0 }; -mat_code_length = sizeof(mat_start_code) + BURST_HEADER_SIZE; -memcpy(ctx->hd_buf, mat_start_code, sizeof(mat_start_code)); - -} else if (ctx->hd_buf_count == 12) { -static const char mat_middle_code[12] = { 0xC3, 0xC1, 0x42, 0x49, 0x3B, 0xFA, 0x82, 0x83, 0x49, 0x80, 0x77, 0xE0 }; -mat_code_length = sizeof(mat_middle_code) + MAT_MIDDLE_CODE_OFFSET; -memcpy(&ctx->hd_buf[12 * TRUEHD_FRAME_OFFSET - BURST_HEADER_SIZE + MAT_MIDDLE_CODE_OFFSET], - mat_middle_code, sizeof(mat_middle_code)); -} -if (pkt->size > TRUEHD_FRAME_OFFSET - mat_code_length) { -/* if such frames exist, we'd need some more complex logic to - * distribute the TrueHD frames in the MAT frame */ -avpriv_request_sample(s, "Too large TrueHD frame of %d bytes", - pkt->size); -return AVERROR_PATCHWELCOME; +if (pkt->size < 8 || pkt->size >= MAT_HALF_FRAME / 2) { +av_log(s, AV_LOG_ERROR, "Invalid frame size: %d\n", pkt->size); +return AVERROR(EINVAL); +} +if (ctx->last_ts == -1) +
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT
2019-02-15 0:23 GMT+01:00, Hendrik Leppkes : > On Thu, Feb 14, 2019 at 8:11 PM Carl Eugen Hoyos wrote: >> >> Hi! >> >> I created attached patch with a lot of help from Hendrik, fixes ticket >> #7731. >> > > Som general comments, since I can't replay inline in this mail client: > > - The pseudo-timestamps are unsigned 16-bit, personally I would make > all types that reference them uint16_t and rely on unsigned overflow > behavior, which is fully valid and specified - no need to handle > negatives manually, etc. I had already changed this (only for the actual timestamp difference), thank you! > - The distance between frames can be incredibly large in some streams, > I've seen it be larger then one whole MAT frame, and the output works > reliably (MAT start/middle/end codes need to be placed within the > padding space, of course). That is not supported yet, could you provide such a problematic sample? (Including the output if possible) New patch attached, Carl Eugen From 25fa80c8dfa6dd9ef4271abac94620458044a507 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Fri, 15 Feb 2019 01:11:52 +0100 Subject: [PATCH] lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT. Allows muxing large frames. Fixes ticket #7731. --- libavformat/spdifenc.c | 147 +--- 1 file changed, 113 insertions(+), 34 deletions(-) diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c index 9514ff8..71708cf 100644 --- a/libavformat/spdifenc.c +++ b/libavformat/spdifenc.c @@ -76,6 +76,14 @@ typedef struct IEC61937Context { int dtshd_skip; ///< counter used for skipping DTS-HD frames +int last_ts;///< timestamp of the last TrueHD frame to calculate spacing +int remaining; ///< bytes to the next mat code +uint8_t *buf; ///< pointer into the mat frame +uint8_t *last_frame;///< buffer for remaining bytes of incompletely written frame +int last_frame_size; +int space; ///< current delta of expected and actual frame spacing +int ratebits; ///< TrueHD ratebits, needed to calculate frame spacing + /* AVOptions: */ int dtshd_rate; int dtshd_fallback; @@ -382,56 +390,118 @@ static int spdif_header_aac(AVFormatContext *s, AVPacket *pkt) /* - * It seems Dolby TrueHD frames have to be encapsulated in MAT frames before + * Dolby TrueHD frames have to be encapsulated in MAT frames before * they can be encapsulated in IEC 61937. - * Here we encapsulate 24 TrueHD frames in a single MAT frame, padding them - * to achieve constant rate. - * The actual format of a MAT frame is unknown, but the below seems to work. - * However, it seems it is not actually necessary for the 24 TrueHD frames to - * be in an exact alignment with the MAT frame. + * A specific alignment is required to fulfill buffering requirements + * in some cases, while the average frame distance has to be constant + * actual frame distances vary depending on timestamps and frame sizes. */ #define MAT_FRAME_SIZE 61424 #define TRUEHD_FRAME_OFFSET 2560 -#define MAT_MIDDLE_CODE_OFFSET -4 +#define MAT_HALF_FRAME 30688 +static const char mat_start_code[20] = { 0x07, 0x9E, 0x00, 0x03, 0x84, 0x01, 0x01, 0x01, 0x80, 0x00, 0x56, 0xA5, 0x3B, 0xF4, 0x81 , 0x83, 0x49, 0x80, 0x77, 0xE0 }; +static const char mat_middle_code[12] = { 0xC3, 0xC1, 0x42, 0x49, 0x3B, 0xFA, 0x82, 0x83, 0x49, 0x80, 0x77, 0xE0 }; +static const char mat_end_code[16] = { 0xC3, 0xC2, 0xC0, 0xC4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x11 }; static int spdif_header_truehd(AVFormatContext *s, AVPacket *pkt) { IEC61937Context *ctx = s->priv_data; -int mat_code_length = 0; -static const char mat_end_code[16] = { 0xC3, 0xC2, 0xC0, 0xC4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x11 }; - -if (!ctx->hd_buf_count) { -static const char mat_start_code[20] = { 0x07, 0x9E, 0x00, 0x03, 0x84, 0x01, 0x01, 0x01, 0x80, 0x00, 0x56, 0xA5, 0x3B, 0xF4, 0x81, 0x83, 0x49, 0x80, 0x77, 0xE0 }; -mat_code_length = sizeof(mat_start_code) + BURST_HEADER_SIZE; -memcpy(ctx->hd_buf, mat_start_code, sizeof(mat_start_code)); - -} else if (ctx->hd_buf_count == 12) { -static const char mat_middle_code[12] = { 0xC3, 0xC1, 0x42, 0x49, 0x3B, 0xFA, 0x82, 0x83, 0x49, 0x80, 0x77, 0xE0 }; -mat_code_length = sizeof(mat_middle_code) + MAT_MIDDLE_CODE_OFFSET; -memcpy(&ctx->hd_buf[12 * TRUEHD_FRAME_OFFSET - BURST_HEADER_SIZE + MAT_MIDDLE_CODE_OFFSET], - mat_middle_code, sizeof(mat_middle_code)); -} -if (pkt->size > TRUEHD_FRAME_OFFSET - mat_code_length) { -/* if such frames exist, we'd need some more complex logic to - * distribute the TrueHD frames in the MAT frame */ -avpriv_request_sample(s, "Too large TrueHD frame of %d bytes", -
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-14 23:36 GMT+01:00, Carl Eugen Hoyos : > please mention ticket #7735. Ping! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
You changed libavfilter but didn't commit (I guess), please mention ticket #7735. (I didn't test myself, sorry if there is no issue!) I just completely missed the parts in libavfilter. I am thoroughly confused why this did not break compilation for me. Will push the missing part asap. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora decoding with mmi.
On Fri, Feb 15, 2019 at 12:13:43AM +0100, Michael Niedermayer wrote: > On Wed, Feb 13, 2019 at 05:56:50PM +0800, Shiyou Yin wrote: > > >-Original Message- > > >From: ffmpeg-devel-boun...@ffmpeg.org > > >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of gxw > > >Sent: Tuesday, February 12, 2019 6:56 PM > > >To: ffmpeg-devel@ffmpeg.org > > >Cc: gxw > > >Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora > > >decoding with mmi. > > > > > >Optimize theora decoding with mmi in functions: > > >1. ff_vp3_idct_add_mmi > > >2. ff_vp3_idct_put_mmi > > >3. ff_vp3_idct_dc_add_mmi > > >4. ff_put_no_rnd_pixels_l2_mmi > > > > > >Theora decoding speed improved about 32%(from 88fps to 116fps, Tested on > > >loongson 3A3000). > > >--- > > > libavcodec/mips/Makefile | 1 + > > > libavcodec/mips/vp3dsp_idct_mmi.c | 769 > > > + > > > libavcodec/mips/vp3dsp_init_mips.c | 14 + > > > libavcodec/mips/vp3dsp_mips.h | 6 + > > > 4 files changed, 790 insertions(+) > > > create mode 100644 libavcodec/mips/vp3dsp_idct_mmi.c > > > > > > > Verified + 1, LGTM. > > will apply one last minute issue i noticed The author looks like a nick name or user name, is that intended: "gxw " ? I mean do you want "gxw" instead of your full name ? (iam asking as it cannot be changed after pushing ...) Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT
On Thu, Feb 14, 2019 at 8:11 PM Carl Eugen Hoyos wrote: > > Hi! > > I created attached patch with a lot of help from Hendrik, fixes ticket #7731. > Som general comments, since I can't replay inline in this mail client: - The pseudo-timestamps are unsigned 16-bit, personally I would make all types that reference them uint16_t and rely on unsigned overflow behavior, which is fully valid and specified - no need to handle negatives manually, etc. - The distance between frames can be incredibly large in some streams, I've seen it be larger then one whole MAT frame, and the output works reliably (MAT start/middle/end codes need to be placed within the padding space, of course). There is a few more things I saw, but I'll respond to those from a better client in a few days when I'm back home. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-15 0:13 GMT+01:00, Hendrik Leppkes : > On Thu, Feb 14, 2019 at 11:36 PM Carl Eugen Hoyos > wrote: >> >>> No, this entire mess with duplicated ff_ symbols is specifically to >> >>> avoid having to include it in the ABI. >> >> >> >> But old libavcodec does not work with new libavutil now or am I wrong? >> > >> > Is that really a thing we expect or advertise to work? It does not seem >> > sane and I'd expect a lot of other things to explode. >> >> We don't "advertise" it but it is certainly expected from any half-sane >> project. > > Its not a problem in any "normal" case. No ff_ symbols are exported, > so dynamic linking would never use it. > What might not work in the future is mixing static libraries of > different versions, but anyone that does something like that is truely > insane anyway. That may be reasonable. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On Thu, Feb 14, 2019 at 11:36 PM Carl Eugen Hoyos wrote: > >>> No, this entire mess with duplicated ff_ symbols is specifically to > >>> avoid having to include it in the ABI. > >> > >> But old libavcodec does not work with new libavutil now or am I wrong? > > > > Is that really a thing we expect or advertise to work? It does not seem > > sane and I'd expect a lot of other things to explode. > > We don't "advertise" it but it is certainly expected from any half-sane > project. Its not a problem in any "normal" case. No ff_ symbols are exported, so dynamic linking would never use it. What might not work in the future is mixing static libraries of different versions, but anyone that does something like that is truely insane anyway. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT
On Thu, Feb 14, 2019 at 8:14 PM Carl Eugen Hoyos wrote: > > 2019-02-14 20:11 GMT+01:00, Carl Eugen Hoyos : > > > I created attached patch with a lot of help from Hendrik, fixes > > ticket #7731. > > I forgot: I still need help to fix the frame distance calculation, > how is the frame rate supposed to be used? > Iiuc, the current code only works for 48kHz audio. > You want to shift the 64 to the right by the ratebits from the TrueHD header, see ff_mlp_read_major_sync where to find it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora decoding with mmi.
On Wed, Feb 13, 2019 at 05:56:50PM +0800, Shiyou Yin wrote: > >-Original Message- > >From: ffmpeg-devel-boun...@ffmpeg.org > >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of gxw > >Sent: Tuesday, February 12, 2019 6:56 PM > >To: ffmpeg-devel@ffmpeg.org > >Cc: gxw > >Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize theora > >decoding with mmi. > > > >Optimize theora decoding with mmi in functions: > >1. ff_vp3_idct_add_mmi > >2. ff_vp3_idct_put_mmi > >3. ff_vp3_idct_dc_add_mmi > >4. ff_put_no_rnd_pixels_l2_mmi > > > >Theora decoding speed improved about 32%(from 88fps to 116fps, Tested on > >loongson 3A3000). > >--- > > libavcodec/mips/Makefile | 1 + > > libavcodec/mips/vp3dsp_idct_mmi.c | 769 > > + > > libavcodec/mips/vp3dsp_init_mips.c | 14 + > > libavcodec/mips/vp3dsp_mips.h | 6 + > > 4 files changed, 790 insertions(+) > > create mode 100644 libavcodec/mips/vp3dsp_idct_mmi.c > > > > Verified + 1, LGTM. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-14 23:17 GMT+01:00, Timo Rothenpieler : > On 14.02.2019 19:59, Carl Eugen Hoyos wrote: >> 2019-02-14 18:21 GMT+01:00, Hendrik Leppkes : >>> On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos >>> wrote: > Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : > > ffmpeg | branch: master | Timo Rothenpieler | > Fri Feb 8 22:47:01 2019 +0100| > [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | committer: Timo > Rothenpieler > > avutil/cuda_check: avoid pointlessly exporting same symbol from two > libraries > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 > --- > > libavcodec/Makefile | 6 +++--- > libavcodec/cuda_check.c | 1 - > libavutil/Makefile | 2 +- > libavutil/cuda_check.c | 45 > - Apart from breaking compilation doesn’t this also break ABI? > > I got reports about this breaking compilation in its old state, which > caused me to to turn it into a static inline header-only function. > > For my this compiles and works fine, is there any constellation/compiler > where it doesn't? You changed libavfilter but didn't commit (I guess), please mention ticket #7735. (I didn't test myself, sorry if there is no issue!) >>> No, this entire mess with duplicated ff_ symbols is specifically to >>> avoid having to include it in the ABI. >> >> But old libavcodec does not work with new libavutil now or am I wrong? > > Is that really a thing we expect or advertise to work? It does not seem > sane and I'd expect a lot of other things to explode. We don't "advertise" it but it is certainly expected from any half-sane project. >> In any case, shouldn't the function have another name if it is static >> now? > > No idea if there is any naming convention for static inline header-only > functions. I kept it as is to avoid having to touch even more files, but > renaming it is of course no big deal. I thought that "ff_" is not for static functions. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On 14.02.2019 19:59, Carl Eugen Hoyos wrote: 2019-02-14 18:21 GMT+01:00, Hendrik Leppkes : On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos wrote: Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : ffmpeg | branch: master | Timo Rothenpieler | Fri Feb 8 22:47:01 2019 +0100| [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | committer: Timo Rothenpieler avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 --- libavcodec/Makefile | 6 +++--- libavcodec/cuda_check.c | 1 - libavutil/Makefile | 2 +- libavutil/cuda_check.c | 45 - Apart from breaking compilation doesn’t this also break ABI? I got reports about this breaking compilation in its old state, which caused me to to turn it into a static inline header-only function. For my this compiles and works fine, is there any constellation/compiler where it doesn't? No, this entire mess with duplicated ff_ symbols is specifically to avoid having to include it in the ABI. But old libavcodec does not work with new libavutil now or am I wrong? Is that really a thing we expect or advertise to work? It does not seem sane and I'd expect a lot of other things to explode. In any case, shouldn't the function have another name if it is static now? No idea if there is any naming convention for static inline header-only functions. I kept it as is to avoid having to touch even more files, but renaming it is of course no big deal. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/truehd_core: Initialize the last bytes of the output buffer
2019-02-14 22:08 GMT+01:00, James Almer : > On 2/14/2019 5:59 PM, Carl Eugen Hoyos wrote: >> 2019-02-12 12:58 GMT+01:00, Carl Eugen Hoyos : >>> Hi! >>> >>> The output of truehd_core is currently undeterministic, the last bytes >>> are uninitialized, valgrind protests if less than 8 bytes are >>> initialized. >>> I believe attached patch is simpler than calculating the necessary >>> write size at the bottom of the function. >> New patch attached. >> >> Please comment, Carl Eugen >> >> >> 0001-lavc-truehd_core-Initialize-the-last-bytes-of-the-ou.patch >> >> From f3e4231af54b7a7664e1a2224cc1223be683f93c Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Thu, 14 Feb 2019 21:57:48 +0100 >> Subject: [PATCH] lavc/truehd_core: Initialize the last bytes of the output >> buffer. >> >> Avoids undeterministic output. >> --- >> libavcodec/truehd_core_bsf.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/libavcodec/truehd_core_bsf.c b/libavcodec/truehd_core_bsf.c >> index be021af..4760872 100644 >> --- a/libavcodec/truehd_core_bsf.c >> +++ b/libavcodec/truehd_core_bsf.c >> @@ -117,6 +117,8 @@ static int truehd_core_filter(AVBSFContext *ctx, >> AVPacket *out) >> out->size -= reduce * 2; >> parity_nibble ^= out->size / 2; >> >> +if (out_size > 8) >> +AV_ZERO64(out->data + out_size - 8); > > AV_ZERO# may use mmx instructions. It should be safe if no float ops are > going to be used after it, otherwise an emms_c() will be needed and the > performance hit may remove any gain you get from not using memset(). New patch with AV_WN64() attached. Thank you, Carl Eugen From 18ac7557e5d2734c2be396dcfe25ea7cfec407a7 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 14 Feb 2019 22:43:10 +0100 Subject: [PATCH] lavc/truehd_core: Initialize the last bytes of the output buffer. Avoids undeterministic output. --- libavcodec/truehd_core_bsf.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/truehd_core_bsf.c b/libavcodec/truehd_core_bsf.c index be021af..dd40e1e 100644 --- a/libavcodec/truehd_core_bsf.c +++ b/libavcodec/truehd_core_bsf.c @@ -117,6 +117,8 @@ static int truehd_core_filter(AVBSFContext *ctx, AVPacket *out) out->size -= reduce * 2; parity_nibble ^= out->size / 2; +if (out_size > 8) +AV_WN64(out->data + out_size - 8, 0); if (have_header) { memcpy(out->data + 4, in->data + 4, 28); out->data[16 + 4] = (out->data[16 + 4] & 0x0f) | (FFMIN(s->hdr.num_substreams, 3) << 4); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/hevc_ps: Expose all SPS and PPS range extension flags
On Wed, Feb 13, 2019 at 08:03:36PM -0800, Philip Langdale wrote: > We need all the flags to be exposed to be able to pass them on to > HW decoders. I did not attempt to nuance any of the warnings about > flags being unsupported as there's no way, at the point we extract > flags, to say whether an HW decoder is being used. > > Signed-off-by: Philip Langdale > --- > libavcodec/hevc_ps.c | 19 --- > libavcodec/hevc_ps.h | 4 > 2 files changed, 12 insertions(+), 11 deletions(-) should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/truehd_core: Initialize the last bytes of the output buffer
On 2/14/2019 5:59 PM, Carl Eugen Hoyos wrote: > 2019-02-12 12:58 GMT+01:00, Carl Eugen Hoyos : >> Hi! >> >> The output of truehd_core is currently undeterministic, the last bytes >> are uninitialized, valgrind protests if less than 8 bytes are >> initialized. >> I believe attached patch is simpler than calculating the necessary >> write size at the bottom of the function. > New patch attached. > > Please comment, Carl Eugen > > > 0001-lavc-truehd_core-Initialize-the-last-bytes-of-the-ou.patch > > From f3e4231af54b7a7664e1a2224cc1223be683f93c Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Thu, 14 Feb 2019 21:57:48 +0100 > Subject: [PATCH] lavc/truehd_core: Initialize the last bytes of the output > buffer. > > Avoids undeterministic output. > --- > libavcodec/truehd_core_bsf.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/truehd_core_bsf.c b/libavcodec/truehd_core_bsf.c > index be021af..4760872 100644 > --- a/libavcodec/truehd_core_bsf.c > +++ b/libavcodec/truehd_core_bsf.c > @@ -117,6 +117,8 @@ static int truehd_core_filter(AVBSFContext *ctx, AVPacket > *out) > out->size -= reduce * 2; > parity_nibble ^= out->size / 2; > > +if (out_size > 8) > +AV_ZERO64(out->data + out_size - 8); AV_ZERO# may use mmx instructions. It should be safe if no float ops are going to be used after it, otherwise an emms_c() will be needed and the performance hit may remove any gain you get from not using memset(). An x86_32 build compiled with -mmmx or an -march value that enables mmx should be enough to test it. > if (have_header) { > memcpy(out->data + 4, in->data + 4, 28); > out->data[16 + 4] = (out->data[16 + 4] & 0x0f) | > (FFMIN(s->hdr.num_substreams, 3) << 4); > -- 1.7.10.4 > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available
On Wed, Feb 13, 2019 at 11:49:21PM +0100, Mathieu Duponchelle wrote: > So, should this go in? :) if someone checks it against some spec and or tests it against some decoders, probably yes, also might be a good idea to bump the micro version of libavcodec thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/arbc: Use AV_WB24() where applicable
2019-01-27 15:18 GMT+01:00, Carl Eugen Hoyos : > Hi! > > Minimal simplification attached. Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/tiff: Allow decoding of cmyka (five components)
2019-02-07 20:07 GMT+01:00, Carl Eugen Hoyos : > Hi! > > Attached patch fixes ticket #7675. Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/truehd_core: Initialize the last bytes of the output buffer
2019-02-12 12:58 GMT+01:00, Carl Eugen Hoyos : > Hi! > > The output of truehd_core is currently undeterministic, the last bytes > are uninitialized, valgrind protests if less than 8 bytes are > initialized. > I believe attached patch is simpler than calculating the necessary > write size at the bottom of the function. New patch attached. Please comment, Carl Eugen From f3e4231af54b7a7664e1a2224cc1223be683f93c Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 14 Feb 2019 21:57:48 +0100 Subject: [PATCH] lavc/truehd_core: Initialize the last bytes of the output buffer. Avoids undeterministic output. --- libavcodec/truehd_core_bsf.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/truehd_core_bsf.c b/libavcodec/truehd_core_bsf.c index be021af..4760872 100644 --- a/libavcodec/truehd_core_bsf.c +++ b/libavcodec/truehd_core_bsf.c @@ -117,6 +117,8 @@ static int truehd_core_filter(AVBSFContext *ctx, AVPacket *out) out->size -= reduce * 2; parity_nibble ^= out->size / 2; +if (out_size > 8) +AV_ZERO64(out->data + out_size - 8); if (have_header) { memcpy(out->data + 4, in->data + 4, 28); out->data[16 + 4] = (out->data[16 + 4] & 0x0f) | (FFMIN(s->hdr.num_substreams, 3) << 4); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer
2019-02-09 15:46 GMT+01:00, Carl Eugen Hoyos : > 2019-02-09 15:44 GMT+01:00, Carl Eugen Hoyos : >> 2019-02-09 15:42 GMT+01:00, James Almer : >>> On 2/9/2019 11:23 AM, Carl Eugen Hoyos wrote: Hi! Attached patch is supposed to constify all occurrences of AVOutputFormat in libavformat. Please comment, Carl Eugen 0001-lavf-Constify-AVOutputFormat-pointer.patch From ba32f41824df07b7a6cb45964ef912c5fc05b276 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sat, 9 Feb 2019 15:21:17 +0100 Subject: [PATCH] lavf: Constify AVOutputFormat pointer. --- libavformat/allformats.c |4 libavformat/avformat.h | 15 ++- libavformat/fifo.c |4 ++-- libavformat/format.c |6 +++--- libavformat/hdsenc.c |2 +- libavformat/hlsenc.c |4 ++-- libavformat/mux.c|4 ++-- libavformat/rtp.c|2 +- libavformat/rtpenc_chain.c |2 +- libavformat/rtpenc_mpegts.c |4 ++-- libavformat/segment.c|2 +- libavformat/smoothstreamingenc.c |2 +- libavformat/version.h|3 +++ libavformat/webm_chunk.c |2 +- 14 files changed, 34 insertions(+), 22 deletions(-) diff --git a/libavformat/allformats.c b/libavformat/allformats.c index 0684498..64d0f02 100644 --- a/libavformat/allformats.c +++ b/libavformat/allformats.c @@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat *f) ff_thread_once(&av_format_next_init, av_format_init_next); if (f) +#if FF_API_AVIOFORMAT +return (AVOutputFormat *) f->next; +#else return f->next; +#endif else { void *opaque = NULL; return (AVOutputFormat *)av_muxer_iterate(&opaque); diff --git a/libavformat/avformat.h b/libavformat/avformat.h index fdaffa5..52922c0 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -532,7 +532,12 @@ typedef struct AVOutputFormat { * New public fields should be added right above. * */ -struct AVOutputFormat *next; +#if FF_API_AVIOFORMAT +#define av_const59 const +#else +#define av_const59 +#endif >>> >>> Shouldn't it be the other way around? FF_API_AVIOFORMAT >>> evaluates to 1 when major is < 59. >> >> Yes, I had realized this in the meantime, new patch attached. > > And with the correct version in version.h Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer
2019-02-09 15:51 GMT+01:00, Carl Eugen Hoyos : > 2019-02-09 14:37 GMT+01:00, Carl Eugen Hoyos : >> 2019-02-01 1:13 GMT+01:00, Michael Niedermayer : >>> On Thu, Jan 31, 2019 at 09:54:14PM +0100, Carl Eugen Hoyos wrote: 2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos : > Hi! > > Attached patch persistently uses "const" for AVInputFormat pointer > after the next version bump. Now with an actually working version. Please comment, Carl Eugen >>> allformats.c |6 +- avformat.h | 32 +++- dashdec.c|3 +++ format.c | 32 ++-- hls.c|3 +++ img2dec.c|2 +- mpeg.c |3 +++ rtpdec_asf.c |3 +++ sapdec.c |3 +++ utils.c | 11 --- version.h|3 +++ 11 files changed, 93 insertions(+), 8 deletions(-) d3aece2f0b9a9c3ff8b2a187ceccdc744ea40de2 0001-lavf-Constify-AVInputFormat-pointer.patch From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 31 Jan 2019 21:51:56 +0100 Subject: [PATCH] lavf: Constify AVInputFormat pointer. --- libavformat/allformats.c |6 +- libavformat/avformat.h | 32 +++- libavformat/dashdec.c|3 +++ libavformat/format.c | 32 ++-- libavformat/hls.c|3 +++ libavformat/img2dec.c|2 +- libavformat/mpeg.c |3 +++ libavformat/rtpdec_asf.c |3 +++ libavformat/sapdec.c |3 +++ libavformat/utils.c | 11 --- libavformat/version.h|3 +++ 11 files changed, 93 insertions(+), 8 deletions(-) diff --git a/libavformat/allformats.c b/libavformat/allformats.c index 0684498..01c4c14 100644 --- a/libavformat/allformats.c +++ b/libavformat/allformats.c @@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat *f) ff_thread_once(&av_format_next_init, av_format_init_next); if (f) -return f->next; +return +#if !FF_API_AVINPUTFORMAT + (AVInputFormat *) +#endif + f->next; else { void *opaque = NULL; return (AVInputFormat *)av_demuxer_iterate(&opaque); diff --git a/libavformat/avformat.h b/libavformat/avformat.h index fdaffa5..7c4ec8f 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -676,7 +676,10 @@ typedef struct AVInputFormat { * New public fields should be added right above. * */ -struct AVInputFormat *next; +#if !FF_API_AVINPUTFORMAT +const +#endif +struct AVInputFormat *next; >>> >>> some av_const59 which is defined to nothing until version 59 >>> should avoid the repeated #if/endif >>> it would require an eventual update to change it to const at some >>> point but it would avoid most preprocessor comands >> >> New patch attached. > > Now with correct condition. Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf:Constify AVProbeData* in av_probe_input_format()
2019-02-09 23:27 GMT+01:00, Carl Eugen Hoyos : > 2019-02-09 23:26 GMT+01:00, Carl Eugen Hoyos : >> Hi! >> >> Attached patch constifies a few pointers at the next version bump. > > And the patch. Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/spdifenc: Do not overwrite buffer when muxing TrueHD
Hi! Currently, when muxing TrueHD in spdif, the buffer is always overwritten. Typical 64bit operating systems do not care, but this should definitely be fixed before the new buffering model can get committed. Please comment, Carl Eugen From 3858971376f97241d29d4f7d3b261009af3c87a9 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 14 Feb 2019 20:16:18 +0100 Subject: [PATCH] lavf/spdifenc: Do not overwrite buffer when muxing TrueHD. Fixes ticket #7733. --- libavformat/spdifenc.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c index 9514ff8..4307942 100644 --- a/libavformat/spdifenc.c +++ b/libavformat/spdifenc.c @@ -422,8 +422,13 @@ static int spdif_header_truehd(AVFormatContext *s, AVPacket *pkt) memcpy(&ctx->hd_buf[ctx->hd_buf_count * TRUEHD_FRAME_OFFSET - BURST_HEADER_SIZE + mat_code_length], pkt->data, pkt->size); -memset(&ctx->hd_buf[ctx->hd_buf_count * TRUEHD_FRAME_OFFSET - BURST_HEADER_SIZE + mat_code_length + pkt->size], - 0, TRUEHD_FRAME_OFFSET - pkt->size - mat_code_length); +if (ctx->hd_buf_count < 23) { +memset(&ctx->hd_buf[ctx->hd_buf_count * TRUEHD_FRAME_OFFSET - BURST_HEADER_SIZE + mat_code_length + pkt->size], + 0, TRUEHD_FRAME_OFFSET - pkt->size - mat_code_length); +} else { +size_t padding = MAT_FRAME_SIZE - (ctx->hd_buf_count * TRUEHD_FRAME_OFFSET - BURST_HEADER_SIZE + pkt->size); +memset(&ctx->hd_buf[MAT_FRAME_SIZE - padding], 0, padding); +} if (++ctx->hd_buf_count < 24){ ctx->pkt_offset = 0; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT
2019-02-14 20:11 GMT+01:00, Carl Eugen Hoyos : > I created attached patch with a lot of help from Hendrik, fixes > ticket #7731. I forgot: I still need help to fix the frame distance calculation, how is the frame rate supposed to be used? Iiuc, the current code only works for 48kHz audio. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/spdifenc: Automatically insert truehd_core bitstream filter
2019-02-13 8:10 GMT+01:00, Hendrik Leppkes : > On Wed, Feb 13, 2019 at 2:57 AM Carl Eugen Hoyos wrote: >> >> 2019-02-13 0:47 GMT+01:00, Hendrik Leppkes : >> > On Tue, Feb 12, 2019 at 12:54 PM Carl Eugen Hoyos >> > wrote: >> >> >> >> 2019-02-12 12:37 GMT+01:00, Hendrik Leppkes : >> >> > On Tue, Feb 12, 2019 at 12:28 PM Carl Eugen Hoyos >> >> > >> >> > wrote: >> >> >> >> >> >> Hi! >> >> >> >> >> >> Attached patch intends to fix ticket #7731. >> >> > >> >> > This is not a fix. The vast majority of TrueHD Atmos tracks work just >> >> > fine with the current limitations, and would needlessly drop the >> >> > Atmos >> >> > information for every stream. >> >> >> >> Is it possible to detect if the Atmos core has to be dropped? >> > >> > Not beforehand, since the size of future frames is of course unknown, >> > and there are no indications in the bitstream. >> > One could consider starting to drop Atmos data after it happened once, >> > but it'll probably still glitch out audio at that point. >> > >> > Ideally the truehd spdif muxer should be revised to support a more >> > flexible buffering model, but its a tad bit complicated with the way >> > the spdif muxer is setup, and I've only recently learned myself how >> > its presumably supposed to be done, since the specifications are not >> > openly available. >> >> I did a few experiments before reading your mail: >> If I use a burst rate of significantly less than 2000 bytes >> audio gets broken with my receiver. >> Can you confirm that in any way? >> Otoh, it does not seem to help to insert memset(0) >> between frames if the burstrate is too low. >> ("burstrate": gap between beginnings of thd frames) >> >> It is not necessary to put 12 frames in both half-MAT frames, >> 15 and 9 work fine here. >> >> My receiver always fails / produces hickups if the thd stream >> contains atmos data: Are you sure it is supposed to work? > > With every hardware? Who knows. My receiver does not support Atmos > either and it plays streams that exceed the 2560 size just fine with > correct muxing into MAT frames - although I haven't tested that one in > the ticket specifically I don't think, and I'm not near that receiver > until next week. > >> Can you already provide a test stream for the audio stream >> from the ticket? >> > > Sure, why not, although I have no idea how one would play this, since > you would need to make sure full MAT frames are always read and output > as one (ie. every 61440 bytes), and unfortunately our raw PCM demuxer > does not support specifying a wanted packet size, oh well. > https://files.1f0.de/tmp/truehd_11mbit_bug.spdif This stream works with my receiver that does not support Atmon, my patch creates a bitexact output. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT
Hi! I created attached patch with a lot of help from Hendrik, fixes ticket #7731. Please review, Carl Eugen From ce97425171b06b353cf9ec71e9ff6c7e7ec49422 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 14 Feb 2019 20:07:53 +0100 Subject: [PATCH] lavf/spdifenc: Use a more flexible buffer model for TrueHD/MAT. Allows muxing large frames. Fixes ticket #7731. --- libavformat/spdifenc.c | 138 1 file changed, 104 insertions(+), 34 deletions(-) diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c index 9514ff8..59d0c27 100644 --- a/libavformat/spdifenc.c +++ b/libavformat/spdifenc.c @@ -76,6 +76,13 @@ typedef struct IEC61937Context { int dtshd_skip; ///< counter used for skipping DTS-HD frames +int last_ts;///< timestamp of the last TrueHD frame to calculate spacing +int remaining; ///< bytes to the next mat code +uint8_t *buf; ///< pointer into the mat frame +uint8_t *last_frame;///< buffer for remaining bytes of incompletely written frame +int last_frame_size; +int space; ///< current delta of expected and actual frame spacing + /* AVOptions: */ int dtshd_rate; int dtshd_fallback; @@ -382,56 +389,110 @@ static int spdif_header_aac(AVFormatContext *s, AVPacket *pkt) /* - * It seems Dolby TrueHD frames have to be encapsulated in MAT frames before + * Dolby TrueHD frames have to be encapsulated in MAT frames before * they can be encapsulated in IEC 61937. - * Here we encapsulate 24 TrueHD frames in a single MAT frame, padding them - * to achieve constant rate. - * The actual format of a MAT frame is unknown, but the below seems to work. - * However, it seems it is not actually necessary for the 24 TrueHD frames to - * be in an exact alignment with the MAT frame. + * A specific alignment is required to fulfill buffering requirements + * in some cases, while the average frame distance has to be constant + * actual frame distances vary depending on timestamps and frame sizes. */ #define MAT_FRAME_SIZE 61424 #define TRUEHD_FRAME_OFFSET 2560 -#define MAT_MIDDLE_CODE_OFFSET -4 +#define MAT_HALF_FRAME 30688 +static const char mat_start_code[20] = { 0x07, 0x9E, 0x00, 0x03, 0x84, 0x01, 0x01, 0x01, 0x80, 0x00, 0x56, 0xA5, 0x3B, 0xF4, 0x81 , 0x83, 0x49, 0x80, 0x77, 0xE0 }; +static const char mat_middle_code[12] = { 0xC3, 0xC1, 0x42, 0x49, 0x3B, 0xFA, 0x82, 0x83, 0x49, 0x80, 0x77, 0xE0 }; +static const char mat_end_code[16] = { 0xC3, 0xC2, 0xC0, 0xC4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x11 }; static int spdif_header_truehd(AVFormatContext *s, AVPacket *pkt) { IEC61937Context *ctx = s->priv_data; -int mat_code_length = 0; -static const char mat_end_code[16] = { 0xC3, 0xC2, 0xC0, 0xC4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x11 }; - -if (!ctx->hd_buf_count) { -static const char mat_start_code[20] = { 0x07, 0x9E, 0x00, 0x03, 0x84, 0x01, 0x01, 0x01, 0x80, 0x00, 0x56, 0xA5, 0x3B, 0xF4, 0x81, 0x83, 0x49, 0x80, 0x77, 0xE0 }; -mat_code_length = sizeof(mat_start_code) + BURST_HEADER_SIZE; -memcpy(ctx->hd_buf, mat_start_code, sizeof(mat_start_code)); - -} else if (ctx->hd_buf_count == 12) { -static const char mat_middle_code[12] = { 0xC3, 0xC1, 0x42, 0x49, 0x3B, 0xFA, 0x82, 0x83, 0x49, 0x80, 0x77, 0xE0 }; -mat_code_length = sizeof(mat_middle_code) + MAT_MIDDLE_CODE_OFFSET; -memcpy(&ctx->hd_buf[12 * TRUEHD_FRAME_OFFSET - BURST_HEADER_SIZE + MAT_MIDDLE_CODE_OFFSET], - mat_middle_code, sizeof(mat_middle_code)); -} -if (pkt->size > TRUEHD_FRAME_OFFSET - mat_code_length) { -/* if such frames exist, we'd need some more complex logic to - * distribute the TrueHD frames in the MAT frame */ -avpriv_request_sample(s, "Too large TrueHD frame of %d bytes", - pkt->size); -return AVERROR_PATCHWELCOME; +if (pkt->size < 8 || pkt->size >= MAT_HALF_FRAME / 2) { +av_log(s, AV_LOG_ERROR, "Invalid frame size: %d\n", pkt->size); +return AVERROR(EINVAL); +} +if (ctx->last_ts == -1 && AV_RB16(&pkt->data[4]) != SYNCWORD1) { +ctx->pkt_offset = 0; +return 0; +} +if (ctx->last_ts >= 0) { +int distance = (AV_RB16(&pkt->data[2]) - ctx->last_ts); +if (distance < 0) +distance = 65536 + AV_RB16(&pkt->data[2]) - ctx->last_ts; +distance *= 64; //FIXME +if (distance > MAT_HALF_FRAME / 4) { +av_log(s, AV_LOG_ERROR, "Invalid frame distance %d, using %d\n", distance, TRUEHD_FRAME_OFFSET); +distance = TRUEHD_FRAME_OFFSET; +} +ctx->space += distance; +} +ctx->last_ts = AV_RB16(&pkt->data[2]); +if (ctx->buf == ctx->hd_buf) { +// write mat_start_code at
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
2019-02-14 18:21 GMT+01:00, Hendrik Leppkes : > On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos wrote: >> >> >> >> > Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : >> > >> > ffmpeg | branch: master | Timo Rothenpieler | >> > Fri Feb 8 22:47:01 2019 +0100| >> > [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | committer: Timo >> > Rothenpieler >> > >> > avutil/cuda_check: avoid pointlessly exporting same symbol from two >> > libraries >> > >> >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 >> > --- >> > >> > libavcodec/Makefile | 6 +++--- >> > libavcodec/cuda_check.c | 1 - >> > libavutil/Makefile | 2 +- >> >> > libavutil/cuda_check.c | 45 >> > - >> >> Apart from breaking compilation doesn’t this also break ABI? >> > > No, this entire mess with duplicated ff_ symbols is specifically to > avoid having to include it in the ABI. But old libavcodec does not work with new libavutil now or am I wrong? In any case, shouldn't the function have another name if it is static now? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] nvenc: add support for b_adapt option also for HEVC encoder
Hi, this will add support for b_adapt for HEVC encoder, now Turing HEVC NVENC with SDK 9.0 also supports B-frames and this option is in default mode disabled. Enable it by default, because it could add around 0.02 PSNR for free. -- Miroslav Slugeň +420 724 825 885 diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c index d567d960ba..19c04e4aa7 100644 --- a/libavcodec/nvenc_hevc.c +++ b/libavcodec/nvenc_hevc.c @@ -95,6 +95,8 @@ static const AVOption options[] = { OFFSET(no_scenecut), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE }, { "forced-idr", "If forcing keyframes, force them as IDR frames.", OFFSET(forced_idr), AV_OPT_TYPE_BOOL, { .i64 = 0 }, -1, 1, VE }, +{ "b_adapt", "When lookahead is enabled, set this to 0 to disable adaptive B-frame decision", +OFFSET(b_adapt), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE }, { "spatial_aq", "set to 1 to enable Spatial AQ", OFFSET(aq), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE }, { "temporal_aq", "set to 1 to enable Temporal AQ", OFFSET(temporal_aq), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE }, { "zerolatency", "Set 1 to indicate zero latency operation (no reordering delay)", ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos wrote: > > > > > Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : > > > > ffmpeg | branch: master | Timo Rothenpieler | Fri > > Feb 8 22:47:01 2019 +0100| [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | > > committer: Timo Rothenpieler > > > > avutil/cuda_check: avoid pointlessly exporting same symbol from two > > libraries > > > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 > > --- > > > > libavcodec/Makefile | 6 +++--- > > libavcodec/cuda_check.c | 1 - > > libavutil/Makefile | 2 +- > > > libavutil/cuda_check.c | 45 - > > Apart from breaking compilation doesn’t this also break ABI? > No, this entire mess with duplicated ff_ symbols is specifically to avoid having to include it in the ABI. The compilation error should of course be fixed. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
> Am 14.02.2019 um 16:41 schrieb Dominik 'Rathann' Mierzejewski > : > >> On Sunday, 03 February 2019 at 22:24, Dominik 'Rathann' Mierzejewski wrote: >>> On Monday, 28 January 2019 at 04:54, James Almer wrote: >>> On 1/27/2019 3:43 PM, Dominik 'Rathann' Mierzejewski wrote: >> [...] If you're trying to say we can upgrade 4.0.x to 4.1.x without recompiling any dependent packages and you guarantee everything will work just like with 4.0.x, then I would be willing to entertain that option >>> >>> ffmpeg 4.1 is meant to be ABI compatible with 4.0, so you should be able >>> to replace the 4.0 libraries and anything linking to them should still >>> work without the need to be recompiled. >>> Now, "work just like with 4.0.x" is impossible to guarantee because >>> there were like five months of development between the two releases, and >>> some modules may behave slightly differently. >> >> That sounds good. I'll consider doing the upgrade. Though backporting >> the patches I asked in this thread would save me that work. > > We have 55 packages requiring FFmpeg. Some of them would require > patching to support FFmpeg 4.1.x. (Some?) > We'd really appreciate it > if you could just backport these two patches to 4.0.x. Why don’t you backport them if you believe it is a good idea? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries
> Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler : > > ffmpeg | branch: master | Timo Rothenpieler | Fri Feb > 8 22:47:01 2019 +0100| [15c6390139096b7e7634bf0f6aaab1cd8b3aa509] | > committer: Timo Rothenpieler > > avutil/cuda_check: avoid pointlessly exporting same symbol from two libraries > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=15c6390139096b7e7634bf0f6aaab1cd8b3aa509 > --- > > libavcodec/Makefile | 6 +++--- > libavcodec/cuda_check.c | 1 - > libavutil/Makefile | 2 +- > libavutil/cuda_check.c | 45 - Apart from breaking compilation doesn’t this also break ABI? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/vdpau: Enable HEVC support for working Nvidia driver versions
On Sunday, 03 February 2019 at 22:24, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 28 January 2019 at 04:54, James Almer wrote: > > On 1/27/2019 3:43 PM, Dominik 'Rathann' Mierzejewski wrote: > [...] > > > If you're trying to say we can upgrade 4.0.x to 4.1.x without > > > recompiling any dependent packages and you guarantee everything will > > > work just like with 4.0.x, then I would be willing to entertain that > > > option > > > > ffmpeg 4.1 is meant to be ABI compatible with 4.0, so you should be able > > to replace the 4.0 libraries and anything linking to them should still > > work without the need to be recompiled. > > Now, "work just like with 4.0.x" is impossible to guarantee because > > there were like five months of development between the two releases, and > > some modules may behave slightly differently. > > That sounds good. I'll consider doing the upgrade. Though backporting > the patches I asked in this thread would save me that work. We have 55 packages requiring FFmpeg. Some of them would require patching to support FFmpeg 4.1.x. We'd really appreciate it if you could just backport these two patches to 4.0.x. Regards, -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresenc_aw : add interlace encoding support
Hi, can this be merged or is more rigourous testing necessary? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content
On Thu, 14 Feb 2019 13:52:45 +0100 Timo Rothenpieler wrote: > > First patch needs ACK by the respective maintainer. Which I believe > was already done last time it was sent? > Actually not. Without the real headers, I didn't know there were new HEVC fields to set, so this part is new for this series. Thanks, --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream
On Wed, Feb 13, 2019 at 12:16:36PM +, Derek Buitenhuis wrote: > On 12/02/2019 22:28, Michael Niedermayer wrote: > > @@ -5048,7 +5048,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext > > *pb, MOVAtom atom) > > for (i = 0; i < c->fc->nb_streams; i++) { > > st = c->fc->streams[i]; > > sc = st->priv_data; > > -if (!sc->has_sidx) { > > +if (ref_st && !sc->has_sidx) { > > st->duration = sc->track_end = > > av_rescale(ref_st->duration, sc->time_scale, ref_sc->time_scale); > > } > > } > > Is it perhaps better to not run this loop at all if ref_sc or ref_st do not > exist? will commit with the check moved to the loop thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content
On 14.02.2019 05:03, Philip Langdale wrote: This is the equivalent change for cuviddec after the previous change for nvdec. I made similar changes to the copying routines to handle pixel formats in a more generic way. Note that unlike with nvdec, there is no confusion about the ability of a codec to output 444 formats. This is because the cuvid parser is used, meaning that 444 JPEG content is still indicated as using a 420 output format. Signed-off-by: Philip Langdale --- libavcodec/cuviddec.c | 66 ++- 1 file changed, 46 insertions(+), 20 deletions(-) diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c index 03589367ce..d6f9c620f4 100644 --- a/libavcodec/cuviddec.c +++ b/libavcodec/cuviddec.c @@ -34,8 +34,14 @@ #include "avcodec.h" #include "decode.h" #include "hwaccel.h" +#include "nvdec.h" #include "internal.h" +#if !NVDECAPI_CHECK_VERSION(9, 0) +#define cudaVideoSurfaceFormat_YUV444 2 +#define cudaVideoSurfaceFormat_YUV444_16Bit 3 +#endif + typedef struct CuvidContext { AVClass *avclass; @@ -106,6 +112,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form CUVIDDECODECAPS *caps = NULL; CUVIDDECODECREATEINFO cuinfo; int surface_fmt; +int chroma_444; int old_width = avctx->width; int old_height = avctx->height; @@ -148,17 +155,19 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form cuinfo.target_rect.right = cuinfo.ulTargetWidth; cuinfo.target_rect.bottom = cuinfo.ulTargetHeight; +chroma_444 = format->chroma_format == cudaVideoChromaFormat_444; + switch (format->bit_depth_luma_minus8) { case 0: // 8-bit -pix_fmts[1] = AV_PIX_FMT_NV12; +pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P : AV_PIX_FMT_NV12; caps = &ctx->caps8; break; case 2: // 10-bit -pix_fmts[1] = AV_PIX_FMT_P010; +pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P16 : AV_PIX_FMT_P010; caps = &ctx->caps10; break; case 4: // 12-bit -pix_fmts[1] = AV_PIX_FMT_P016; +pix_fmts[1] = chroma_444 ? AV_PIX_FMT_YUV444P16 : AV_PIX_FMT_P016; caps = &ctx->caps12; break; default: @@ -261,12 +270,6 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form return 0; } -if (format->chroma_format != cudaVideoChromaFormat_420) { -av_log(avctx, AV_LOG_ERROR, "Chroma formats other than 420 are not supported\n"); -ctx->internal_error = AVERROR(EINVAL); -return 0; -} - ctx->chroma_format = format->chroma_format; cuinfo.CodecType = ctx->codec_type = format->codec; @@ -280,8 +283,15 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form case AV_PIX_FMT_P016: cuinfo.OutputFormat = cudaVideoSurfaceFormat_P016; break; +case AV_PIX_FMT_YUV444P: +cuinfo.OutputFormat = cudaVideoSurfaceFormat_YUV444; +break; +case AV_PIX_FMT_YUV444P16: +cuinfo.OutputFormat = cudaVideoSurfaceFormat_YUV444_16Bit; +break; default: -av_log(avctx, AV_LOG_ERROR, "Output formats other than NV12, P010 or P016 are not supported\n"); +av_log(avctx, AV_LOG_ERROR, "Unsupported output format: %s\n", + av_get_pix_fmt_name(avctx->sw_pix_fmt)); ctx->internal_error = AVERROR(EINVAL); return 0; } @@ -490,6 +500,7 @@ static int cuvid_output_frame(AVCodecContext *avctx, AVFrame *frame) return ret; if (av_fifo_size(ctx->frame_queue)) { +const AVPixFmtDescriptor *pixdesc; CuvidParsedFrame parsed_frame; CUVIDPROCPARAMS params; unsigned int pitch = 0; @@ -520,7 +531,10 @@ static int cuvid_output_frame(AVCodecContext *avctx, AVFrame *frame) goto error; } -for (i = 0; i < 2; i++) { +pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt); + +for (i = 0; i < pixdesc->nb_components; i++) { +int height = avctx->height >> (i ? pixdesc->log2_chroma_h : 0); CUDA_MEMCPY2D cpy = { .srcMemoryType = CU_MEMORYTYPE_DEVICE, .dstMemoryType = CU_MEMORYTYPE_DEVICE, @@ -530,22 +544,25 @@ static int cuvid_output_frame(AVCodecContext *avctx, AVFrame *frame) .dstPitch = frame->linesize[i], .srcY = offset, .WidthInBytes = FFMIN(pitch, frame->linesize[i]), -.Height= avctx->height >> (i ? 1 : 0), +.Height= height, }; ret = CHECK_CU(ctx->cudl->cuMemcpy2DAsync(&cpy, device_hwctx->stream)); if (ret < 0) goto error; -offset += avctx->he
Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/nvenc_hevc: adding B frame support
On 13.02.2019 20:18, Timo Rothenpieler wrote: On 13.02.2019 09:52, Roman Arzumanyan wrote: Hello, Please find attached patch, it adds HEVC B-frames support to nvenc_hevc. This feature requires Video Codec SDK 9 + Turing card. Will it cause issues if set on an older card, or just plain get ignored? If it's ignored, this LGTM. Missed that the existing cap check will catch this. Applied smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel