Re: [FFmpeg-devel] avformat/dashdec: fix for ticket #7336

2018-07-31 Thread Liu Steven


> 在 2018年7月31日,下午11:52,jacek jogo  写道:
> 
> Hi.
> fix for ticket #7336
> <0001-fix-possible-segfault-if-dash-stream-have-only-audio.patch>___
LGTM


Thanks
> 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


[FFmpeg-devel] [PATCH] avcodec/mediacodec: add av_mediacodec_render_buffer_at_time()

2018-07-31 Thread Aman Gupta
From: Aman Gupta 

The existing av_mediacodec_release_buffer allows the user to render
or discard the Surface-backed frame. This new method allows the user
to control exactly when the frame will be rendered to it's SurfaceView.

Available since Android API 21.

Signed-off-by: Aman Gupta 
---
 doc/APIchanges  |  3 +++
 libavcodec/mediacodec.c | 21 +
 libavcodec/mediacodec.h | 13 +
 libavcodec/mediacodec_wrapper.c |  2 +-
 libavcodec/version.h|  2 +-
 5 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index efe15ba4e0..62394fd837 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-08-01 - xx - lavc 58.23.100 - mediacodec.h
+  Add av_mediacodec_render_buffer_at_time().
+
 2018-05-xx - xx - lavf 58.15.100 - avformat.h
   Add pmt_version field to AVProgram
 
diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
index b0aae43a87..aa14624fd0 100644
--- a/libavcodec/mediacodec.c
+++ b/libavcodec/mediacodec.c
@@ -102,6 +102,22 @@ int av_mediacodec_release_buffer(AVMediaCodecBuffer 
*buffer, int render)
 return 0;
 }
 
+int av_mediacodec_render_buffer_at_time(AVMediaCodecBuffer *buffer, int64_t 
time)
+{
+MediaCodecDecContext *ctx = buffer->ctx;
+int released = atomic_fetch_add(&buffer->released, 1);
+
+if (!released && (ctx->delay_flush || buffer->serial == 
atomic_load(&ctx->serial))) {
+atomic_fetch_sub(&ctx->hw_buffer_count, 1);
+av_log(ctx->avctx, AV_LOG_DEBUG,
+   "Rendering output buffer %zd (%p) ts=%"PRId64" with 
time=%"PRId64" [%d pending]\n",
+   buffer->index, buffer, buffer->pts, time, 
atomic_load(&ctx->hw_buffer_count));
+return ff_AMediaCodec_releaseOutputBufferAtTime(ctx->codec, 
buffer->index, time);
+}
+
+return 0;
+}
+
 #else
 
 #include 
@@ -125,4 +141,9 @@ int av_mediacodec_release_buffer(AVMediaCodecBuffer 
*buffer, int render)
 return AVERROR(ENOSYS);
 }
 
+int av_mediacodec_render_buffer_at_time(AVMediaCodecBuffer *buffer, int64_t 
time)
+{
+return AVERROR(ENOSYS);
+}
+
 #endif
diff --git a/libavcodec/mediacodec.h b/libavcodec/mediacodec.h
index 5606d24a1e..4c8545df03 100644
--- a/libavcodec/mediacodec.h
+++ b/libavcodec/mediacodec.h
@@ -85,4 +85,17 @@ typedef struct MediaCodecBuffer AVMediaCodecBuffer;
  */
 int av_mediacodec_release_buffer(AVMediaCodecBuffer *buffer, int render);
 
+/**
+ * Release a MediaCodec buffer and render it at the given time to the surface
+ * that is associated with the decoder. The timestamp must be within one second
+ * of the current java/lang/System#nanoTime() (which is implemented using
+ * CLOCK_MONOTONIC on Android). See the Android MediaCodec documentation
+ * of android/media/MediaCodec#releaseOutputBuffer(int,long) for more details.
+ *
+ * @param buffer the buffer to render
+ * @param time timestamp in nanoseconds of when to render the buffer
+ * @return 0 on success, < 0 otherwise
+ */
+int av_mediacodec_render_buffer_at_time(AVMediaCodecBuffer *buffer, int64_t 
time);
+
 #endif /* AVCODEC_MEDIACODEC_H */
diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index c47c2c9a41..a024e3bdb1 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -1432,7 +1432,7 @@ int 
ff_AMediaCodec_releaseOutputBufferAtTime(FFAMediaCodec *codec, size_t idx, i
 
 JNI_GET_ENV_OR_RETURN(env, codec, AVERROR_EXTERNAL);
 
-(*env)->CallVoidMethod(env, codec->object, 
codec->jfields.release_output_buffer_at_time_id, (jint)idx, timestampNs);
+(*env)->CallVoidMethod(env, codec->object, 
codec->jfields.release_output_buffer_at_time_id, (jint)idx, (jlong)timestampNs);
 if (ff_jni_exception_check(env, 1, codec) < 0) {
 ret = AVERROR_EXTERNAL;
 goto fail;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 3f0d98efdf..a91e5f01e6 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  58
-#define LIBAVCODEC_VERSION_MINOR  22
+#define LIBAVCODEC_VERSION_MINOR  23
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavf: add avs2 demuxer

2018-07-31 Thread Michael Niedermayer
On Tue, Jul 31, 2018 at 11:02:20PM +0800, hwren wrote:
> Signed-off-by: hwren 
> ---
>  libavformat/Makefile |  1 +
>  libavformat/allformats.c |  1 +
>  libavformat/davs2.c  | 64 
> 
>  3 files changed, 66 insertions(+)
>  create mode 100644 libavformat/davs2.c
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index f2f3aab..c4534b8 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -110,6 +110,7 @@ OBJS-$(CONFIG_AST_DEMUXER)   += ast.o astdec.o
>  OBJS-$(CONFIG_AST_MUXER) += ast.o astenc.o
>  OBJS-$(CONFIG_AU_DEMUXER)+= au.o pcm.o
>  OBJS-$(CONFIG_AU_MUXER)  += au.o rawenc.o
> +OBJS-$(CONFIG_AVS2_DEMUXER)  += davs2.o rawdec.o
>  OBJS-$(CONFIG_AVI_DEMUXER)   += avidec.o
>  OBJS-$(CONFIG_AVI_MUXER) += avienc.o mpegtsenc.o 
> avlanguage.o rawutils.o
>  OBJS-$(CONFIG_AVM2_MUXER)+= swfenc.o swf.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index adcc8d9..38eaeea 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -76,6 +76,7 @@ extern AVInputFormat  ff_avisynth_demuxer;
>  extern AVOutputFormat ff_avm2_muxer;
>  extern AVInputFormat  ff_avr_demuxer;
>  extern AVInputFormat  ff_avs_demuxer;
> +extern AVInputFormat  ff_avs2_demuxer;
>  extern AVInputFormat  ff_bethsoftvid_demuxer;
>  extern AVInputFormat  ff_bfi_demuxer;
>  extern AVInputFormat  ff_bintext_demuxer;
> diff --git a/libavformat/davs2.c b/libavformat/davs2.c
> new file mode 100644
> index 000..8c90fd8
> --- /dev/null
> +++ b/libavformat/davs2.c
> @@ -0,0 +1,64 @@
> +/*
> + * AVS2 video stream probe.
> + *
> + * Copyright (C) 2018 Huiwen Ren, 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "avformat.h"
> +#include "rawdec.h"
> +#include "libavcodec/internal.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#define ISSQH(x)  ((x) == 0xB0 )
> +#define ISEND(x)  ((x) == 0xB1 )
> +#define ISPIC(x)  ((x) == 0xB3 || (x) == 0xB6)
> +#define ISUNIT(x) ( ISSQH(x) || ISEND(x) || (x) == 0xB2 || ISPIC(x) || (x) 
> == 0xB5 || (x) == 0xB7 )
> +#define ISAVS2(x) ((x) == 0x12 || (x) == 0x20 || (x) == 0x22 || (x) == 0x30 
> || (x) == 0x32 )
> +
> +static int avs2_probe(AVProbeData *p)
> +{
> +uint32_t code= -1;
> +uint8_t state=0;
> +const uint8_t *ptr = p->buf, *end = p->buf + p->buf_size, *sqb=0;
> +
> +while (ptr < end) {
> +ptr = avpriv_find_start_code(ptr, end, &code);
> +state = code & 0xFF;
> +if ((code & 0xff00) == 0x100) {
> +if (ISUNIT(state)) {
> +if (sqb) {
> +break;
> +}
> +if (ISSQH(state)) {
> +if (!ISAVS2(*ptr))
> +return 0;
> +sqb = ptr;
> +} else if (ISEND(state)) {
> +return 0;
> +}
> +}
> +}
> +}
> +if (sqb && ptr-sqb >= 21){
> +return AVPROBE_SCORE_EXTENSION+2;
> +}
> +return 0;
> +}

this fails
tools/probetest 256 4096


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]tools/qt-faststart: Allow free atoms after moov atom

2018-07-31 Thread Carl Eugen Hoyos
2018-07-25 20:37 GMT+02:00, Carl Eugen Hoyos :
> 2018-07-19 23:18 GMT+02:00, Carl Eugen Hoyos :
>> 2018-07-12 1:28 GMT+02:00, Carl Eugen Hoyos :
>>
>>> Attached patch allows to fast-start mov files with free atoms after
>>> the moov atom.
>>> Tested with the sample from ticket #7277.
>>
>> Ping.
>>
>> As this is not trivial to test, I would prefer not to "improve" the patch
>> until another sample appears.
>
> I will push this patch if nobody objects.

Patch applied.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Why does ffmpeg h264 decoder stop decoding when certain type of packets are coming in the input stream?

2018-07-31 Thread Carl Eugen Hoyos
2018-07-28 14:57 GMT+02:00, Naveed Basha :
> Yes, please find the test stream here. I was using ffmpeg v3.4.2.
>
> https://drive.google.com/open?id=1rHCfG4csA3rB4LSgErEBn1F3WfI5nUVr

This is now ticket #7340, thank you for the sample.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavc/svq3: Fix regression decoding some files.

2018-07-31 Thread Carl Eugen Hoyos
2018-07-31 2:22 GMT+02:00, Nikolas Bowe :
> Fixes some SVQ3 encoded files which fail to decode correctly after
> 6d6faa2a2d.

Please provide a sample.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] hlsenc.c changes for fMP4

2018-07-31 Thread Ronak
Hi,

I've made changes to the code inside of hlsenc.c to resolve this issue: 
https://trac.ffmpeg.org/ticket/7281 . I've 
verified my changes with mpegts separate files, mpegts single file & fMP4 
single file, and everything is working fine.

I'd like to find out how I can verify live HLS streaming use cases. Is there a 
way I can verify this? I'd like verify this before I submit patch for 
consideration for merging into ffmpeg trunk.

Thanks,

Ronak
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH]lavf/dashdec: Do not copy url on init copy

2018-07-31 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes ticket #7338, better fix welcome!

Please comment, Carl Eugen
From a967c8d11872d7163175ed946abdc80dcce8f37a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 1 Aug 2018 00:04:32 +0200
Subject: [PATCH] lavf/dashdec: Do not copy url address on init copy.

Fixes ticket #7338.
---
 libavformat/dashdec.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 89f3ac2..12e7535 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1902,6 +1902,7 @@ static void copy_init_section(struct representation *rep_dest, struct representa
 *rep_dest->init_section = *rep_src->init_section;
 rep_dest->init_sec_buf = av_mallocz(rep_src->init_sec_buf_size);
 memcpy(rep_dest->init_sec_buf, rep_src->init_sec_buf, rep_src->init_sec_data_len);
+rep_dest->init_section->url = NULL;
 rep_dest->init_sec_buf_size = rep_src->init_sec_buf_size;
 rep_dest->init_sec_data_len = rep_src->init_sec_data_len;
 rep_dest->cur_timestamp = rep_src->cur_timestamp;
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec/mediacodecdec: fix SEGV on modern nvidia decoders

2018-07-31 Thread Aman Gupta
From: Aman Gupta 

This code came originally from gstreamer, where it was added in [1]
as a work-around for the Tegra 3. (The alignment was changed in [2]
as a response to [3], from 32-bit to 16-bit).

gstreamer only used this workaround in the case where the decoder
didn't return a slice-height property, but when the code was copied
into avcodec the conditional got lost. This commit restores the guard
and prefers the slice-height from the decoder when it is available.

This fixes segfaults decoding 1920x1080 h264 and mpeg2 videos on the
NVidia SHIELD after upgrading to Android Oreo.

[1] 
https://github.com/GStreamer/gst-plugins-bad/commit/a870e6a5c30dd85240fe75c7409cc1cf1b86541d
[2] 
https://github.com/GStreamer/gst-plugins-bad/commit/21ff3ae0b0127bd82951d278ca24f2d54133b7cd
[3] https://bugzilla.gnome.org/show_bug.cgi?id=748867

Signed-off-by: Aman Gupta 
---
 libavcodec/mediacodecdec_common.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index 887865a281..f235dae71b 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -389,13 +389,14 @@ static int mediacodec_dec_parse_format(AVCodecContext 
*avctx, MediaCodecDecConte
 s->stride = s->stride > 0 ? s->stride : s->width;
 
 AMEDIAFORMAT_GET_INT32(s->slice_height, "slice-height", 0);
-s->slice_height = s->slice_height > 0 ? s->slice_height : s->height;
 
-if (strstr(s->codec_name, "OMX.Nvidia.")) {
+if (strstr(s->codec_name, "OMX.Nvidia.") && s->slice_height == 0) {
 s->slice_height = FFALIGN(s->height, 16);
 } else if (strstr(s->codec_name, "OMX.SEC.avc.dec")) {
 s->slice_height = avctx->height;
 s->stride = avctx->width;
+} else if (s->slice_height == 0) {
+s->slice_height = s->height;
 }
 
 AMEDIAFORMAT_GET_INT32(s->color_format, "color-format", 1);
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] qt-faststart: Add mode for probing faststart-ness

2018-07-31 Thread Baptiste Coudurier
Hey Tomas,

On Sat, Jul 28, 2018 at 1:56 AM, Tomas Härdin  wrote:

> lör 2018-07-28 klockan 10:31 +0530 skrev Gyan Doshi:
> >
> > On 28-07-2018 03:33 AM, Tomas Härdin wrote:
> > >
> > > woot! I didn't know the mov demuxer dumped such things. It is quite
> > > slow however, since it will scan through every leaf atom in the
> > > file.
> > > For example, running time ffmpeg -i input.mov -v 56 2>&1 | wc on a
> > > 1.5
> > > GiB MP4 on an SSD takes:
> >
> > Use the subfile protocol to forgo parsing the whole file, e.g.
> >
> >  ffmpeg -i subfile,,start,0,end,1,,:in.mp4 -v 56 2>&1 | grep
> > -e
> > "type:'moov'" -e "type:'mdat'" | head -1 | grep moov
> >
> > This assumes that at least one of the two targeted boxes moov/mdat
> > start
> > within the first 1 bytes.
>
> Neat. This is similar to the first suggestion I had to the peertube
> devs, dd:ing off the first MiB or so then probing that. We'll see what
> they say, and what Baptiste thinks I guess


Interesting, I can see the interest of checking this. Could ffprobe do that
somehow ?
Would be an interesting information to report.
Not sure it belongs in qt-faststart, and not sure checking fragmented files
would be in
the scope of qt-faststart. What do you think ?

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_sw_buffer: Fix segmentation fault with decoding on android oreo (corrected)

2018-07-31 Thread Aman Gupta
On Thu, Jul 19, 2018 at 10:08 AM Peter Bennett  wrote:

> This is a correction of the earlier submission of this patch.
>
> avcodec_receive_frame consistently causes a seg fault when decoding 1080i
> mpeg2
> on android version oreo. When copying the frame, the second plane in the
> buffer
> follows on immediately after 1080 lines of the first plane, but the code
> assumes
> it is after 1088 lines of the first plane, based on slice_height. It
> crashes on
> copying data for the second plane when it hits the actual end of the data
> and
> starts accessing addresses beyond that.
>
> Instead of using slice_height here, change to use use height. slice_height
> is
> used at other places in this module and I do not know if they also need to
> be
> changed. I have confirmed that with this change, decoding works correctly
> on android oreo as well as on the prior version, android nougat.
>

This issue is not specific to 1080i mpeg2, and can be reproduced with 1080p
h264 as well.

slice_height is definitely the correct variable to use here. The problem is
it is not being set correctly. I will send an updated patch.

Aman


> ---
>  libavcodec/mediacodec_sw_buffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/mediacodec_sw_buffer.c
> b/libavcodec/mediacodec_sw_buffer.c
> index 92428e85f0..30a53f05b3 100644
> --- a/libavcodec/mediacodec_sw_buffer.c
> +++ b/libavcodec/mediacodec_sw_buffer.c
> @@ -150,7 +150,7 @@ void
> ff_mediacodec_sw_buffer_copy_yuv420_semi_planar(AVCodecContext *avctx,
>  } else if (i == 1) {
>  height = avctx->height / 2;
>
> -src += s->slice_height * s->stride;
> +src += s->height * s->stride;
>  src += s->crop_top * s->stride;
>  src += s->crop_left;
>  }
> --
> 2.17.1
>
> ___
> 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


[FFmpeg-devel] [PATCH] aadec: alternate mp3 seek handling

2018-07-31 Thread Karsten Otto
After seeking, determine the offset of the next frame in the decrypted
buffer by scanning the first few bytes for a valid mp3 header.
This significantly improves the listening experience for audio content
with untypical encoding.
---
This is a refinement of an earlier patch iteration, according to lessons
learned and discussions on the mailing list: Scan a limited range to find
the first shifted frame only, check for a very specific bit pattern, and
add extra checks and guards for better code maintainability.

Unfortunately, this variant violates the architectural layering between
demuxer and codec. But I did some more testing with untypical encodings,
where the current estimation mechanism fails, and the resulting audio on
seek was just too horribly annoying.

I believe the better listening experience outweighs the architectural
uglyness, so this should be in the official code base. But if you think
otherwise, just let me know, and I will keep this a private patch.

 libavformat/aadec.c | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/libavformat/aadec.c b/libavformat/aadec.c
index d83f283ffe..9b1495c218 100644
--- a/libavformat/aadec.c
+++ b/libavformat/aadec.c
@@ -37,7 +37,7 @@
 #define TEA_BLOCK_SIZE 8
 #define CHAPTER_HEADER_SIZE 8
 #define TIMEPREC 1000
-#define MP3_FRAME_SIZE 104
+#define MP3_FRAME_SIZE 105
 
 typedef struct AADemuxContext {
 AVClass *class;
@@ -51,7 +51,7 @@ typedef struct AADemuxContext {
 int64_t current_chapter_size;
 int64_t content_start;
 int64_t content_end;
-int seek_offset;
+int did_seek;
 } AADemuxContext;
 
 static int get_second_size(char *codec_name)
@@ -179,7 +179,7 @@ static int aa_read_header(AVFormatContext *s)
 st->codecpar->sample_rate = 22050;
 st->need_parsing = AVSTREAM_PARSE_FULL_RAW;
 avpriv_set_pts_info(st, 64, 8, 32000 * TIMEPREC);
-// encoded audio frame is MP3_FRAME_SIZE bytes (+1 with padding, 
unlikely)
+// encoded audio frame is MP3_FRAME_SIZE bytes (-1 without padding)
 } else if (!strcmp(codec_name, "acelp85")) {
 st->codecpar->codec_id = AV_CODEC_ID_SIPR;
 st->codecpar->block_align = 19;
@@ -231,7 +231,7 @@ static int aa_read_header(AVFormatContext *s)
 ff_update_cur_dts(s, st, 0);
 avio_seek(pb, start, SEEK_SET);
 c->current_chapter_size = 0;
-c->seek_offset = 0;
+c->did_seek = 0;
 
 return 0;
 }
@@ -244,7 +244,7 @@ static int aa_read_packet(AVFormatContext *s, AVPacket *pkt)
 int trailing_bytes;
 int blocks;
 uint8_t buf[MAX_CODEC_SECOND_SIZE * 2];
-int written = 0;
+int written = 0, offset = 0;
 int ret;
 AADemuxContext *c = s->priv_data;
 uint64_t pos = avio_tell(s->pb);
@@ -297,16 +297,33 @@ static int aa_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (c->current_chapter_size <= 0)
 c->current_chapter_size = 0;
 
-if (c->seek_offset > written)
-c->seek_offset = 0; // ignore wrong estimate
+if (c->did_seek) {
+c->did_seek = 0;
+
+if (s->streams[0]->codecpar->codec_id == AV_CODEC_ID_MP3 && written >= 
MP3_FRAME_SIZE + 3) {
+for (offset = 0; offset < MP3_FRAME_SIZE; ++offset) {
+// find mp3 header: sync, v2, layer3, no crc, 32kbps, 22kHz, 
mono
+if ((buf[offset + 0]   ) == 0xff &&
+(buf[offset + 1]   ) == 0xf3 &&
+(buf[offset + 2] & 0xfc) == 0x40 &&
+(buf[offset + 3] & 0xf0) == 0xc0)
+break;
+}
+if (offset == MP3_FRAME_SIZE) offset = 0; // not found, just use 
as is
+}
+
+ff_update_cur_dts(s, s->streams[0],
+(pos + offset - c->content_start - CHAPTER_HEADER_SIZE * 
(c->chapter_idx - 1))
+* TIMEPREC);
+}
 
-ret = av_new_packet(pkt, written - c->seek_offset);
+if (offset > written) offset = 0;
+ret = av_new_packet(pkt, written - offset);
 if (ret < 0)
 return ret;
-memcpy(pkt->data, buf + c->seek_offset, written - c->seek_offset);
+memcpy(pkt->data, buf + offset, written - offset);
 pkt->pos = pos;
 
-c->seek_offset = 0;
 return 0;
 }
 
@@ -349,13 +366,7 @@ static int aa_read_seek(AVFormatContext *s,
 c->current_codec_second_size = c->codec_second_size;
 c->current_chapter_size = chapter_size - chapter_pos;
 c->chapter_idx = 1 + chapter_idx;
-
-// for unaligned frames, estimate offset of first frame in block (assume 
no padding)
-if (s->streams[0]->codecpar->codec_id == AV_CODEC_ID_MP3) {
-c->seek_offset = (MP3_FRAME_SIZE - chapter_pos % MP3_FRAME_SIZE) % 
MP3_FRAME_SIZE;
-}
-
-ff_update_cur_dts(s, s->streams[0], ch->start + (chapter_pos + 
c->seek_offset) * TIMEPREC);
+c->did_seek = 1;
 
 return 1;
 }
-- 
2.14.3 (Apple Git-98)

___
ffmpeg-devel mailing list
ffmpeg-de

[FFmpeg-devel] avformat/dashdec: fix for ticket #7336

2018-07-31 Thread jacek jogo
Hi.
fix for ticket #7336
From a8948069bbf8995414bb20f578a1553c522b5d06 Mon Sep 17 00:00:00 2001
From: Jacek Jendrzej 
Date: Mon, 30 Jul 2018 17:17:14 +0200
Subject: [PATCH] fix possible segfault, if dash stream have only audio or
 video pid

---
 libavformat/dashdec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 89f3ac2759..f0939f4425 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1936,7 +1936,8 @@ static int dash_read_header(AVFormatContext *s)
 s->duration = (int64_t) c->media_presentation_duration * AV_TIME_BASE;
 }
 
-c->is_init_section_common_video = is_common_init_section_exist(c->videos, c->n_videos);
+if(c->n_videos)
+c->is_init_section_common_video = is_common_init_section_exist(c->videos, c->n_videos);
 
 /* Open the demuxer for video and audio components if available */
 for (i = 0; i < c->n_videos; i++) {
@@ -1952,7 +1953,8 @@ static int dash_read_header(AVFormatContext *s)
 ++stream_index;
 }
 
-  c->is_init_section_common_audio = is_common_init_section_exist(c->audios, c->n_audios);
+if(c->n_audios)
+c->is_init_section_common_audio = is_common_init_section_exist(c->audios, c->n_audios);
 
 for (i = 0; i < c->n_audios; i++) {
 struct representation *cur_audio = c->audios[i];
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter

2018-07-31 Thread Pedro Arthur
2018-07-28 14:31 GMT-03:00 Pedro Arthur :
> 2018-07-27 14:24 GMT-03:00 Rostislav Pehlivanov :
>> On 27 July 2018 at 18:12, Rostislav Pehlivanov  wrote:
>>
>>>
>>> And the coding style is just the tip, there are dozens of things I
>>> disagree with, such as the custom float to 8 bit conversions, when filters
>>> already exist which take in floats (zscale).
>>>
>>
>> I should probably expand on what I mean by the custom float conversion:
>> make the filter accept a float pixel format, such as AV_PIX_FMT_GBRPF32. We
>> have one, we use it in vf_tonemap and vf_zscale. Users will need to specify
>> a filter to convert to float first, which will match what they have to do
>> for vf_zscale and vf_tonemap. If you need to process YUV then add a float
>> YUV format, but please, don't do custom conversions in filters.
> It seems there is a patch adding YUV float formats in the ml, I asked
> the student to make a patch removing the conversion and supporting
> only float formats when the yuv float format get in the tree.
Just to update on the matter, there are currently two patches on ml,
one which fixes the code style and one which removes a huge amount of
stored data from the sr filter.
We are working on removing the format conversion from sr filter,
adding the needed floating formats to swscale.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/2] fate: add decoder test for avs2

2018-07-31 Thread James Almer
On 7/31/2018 9:17 AM, hwren wrote:
> Signed-off-by: hwren 
> ---
>  tests/Makefile|  1 +
>  tests/fate/avs2.mak   |  9 +
>  tests/ref/fate/avs2-davs2 | 98 
> +++
>  3 files changed, 108 insertions(+)
>  create mode 100644 tests/fate/avs2.mak
>  create mode 100644 tests/ref/fate/avs2-davs2
> 
> diff --git a/tests/Makefile b/tests/Makefile
> index 24680b8..5ded6a4 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -102,6 +102,7 @@ include $(SRC_PATH)/tests/fate/api.mak
>  include $(SRC_PATH)/tests/fate/apng.mak
>  include $(SRC_PATH)/tests/fate/atrac.mak
>  include $(SRC_PATH)/tests/fate/audio.mak
> +include $(SRC_PATH)/tests/fate/avs2.mak
>  include $(SRC_PATH)/tests/fate/bmp.mak
>  include $(SRC_PATH)/tests/fate/build.mak
>  include $(SRC_PATH)/tests/fate/canopus.mak
> diff --git a/tests/fate/avs2.mak b/tests/fate/avs2.mak
> new file mode 100644
> index 000..dd08e4a
> --- /dev/null
> +++ b/tests/fate/avs2.mak
> @@ -0,0 +1,9 @@
> +FATE_LIBDAVS2 = davs2
> +
> +FATE_LIBDAVS2  := $(FATE_LIBDAVS2:%=fate-avs2-%)
> +
> +FATE_SAMPLES_AVCONV += $(FATE_LIBDAVS2)
> +FATE_SAMPLES_FFPROBE += $(FATE_LIBDAVS2_FFPROBE-yes)
> +fate-libdavs2: $(FATE_LIBDAVS2) $(FATE_LIBDAVS2_FFPROBE-yes)
> +
> +fate-avs2-davs2: CMD = framecrc -vsync drop -vcodec libdavs2 
> -i $(TARGET_SAMPLES)/avs2/test.avs2 -flags +bitexact

We don't add tests for decoders that require external dependencies.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 1/2] docs/filters: add documentation to all existing OpenCL filters

2018-07-31 Thread Danil Iashchenko
docs/filters: add documentation to all existing OpenCL filters

---

Thanks for your comments! Most of the issues have been fixed.

>The filer source has many more options defined.
>In addition, there are many missing values for the tonemap algo; it appears 
>not all are effected. If that's the case, remove or note that in the AVOptions 
>table.

It seems I'd need more time than expected to fully acquaint myself with 
tonemap_opencl so as to write appropriately detailed documentation, (as you 
said, there are a lot of options, and it's unclear which ones are actually 
working). 
This hinders overall progress on the documentation and filter implementation of 
my GSoC project and there is not much time left. I suggest putting it on the 
backburner for the moment and leaving it out until the next patch.
Again, only tonemap_opencl presents an issue; the rest of the documentation is 
fine.

 doc/filters.texi | 413 +++
 1 file changed, 413 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 705d48e..5c081d3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17545,6 +17545,419 @@ pixel format "yuv422p" @var{hsub} is 2 and @var{vsub} 
is 1.
 
 @c man end VIDEO FILTERS
 
+@chapter OpenCL Video Filters
+@c man begin OPENCL VIDEO FILTERS
+
+Below is a description of the currently available OpenCL video filters.
+
+To enable compilation of these filters you need to configure FFmpeg with
+@code{--enable-opencl}.
+
+Running OpenCL filters requires you to initialize a hardware device and to 
pass that device to all filters in any filter graph. 
+@table @option
+
+@item -init_hw_device 
@var{type}[=@var{name}][:@var{device}[,@var{key=value}...]]
+Initialise a new hardware device of type @var{opencl} called @var{name}, using 
the
+given device parameters.
+
+@item -filter_hw_device @var{name}
+Pass the hardware device called @var{name} to all filters in any filter graph.
+
+@end table
+
+For more detailed information see 
@url{https://www.ffmpeg.org/ffmpeg.html#Advanced-Video-options}
+
+@itemize
+@item
+Example of choosing the first device on the second platform and running 
avgblur_opencl filter with default parameters on it.
+@example
+-init_hw_device opencl=gpu:1.0 -filter_hw_device gpu -i INPUT -vf "hwupload, 
avgblur_opencl, hwdownload" OUTPUT 
+@end example
+@end itemize
+
+@section avgblur_opencl
+
+Apply average blur filter.
+
+The filter accepts the following options:
+
+@table @option
+@item sizeX
+Set horizontal radius size.
+Range is @code{[1, 1024]} and default value is @code{1}.
+
+@item planes
+Set which planes to filter. By default value @code{0xf}, all planes will be 
processed.
+
+@item sizeY
+Set vertical radius size, if zero it will be same as @code{sizeX}.
+Range is @code{[1, 1024]} and default value is @code{0}.
+@end table
+
+@subsection Example
+
+@itemize
+@item
+Apply average blur filter with horizontal and vertical size of 3, setting each 
pixel of the output to the average value of the 7x7 region centered on it in 
the input. For pixels on the edges of the image, the region does not extend 
beyond the image boundaries, and so out-of-range coordinates are not used in 
the calculations.
+@example
+-i INPUT -vf "hwupload, avgblur_opencl=3, hwdownload" OUTPUT
+@end example
+@end itemize
+
+@section boxblur_opencl
+
+Apply a boxblur algorithm to the input video.
+
+It accepts the following parameters:
+
+@table @option
+
+@item luma_radius, lr
+@item luma_power, lp
+@item chroma_radius, cr
+@item chroma_power, cp
+@item alpha_radius, ar
+@item alpha_power, ap
+
+@end table
+
+A description of the accepted options follows.
+
+@table @option
+@item luma_radius, lr
+@item chroma_radius, cr
+@item alpha_radius, ar
+Set an expression for the box radius in pixels used for blurring the
+corresponding input plane.
+
+The radius value must be a non-negative number, and must not be
+greater than the value of the expression @code{min(w,h)/2} for the
+luma and alpha planes, and of @code{min(cw,ch)/2} for the chroma
+planes.
+
+Default value for @option{luma_radius} is "2". If not specified,
+@option{chroma_radius} and @option{alpha_radius} default to the
+corresponding value set for @option{luma_radius}.
+
+The expressions can contain the following constants:
+@table @option
+@item w
+@item h
+The input width and height in pixels.
+
+@item cw
+@item ch
+The input chroma image width and height in pixels.
+
+@item hsub
+@item vsub
+The horizontal and vertical chroma subsample values. For example, for the
+pixel format "yuv422p", @var{hsub} is 2 and @var{vsub} is 1.
+@end table
+
+@item luma_power, lp
+@item chroma_power, cp
+@item alpha_power, ap
+Specify how many times the boxblur filter is applied to the
+corresponding plane.
+
+Default value for @option{luma_power} is 2. If not specified,
+@option{chroma_power} and @option{alpha_power} default to the
+corresponding value set for @option{luma_power}.
+
+A value of 0 will disable the eff

Re: [FFmpeg-devel] [PATCH 5/5] avformat/matroskaenc: update AV1 support

2018-07-31 Thread James Almer
On 7/31/2018 3:37 AM, Steve Lhomme wrote:
> On 30/07/2018 17:13, James Almer wrote:
>> On 7/30/2018 2:03 AM, Steve Lhomme wrote:
>>> On 26/07/2018 03:11, James Almer wrote:
 Make sure to not write forbidden OBUs to CodecPrivate, and do the same
 with
 unnecessary OBUs for packets.
>>> Does this include reordering the OBUs ? The first one must be the
>>> Sequence Header OBU. Also it must be the only one of that kind.
>> No, it doesn't. I can make that change, but why does it matter if it's
>> the first? Why can't a metadata OBU be before a Seq Header? isobmff
> 
> Because if the spec say it's the first and its enforced, the OBU parser
> needed at the container level may be simpler. The muxing side can have
> more complexity if needed.

Nothing in the spec says it's the first, afaics, just that in a temporal
unit if present it must prepend a frame. I may be misreading it, though.

In any case, my suggestion in the isobmff issue includes ordering of
OBUs in av1C.

> 
>> doesn't care what's first, only what's in.
> 
> I requested that the same constraint be applied in ISOBMFF
> https://github.com/AOMediaCodec/av1-isobmff/pull/47#issuecomment-408598719
> 
>> A parser is currently forced to know how to read OBUs anyway, and it
>> could just skip any metadata obu before the sequence header.
>>
>> For that matter, i do agree with
>> https://github.com/AOMediaCodec/av1-isobmff/issues/7#issuecomment-406257234
>>
>> and
>> https://github.com/AOMediaCodec/av1-isobmff/issues/46#issuecomment-406516226
>>
>> that perhaps av1C should, much like hvcC, avcC and in it's own way also
>> vpcC, contain a bunch of header bytes listing some basic information
>> (and therefore the entire thing, sans atom size and fourcc, be included
>> in CodecPrivate verbatim). Things like profile, level, and maybe number
>> of OBUs, before the raw OBUs.
>> As an extra benefit than simply removing the requirement for demuxers to
>> parse OBUs that may even only be in sample data just to see if the file
>> can be decoded (firing up a hardware decoder can be expensive), it would
>> also give us a way to identify the source of the bitstream (mp4/mkv vs
>> ivf/raw/annexb/etc), for example for the purpose of inserting the
>> extradata Seq Header if not present on key frames (Matroska allows to
>> remove it, but isobmff in section 2.5 seems to want a sync sample to be
>> a fully compliant RAP without the need of extradata obus, despite the
>> description in section 2.4.4), achieved by writing and using an
>> av1_mp4tolobf bsf or similar, which would then be included where needed
>> instead of the naive dump_extradata one from patch 2/5 of this set, for
>> example.
> 
> I totally support this. In the end storing OBUs in extra data is
> becoming a PITA, especially if it needs to be prepended to some frames
> but not all. If we stick to a simpler structure with what's needed to
> identify decoder properties (mostly the profile) it would make things a
> lot easier.

The process of assembling a bitstream for the purpose of decoding or
storing is up to the implementation. The requirement for the global Seq
Headers to be prepended to key frames for raw bitstream purposes is
essentially the same as sps/pps/vps from h264 and h265.

ffmpeg's decoders keep global headers in extradata to use them as they
see fit (native decoders), or request the aid of bitstream filters like
h264_mp4toannexb to assemble the bitstream using said extradata if
required (hardware decoders, some external decoders). Similarly, muxers
for non global header containers (ivf, raw, etc) do the same on their
own, or with the aid of a bitstream filter.

> 
>>
 Signed-off-by: James Almer 
 ---
    libavformat/matroskaenc.c | 6 ++
    1 file changed, 6 insertions(+)

 diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
 index b7ff1950d3..816ddd059a 100644
 --- a/libavformat/matroskaenc.c
 +++ b/libavformat/matroskaenc.c
 @@ -21,6 +21,7 @@
      #include 
    +#include "av1.h"
    #include "avc.h"
    #include "hevc.h"
    #include "avformat.h"
 @@ -769,6 +770,9 @@ static int
 mkv_write_native_codecprivate(AVFormatContext *s, AVIOContext *pb,
    ff_isom_write_hvcc(dyn_cp, par->extradata,
   par->extradata_size, 0);
    return 0;
 +    case AV_CODEC_ID_AV1:
 +    return ff_isom_write_av1c(dyn_cp, par->extradata,
 +  par->extradata_size);
    case AV_CODEC_ID_ALAC:
    if (par->extradata_size < 36) {
    av_log(s, AV_LOG_ERROR,
 @@ -2120,6 +2124,8 @@ static void mkv_write_block(AVFormatContext *s,
 AVIOContext *pb,
     (AV_RB24(par->extradata) == 1 ||
 AV_RB32(par->extradata) == 1))
    /* extradata is Annex B, assume the bitstream is too and
 convert it */
    ff_hevc_annexb2mp4_buf(pkt->data, &data, &size

[FFmpeg-devel] [PATCH] lavf: add avs2 demuxer

2018-07-31 Thread hwren
Signed-off-by: hwren 
---
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/davs2.c  | 64 
 3 files changed, 66 insertions(+)
 create mode 100644 libavformat/davs2.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index f2f3aab..c4534b8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -110,6 +110,7 @@ OBJS-$(CONFIG_AST_DEMUXER)   += ast.o astdec.o
 OBJS-$(CONFIG_AST_MUXER) += ast.o astenc.o
 OBJS-$(CONFIG_AU_DEMUXER)+= au.o pcm.o
 OBJS-$(CONFIG_AU_MUXER)  += au.o rawenc.o
+OBJS-$(CONFIG_AVS2_DEMUXER)  += davs2.o rawdec.o
 OBJS-$(CONFIG_AVI_DEMUXER)   += avidec.o
 OBJS-$(CONFIG_AVI_MUXER) += avienc.o mpegtsenc.o avlanguage.o 
rawutils.o
 OBJS-$(CONFIG_AVM2_MUXER)+= swfenc.o swf.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index adcc8d9..38eaeea 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -76,6 +76,7 @@ extern AVInputFormat  ff_avisynth_demuxer;
 extern AVOutputFormat ff_avm2_muxer;
 extern AVInputFormat  ff_avr_demuxer;
 extern AVInputFormat  ff_avs_demuxer;
+extern AVInputFormat  ff_avs2_demuxer;
 extern AVInputFormat  ff_bethsoftvid_demuxer;
 extern AVInputFormat  ff_bfi_demuxer;
 extern AVInputFormat  ff_bintext_demuxer;
diff --git a/libavformat/davs2.c b/libavformat/davs2.c
new file mode 100644
index 000..8c90fd8
--- /dev/null
+++ b/libavformat/davs2.c
@@ -0,0 +1,64 @@
+/*
+ * AVS2 video stream probe.
+ *
+ * Copyright (C) 2018 Huiwen Ren, 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "rawdec.h"
+#include "libavcodec/internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define ISSQH(x)  ((x) == 0xB0 )
+#define ISEND(x)  ((x) == 0xB1 )
+#define ISPIC(x)  ((x) == 0xB3 || (x) == 0xB6)
+#define ISUNIT(x) ( ISSQH(x) || ISEND(x) || (x) == 0xB2 || ISPIC(x) || (x) == 
0xB5 || (x) == 0xB7 )
+#define ISAVS2(x) ((x) == 0x12 || (x) == 0x20 || (x) == 0x22 || (x) == 0x30 || 
(x) == 0x32 )
+
+static int avs2_probe(AVProbeData *p)
+{
+uint32_t code= -1;
+uint8_t state=0;
+const uint8_t *ptr = p->buf, *end = p->buf + p->buf_size, *sqb=0;
+
+while (ptr < end) {
+ptr = avpriv_find_start_code(ptr, end, &code);
+state = code & 0xFF;
+if ((code & 0xff00) == 0x100) {
+if (ISUNIT(state)) {
+if (sqb) {
+break;
+}
+if (ISSQH(state)) {
+if (!ISAVS2(*ptr))
+return 0;
+sqb = ptr;
+} else if (ISEND(state)) {
+return 0;
+}
+}
+}
+}
+if (sqb && ptr-sqb >= 21){
+return AVPROBE_SCORE_EXTENSION+2;
+}
+return 0;
+}
+
+FF_DEF_RAWVIDEO_DEMUXER(avs2, "raw AVS2-P2/IEEE 1857.4", avs2_probe, 
"avs,avs2", AV_CODEC_ID_AVS2)
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/2] fate: add decoder test for avs2

2018-07-31 Thread Huiwen Ren
The avs2 sample used in this patch could be temporary found in

https://gitee.com/hwren/avs2_samples/blob/master/ES/BasketballPass_416x240_50_ai/test.avs2

please download test.avs2 and put it as fate-suite/avs2/test.avs2









At 2018-07-31 20:17:12, "hwren"  wrote:
>Signed-off-by: hwren 
>---
> tests/Makefile|  1 +
> tests/fate/avs2.mak   |  9 +
> tests/ref/fate/avs2-davs2 | 98 +++
> 3 files changed, 108 insertions(+)
> create mode 100644 tests/fate/avs2.mak
> create mode 100644 tests/ref/fate/avs2-davs2
>
>diff --git a/tests/Makefile b/tests/Makefile
>index 24680b8..5ded6a4 100644
>--- a/tests/Makefile
>+++ b/tests/Makefile
>@@ -102,6 +102,7 @@ include $(SRC_PATH)/tests/fate/api.mak
> include $(SRC_PATH)/tests/fate/apng.mak
> include $(SRC_PATH)/tests/fate/atrac.mak
> include $(SRC_PATH)/tests/fate/audio.mak
>+include $(SRC_PATH)/tests/fate/avs2.mak
> include $(SRC_PATH)/tests/fate/bmp.mak
> include $(SRC_PATH)/tests/fate/build.mak
> include $(SRC_PATH)/tests/fate/canopus.mak
>diff --git a/tests/fate/avs2.mak b/tests/fate/avs2.mak
>new file mode 100644
>index 000..dd08e4a
>--- /dev/null
>+++ b/tests/fate/avs2.mak
>@@ -0,0 +1,9 @@
>+FATE_LIBDAVS2 = davs2
>+
>+FATE_LIBDAVS2  := $(FATE_LIBDAVS2:%=fate-avs2-%)
>+
>+FATE_SAMPLES_AVCONV += $(FATE_LIBDAVS2)
>+FATE_SAMPLES_FFPROBE += $(FATE_LIBDAVS2_FFPROBE-yes)
>+fate-libdavs2: $(FATE_LIBDAVS2) $(FATE_LIBDAVS2_FFPROBE-yes)
>+
>+fate-avs2-davs2: CMD = framecrc -vsync drop -vcodec libdavs2 
>-i $(TARGET_SAMPLES)/avs2/test.avs2 -flags +bitexact
>diff --git a/tests/ref/fate/avs2-davs2 b/tests/ref/fate/avs2-davs2
>new file mode 100644
>index 000..45448bf
>--- /dev/null
>+++ b/tests/ref/fate/avs2-davs2
>@@ -0,0 +1,98 @@
>+#tb 0: 1/50
>+#media_type 0: video
>+#codec_id 0: rawvideo
>+#dimensions 0: 416x240
>+#sar 0: 0/1
>+0,  0,  0,1,   149760, 0xe846980b
>+0,  1,  1,1,   149760, 0x8da0b6a5
>+0,  2,  2,1,   149760, 0x4e870abb
>+0,  3,  3,1,   149760, 0x9b6319c7
>+0,  4,  4,1,   149760, 0xf6406852
>+0,  5,  5,1,   149760, 0xf114c48b
>+0,  6,  6,1,   149760, 0xf687e7cc
>+0,  7,  7,1,   149760, 0x7fe42bbd
>+0,  8,  8,1,   149760, 0x6bf62c4e
>+0,  9,  9,1,   149760, 0xd73466dc
>+0, 10, 10,1,   149760, 0x90dca2b4
>+0, 11, 11,1,   149760, 0x8debab8e
>+0, 12, 12,1,   149760, 0x417ca7ad
>+0, 13, 13,1,   149760, 0xf553a64a
>+0, 14, 14,1,   149760, 0x7d22e5b3
>+0, 15, 15,1,   149760, 0x34700a54
>+0, 16, 16,1,   149760, 0xed001612
>+0, 17, 17,1,   149760, 0xfeab6089
>+0, 18, 18,1,   149760, 0x4cb26215
>+0, 19, 19,1,   149760, 0x4edf76c3
>+0, 20, 20,1,   149760, 0xabad8cb7
>+0, 21, 21,1,   149760, 0x7e909e0a
>+0, 22, 22,1,   149760, 0xf401c95e
>+0, 23, 23,1,   149760, 0x116ad718
>+0, 24, 24,1,   149760, 0xe1dae8a3
>+0, 25, 25,1,   149760, 0xf2d218f7
>+0, 26, 26,1,   149760, 0xb71f22e3
>+0, 27, 27,1,   149760, 0xd17d3435
>+0, 28, 28,1,   149760, 0x70de3926
>+0, 29, 29,1,   149760, 0x17b05086
>+0, 30, 30,1,   149760, 0x07526799
>+0, 31, 31,1,   149760, 0x74165cef
>+0, 32, 32,1,   149760, 0x162c7875
>+0, 33, 33,1,   149760, 0xf05c7f17
>+0, 34, 34,1,   149760, 0xaa16880b
>+0, 35, 35,1,   149760, 0xb5bb91ea
>+0, 36, 36,1,   149760, 0xfa42af20
>+0, 37, 37,1,   149760, 0xa044b73b
>+0, 38, 38,1,   149760, 0xc527cdf0
>+0, 39, 39,1,   149760, 0x1aa4c33d
>+0, 40, 40,1,   149760, 0x7a4502ad
>+0, 41, 41,1,   149760, 0xfea42c93
>+0, 42, 42,1,   149760, 0x8f675f4d
>+0, 43, 43,1,   149760, 0xd0a560d8
>+0, 44, 44,1,   149760, 0xa10a5b1e
>+0, 45, 45,1,   149760, 0x9b2f71be
>+0, 46, 46,1,   149760, 0x475b6478
>+0, 47, 47,1,   149760, 0xf0046092
>+0, 48, 48,1,   149760, 0x1e035e28
>+0, 49, 49,1,   149760, 0xc8706662
>+0, 50, 50,1,   149760, 0x666a9752
>+0, 51, 51,1,   149760, 0x55ada842

[FFmpeg-devel] [PATCH 1/2] lavc/libdavs2.c: change log level

2018-07-31 Thread hwren
preper for fate test, the info-level param will be added later.

Signed-off-by: hwren 
---
 libavcodec/libdavs2.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 12db1f9..676b6fc 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -51,7 +51,7 @@ static av_cold int davs2_init(AVCodecContext *avctx)
 
 /* init the decoder */
 cad->param.threads  = avctx->thread_count;
-cad->param.info_level   = 0;
+cad->param.info_level   = DAVS2_LOG_WARNING;
 cad->decoder= davs2_decoder_open(&cad->param);
 
 if (!cad->decoder) {
@@ -59,7 +59,6 @@ static av_cold int davs2_init(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-av_log(avctx, AV_LOG_VERBOSE, "decoder created. %p\n", cad->decoder);
 return 0;
 }
 
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/2] fate: add decoder test for avs2

2018-07-31 Thread hwren
Signed-off-by: hwren 
---
 tests/Makefile|  1 +
 tests/fate/avs2.mak   |  9 +
 tests/ref/fate/avs2-davs2 | 98 +++
 3 files changed, 108 insertions(+)
 create mode 100644 tests/fate/avs2.mak
 create mode 100644 tests/ref/fate/avs2-davs2

diff --git a/tests/Makefile b/tests/Makefile
index 24680b8..5ded6a4 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -102,6 +102,7 @@ include $(SRC_PATH)/tests/fate/api.mak
 include $(SRC_PATH)/tests/fate/apng.mak
 include $(SRC_PATH)/tests/fate/atrac.mak
 include $(SRC_PATH)/tests/fate/audio.mak
+include $(SRC_PATH)/tests/fate/avs2.mak
 include $(SRC_PATH)/tests/fate/bmp.mak
 include $(SRC_PATH)/tests/fate/build.mak
 include $(SRC_PATH)/tests/fate/canopus.mak
diff --git a/tests/fate/avs2.mak b/tests/fate/avs2.mak
new file mode 100644
index 000..dd08e4a
--- /dev/null
+++ b/tests/fate/avs2.mak
@@ -0,0 +1,9 @@
+FATE_LIBDAVS2 = davs2
+
+FATE_LIBDAVS2  := $(FATE_LIBDAVS2:%=fate-avs2-%)
+
+FATE_SAMPLES_AVCONV += $(FATE_LIBDAVS2)
+FATE_SAMPLES_FFPROBE += $(FATE_LIBDAVS2_FFPROBE-yes)
+fate-libdavs2: $(FATE_LIBDAVS2) $(FATE_LIBDAVS2_FFPROBE-yes)
+
+fate-avs2-davs2: CMD = framecrc -vsync drop -vcodec libdavs2 
-i $(TARGET_SAMPLES)/avs2/test.avs2 -flags +bitexact
diff --git a/tests/ref/fate/avs2-davs2 b/tests/ref/fate/avs2-davs2
new file mode 100644
index 000..45448bf
--- /dev/null
+++ b/tests/ref/fate/avs2-davs2
@@ -0,0 +1,98 @@
+#tb 0: 1/50
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 416x240
+#sar 0: 0/1
+0,  0,  0,1,   149760, 0xe846980b
+0,  1,  1,1,   149760, 0x8da0b6a5
+0,  2,  2,1,   149760, 0x4e870abb
+0,  3,  3,1,   149760, 0x9b6319c7
+0,  4,  4,1,   149760, 0xf6406852
+0,  5,  5,1,   149760, 0xf114c48b
+0,  6,  6,1,   149760, 0xf687e7cc
+0,  7,  7,1,   149760, 0x7fe42bbd
+0,  8,  8,1,   149760, 0x6bf62c4e
+0,  9,  9,1,   149760, 0xd73466dc
+0, 10, 10,1,   149760, 0x90dca2b4
+0, 11, 11,1,   149760, 0x8debab8e
+0, 12, 12,1,   149760, 0x417ca7ad
+0, 13, 13,1,   149760, 0xf553a64a
+0, 14, 14,1,   149760, 0x7d22e5b3
+0, 15, 15,1,   149760, 0x34700a54
+0, 16, 16,1,   149760, 0xed001612
+0, 17, 17,1,   149760, 0xfeab6089
+0, 18, 18,1,   149760, 0x4cb26215
+0, 19, 19,1,   149760, 0x4edf76c3
+0, 20, 20,1,   149760, 0xabad8cb7
+0, 21, 21,1,   149760, 0x7e909e0a
+0, 22, 22,1,   149760, 0xf401c95e
+0, 23, 23,1,   149760, 0x116ad718
+0, 24, 24,1,   149760, 0xe1dae8a3
+0, 25, 25,1,   149760, 0xf2d218f7
+0, 26, 26,1,   149760, 0xb71f22e3
+0, 27, 27,1,   149760, 0xd17d3435
+0, 28, 28,1,   149760, 0x70de3926
+0, 29, 29,1,   149760, 0x17b05086
+0, 30, 30,1,   149760, 0x07526799
+0, 31, 31,1,   149760, 0x74165cef
+0, 32, 32,1,   149760, 0x162c7875
+0, 33, 33,1,   149760, 0xf05c7f17
+0, 34, 34,1,   149760, 0xaa16880b
+0, 35, 35,1,   149760, 0xb5bb91ea
+0, 36, 36,1,   149760, 0xfa42af20
+0, 37, 37,1,   149760, 0xa044b73b
+0, 38, 38,1,   149760, 0xc527cdf0
+0, 39, 39,1,   149760, 0x1aa4c33d
+0, 40, 40,1,   149760, 0x7a4502ad
+0, 41, 41,1,   149760, 0xfea42c93
+0, 42, 42,1,   149760, 0x8f675f4d
+0, 43, 43,1,   149760, 0xd0a560d8
+0, 44, 44,1,   149760, 0xa10a5b1e
+0, 45, 45,1,   149760, 0x9b2f71be
+0, 46, 46,1,   149760, 0x475b6478
+0, 47, 47,1,   149760, 0xf0046092
+0, 48, 48,1,   149760, 0x1e035e28
+0, 49, 49,1,   149760, 0xc8706662
+0, 50, 50,1,   149760, 0x666a9752
+0, 51, 51,1,   149760, 0x55ada842
+0, 52, 52,1,   149760, 0xff0fb577
+0, 53, 53,1,   149760, 0x0139e4ed
+0, 54, 54,1,   149760, 0x2f25f117
+0, 55, 55,1,   149760, 0xcd0f18da
+0, 56, 56,1,   149760, 0xef443f15
+0, 57, 57,1,   149760, 0xb3718577
+0, 58, 

Re: [FFmpeg-devel] [PATCH] avformat/librtmp: fix returning EOF from Read/Write

2018-07-31 Thread Timo Rothenpieler

Am 28.07.2018 um 11:48 schrieb Jan Ekström:

On Thu, Jul 26, 2018 at 1:20 PM, Timo Rothenpieler
 wrote:

---
  libavformat/librtmp.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
index f3cfa9a8e2..43013e46e0 100644
--- a/libavformat/librtmp.c
+++ b/libavformat/librtmp.c
@@ -261,7 +261,10 @@ static int rtmp_write(URLContext *s, const uint8_t *buf, 
int size)
  LibRTMPContext *ctx = s->priv_data;
  RTMP *r = &ctx->rtmp;

-return RTMP_Write(r, buf, size);
+int ret = RTMP_Write(r, buf, size);
+if (!ret)
+return AVERROR_EOF;
+return ret;
  }

  static int rtmp_read(URLContext *s, uint8_t *buf, int size)
@@ -269,7 +272,10 @@ static int rtmp_read(URLContext *s, uint8_t *buf, int size)
  LibRTMPContext *ctx = s->priv_data;
  RTMP *r = &ctx->rtmp;

-return RTMP_Read(r, buf, size);
+int ret = RTMP_Read(r, buf, size);
+if (!ret)
+return AVERROR_EOF;
+return ret;
  }

  static int rtmp_read_pause(URLContext *s, int pause)
--
2.18.0



Cheers, these things just keep popping up it seems :) . Generally I've
done something along the lines of return ret ? ret : AVERROR_EOF; ,
but that's just a stylistic thing.

Jan


I'm starting to wonder if adding it to the write function is even 
correct. The only way I see the function returning 0 is when it actually 
did not write anything because the size was < 11.




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] Why does ffmpeg h264 decoder stop decoding when certain type of packets are coming in the input stream?

2018-07-31 Thread Naveed Basha
Hi,

I was debugging the issue to find out that when there are certain IDR (PPS)
AVPackets in the stream the h264 decoder stops decoding AVPackets after
that.
I am unclear as to if there is something wrong with ffmpeg h264 decoder and
needs a fix or if it is a normal behavior and application programmer has to
adopt some logic?
Could someone please help me with this?


On Sat, Jul 28, 2018 at 6:27 PM Naveed Basha  wrote:

> Yes, please find the test stream here. I was using ffmpeg v3.4.2.
>
> https://drive.google.com/open?id=1rHCfG4csA3rB4LSgErEBn1F3WfI5nUVr
>
> On Sat, Jul 28, 2018 at 6:36 AM Michael Niedermayer 
> wrote:
>
>> On Fri, Jul 27, 2018 at 05:27:44PM +0530, Naveed Basha wrote:
>> > Hi All,
>> >
>> > I used av_read_frame to get the AVPacket from encoded h264 file. But
>> when
>> > this packet (00 00 01 05 94 5a 33 e7 4d 6b d7 ad 13 86 ff 47 83 93 31
>> f1 e3
>> > 0a) is in the input stream (h264 video) ffmpeg decoder stops decoding
>> > frames for any subsequent AVPackets. But if I skip this packet to
>> provide
>> > to the decoder the next AVPackets decode just fine.
>> >
>> > Could you please help me to find what is wrong with this packet? Or
>> what is
>> > wrong with the ffmpeg decoder?
>> > Thanks,
>> > Naveed
>>
>> do you have some testcase for reproducing this ?
>>
>> thx
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
> --
> Cheers,
> Naveed
>


-- 
Cheers,
Naveed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/4] vf_tonemap: Update the default peak values

2018-07-31 Thread Vittorio Giovara
On Wed, Jul 25, 2018 at 5:46 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> When there is no metadata attached to a frame, take into account both
> the PQ and HLG transfers, and change the HLG default value to 10:
> the value of 12 is the maximum range in scene referred light, but
> the reference OOTF maps this from 0 to 1000 cd/m² on the ideal HLG
> monitor.
>
> This matches what vf_tonemap_opencl does.
> ---
>  libavfilter/vf_tonemap.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

haasn was suggesting to change the title to `vf_tonemap: Fix the logic for
detecting the maximum peak of untagged sources` in order to better describe
the contents of this patch (and avoid having to split this simple change).
If no objections I'll amend the commit title and push soon.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel