[FFmpeg-devel] [Patch] lavf/mpeg: fix indent

2019-02-14 Thread Morris Stock 
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-14 Thread Wang Bin 
>
> 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.

2019-02-14 Thread guxiwei-hf 
>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

2019-02-14 Thread Michael Niedermayer 
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

2019-02-14 Thread Timo Rothenpieler 

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-14 Thread Carl Eugen Hoyos 
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-14 Thread 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
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 Thread Carl Eugen Hoyos 
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

2019-02-14 Thread Timo Rothenpieler 

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.

2019-02-14 Thread Michael Niedermayer 
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

2019-02-14 Thread 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.
- 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-14 Thread Carl Eugen Hoyos 
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

2019-02-14 Thread 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.

- 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

2019-02-14 Thread Hendrik Leppkes 
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.

2019-02-14 Thread Michael Niedermayer 
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 Thread Carl Eugen Hoyos 
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

2019-02-14 Thread 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?




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 Thread Carl Eugen Hoyos 
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

2019-02-14 Thread Michael Niedermayer 
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

2019-02-14 Thread 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().

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

2019-02-14 Thread Michael Niedermayer 
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-02-14 Thread Carl Eugen Hoyos 
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-14 Thread Carl Eugen Hoyos 
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-14 Thread Carl Eugen Hoyos 
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-14 Thread Carl Eugen Hoyos 
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-14 Thread Carl Eugen Hoyos 
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-14 Thread Carl Eugen Hoyos 
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

2019-02-14 Thread Carl Eugen Hoyos 
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 Thread Carl Eugen Hoyos 
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-14 Thread Carl Eugen Hoyos 
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

2019-02-14 Thread Carl Eugen Hoyos 
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 Thread Carl Eugen Hoyos 
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

2019-02-14 Thread Miroslav Slugeň 

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

2019-02-14 Thread 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.

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

2019-02-14 Thread Carl Eugen Hoyos 



> 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

2019-02-14 Thread Carl Eugen Hoyos 


> 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

2019-02-14 Thread 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. 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

2019-02-14 Thread Kieran O Leary 
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

2019-02-14 Thread Philip Langdale 
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

2019-02-14 Thread Michael Niedermayer 
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

2019-02-14 Thread Timo Rothenpieler 

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

2019-02-14 Thread Timo Rothenpieler 

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