Re: [FFmpeg-devel] [PATCH 13/26] vaapi_encode: Add quality level to common options

[Xiang, Haihao]

On Sun, 2018-04-22 at 16:29 +0100, Mark Thompson wrote:
> This was previously accessible only via AVCodecContext.compression_level
> for all encoders except H.264 where it was also a private option.  This
> makes it an explicit option everywhere.
> ---
>  libavcodec/vaapi_encode.c  | 87 ++---
> -
>  libavcodec/vaapi_encode.h  |  8 
>  libavcodec/vaapi_encode_h264.c |  6 ---
>  3 files changed, 62 insertions(+), 39 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 9c39bcdeff..a5eb072843 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1381,6 +1381,52 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  return 0;
>  }
>  
> +static av_cold int vaapi_encode_init_quality(AVCodecContext *avctx)
> +{
> +#if VA_CHECK_VERSION(0, 36, 0)
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAStatus vas;
> +VAConfigAttrib attr = { VAConfigAttribEncQualityRange };
> +
> +vas = vaGetConfigAttributes(ctx->hwctx->display,
> +ctx->va_profile,
> +ctx->va_entrypoint,
> +, 1);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query quality "
> +   "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR_EXTERNAL;
> +}
> +
> +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> +if (ctx->quality != 0) {
> +av_log(avctx, AV_LOG_WARNING, "Quality attribute is not "
> +   "supported: will use default quality level.\n");
> +}
> +} else {
> +if (ctx->quality > attr.value) {
> +av_log(avctx, AV_LOG_WARNING, "Invalid quality level: "
> +   "valid range is 0-%d, using %d.\n",
> +   attr.value, attr.value);
> +ctx->quality = attr.value;
> +}
> +
> +ctx->quality_params.misc.type =
> +VAEncMiscParameterTypeQualityLevel;
> +ctx->quality_params.quality.quality_level =
> +ctx->quality;
> +
> +vaapi_encode_add_global_param(avctx, >quality_params.misc,
> +  sizeof(ctx->quality_params));
> +}
> +#else
> +av_log(avctx, AV_LOG_WARNING, "The encode quality option is "
> +   "not supported with this VAAPI version.\n");
> +#endif
> +
> +return 0;
> +}
> +
>  static void vaapi_encode_free_output_buffer(void *opaque,
>  uint8_t *data)
>  {
> @@ -1562,6 +1608,14 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
>  if (err < 0)
>  goto fail;
>  
> +if (!ctx->quality)
> +ctx->quality = avctx->compression_level;


0 means the default quality level in use in VAAPI, so does it make sense to
assign avctx->compression_level which is not FF_COMPRESSION_DEFAULT to ctx-
>quality?


> +if (ctx->quality >= 0) {
> +err = vaapi_encode_init_quality(avctx);
> +if (err < 0)
> +goto fail;
> +}
> +
>  vas = vaCreateConfig(ctx->hwctx->display,
>   ctx->va_profile, ctx->va_entrypoint,
>   ctx->config_attributes, ctx->nb_config_attributes,
> @@ -1611,39 +1665,6 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
>  goto fail;
>  }
>  
> -if (avctx->compression_level >= 0) {
> -#if VA_CHECK_VERSION(0, 36, 0)
> -VAConfigAttrib attr = { VAConfigAttribEncQualityRange };
> -
> -vas = vaGetConfigAttributes(ctx->hwctx->display,
> -ctx->va_profile,
> -ctx->va_entrypoint,
> -, 1);
> -if (vas != VA_STATUS_SUCCESS) {
> -av_log(avctx, AV_LOG_WARNING, "Failed to query quality "
> -   "attribute: will use default compression level.\n");
> -} else {
> -if (avctx->compression_level > attr.value) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid compression "
> -   "level: valid range is 0-%d, using %d.\n",
> -   attr.value, attr.value);
> -avctx->compression_level = attr.value;
> -}
> -
> -ctx->quality_params.misc.type =
> -VAEncMiscParameterTypeQualityLevel;
> -ctx->quality_params.quality.quality_level =
> -avctx->compression_level;
> -
> -vaapi_encode_add_global_param(avctx, >quality_params.misc,
> -  sizeof(ctx->quality_params));
> -}
> -#else
> -av_log(avctx, AV_LOG_WARNING, "The encode compression level "
> -   "option is not supported with this VAAPI version.\n");
> -#endif
> -}
> -
>  ctx->input_order  = 0;
>  ctx->output_delay = 

Re: [FFmpeg-devel] [PATCH] fix memory leak of parsing dash MPD

[Steven Liu]

> On 20 Apr 2018, at 11:33, Steven Liu  wrote:
> 
> 
> 
>> On 19 Apr 2018, at 20:28, guikunzhi  wrote:
>> 
>> Signed-off-by: guikunzhi 
>> ---
>> libavformat/dashdec.c | 14 +++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>> 
>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>> index 6304ad933b..b9f1a40dfe 100644
>> --- a/libavformat/dashdec.c
>> +++ b/libavformat/dashdec.c
>> @@ -706,6 +706,7 @@ static int resolve_content_path(AVFormatContext *s, 
>> const char *url, int *max_ur
>>char *baseurl = NULL;
>>char *root_url = NULL;
>>char *text = NULL;
>> +char *tmp = NULL;
>> 
>>int isRootHttp = 0;
>>char token ='/';
>> @@ -735,9 +736,11 @@ static int resolve_content_path(AVFormatContext *s, 
>> const char *url, int *max_ur
>>goto end;
>>}
>>av_strlcpy(text, url, strlen(url)+1);
>> -while (mpdName = av_strtok(text, "/", ))  {
>> +tmp = text;
>> +while (mpdName = av_strtok(tmp, "/", ))  {
>>size = strlen(mpdName);
>>}
>> +av_free(text);
>> 
>>path = av_mallocz(tmp_max_url_size);
>>tmp_str = av_mallocz(tmp_max_url_size);
>> @@ -796,6 +799,7 @@ end:
>>}
>>av_free(path);
>>av_free(tmp_str);
>> +xmlFree(baseurl);
>>return updated;
>> 
>> }
>> @@ -1121,6 +1125,7 @@ static int parse_manifest(AVFormatContext *s, const 
>> char *url, AVIOContext *in)
>>xmlNodePtr root_element = NULL;
>>xmlNodePtr node = NULL;
>>xmlNodePtr period_node = NULL;
>> +xmlNodePtr tmp_node = NULL;
>>xmlNodePtr mpd_baseurl_node = NULL;
>>xmlNodePtr period_baseurl_node = NULL;
>>xmlNodePtr period_segmenttemplate_node = NULL;
>> @@ -1215,8 +1220,10 @@ static int parse_manifest(AVFormatContext *s, const 
>> char *url, AVIOContext *in)
>>xmlFree(val);
>>}
>> 
>> -mpd_baseurl_node = find_child_node_by_name(node, "BaseURL");
>> -if (!mpd_baseurl_node) {
>> +tmp_node = find_child_node_by_name(node, "BaseURL");
>> +if (tmp_node) {
>> +mpd_baseurl_node = xmlCopyNode(tmp_node,1);
>> +} else {
>>mpd_baseurl_node = xmlNewNode(NULL, "BaseURL");
>>}
>> 
>> @@ -1270,6 +1277,7 @@ cleanup:
>>/*free the document */
>>xmlFreeDoc(doc);
>>xmlCleanupParser();
>> +xmlFreeNode(mpd_baseurl_node);
>>}
>> 
>>av_free(new_url);
>> -- 
>> 2.14.3 (Apple Git-98)
>> 
>> 
> 
> LGTM

Applied!

Thanks
Steven





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

[FFmpeg-devel] [PATCH 1/2] ffmpeg: handling copyts use case in forced key frames functionality

[vdixit]

From: Vishwanath Dixit 

Forced key frames creation functionality was assuming the first PTS
value to be zero, but, when 'copyts' is enalbed, the first PTS can
be any big number. This was eventually forcing all the frames as
key frames. To overcome this issue, the actual first PTS value has
to be considered.
---
 fftools/ffmpeg.c | 5 -
 fftools/ffmpeg_opt.c | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe721..d9bb78a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1227,7 +1227,7 @@ static void do_video_out(OutputFile *of,
 in_picture->pict_type = 0;
 
 pts_time = in_picture->pts != AV_NOPTS_VALUE ?
-in_picture->pts * av_q2d(enc->time_base) : NAN;
+(in_picture->pts - ost->first_pts) * av_q2d(enc->time_base) : NAN;
 if (ost->forced_kf_index < ost->forced_kf_count &&
 in_picture->pts >= ost->forced_kf_pts[ost->forced_kf_index]) {
 ost->forced_kf_index++;
@@ -1477,6 +1477,9 @@ static int reap_filters(int flush)
 filtered_frame->pts =
 av_rescale_q(filtered_frame->pts, filter_tb, 
enc->time_base) -
 av_rescale_q(start_time, AV_TIME_BASE_Q, enc->time_base);
+
+if (ost->first_pts == AV_NOPTS_VALUE)
+ost->first_pts = filtered_frame->pts;
 }
 //if (ost->source_index >= 0)
 //*filtered_frame= 
*input_streams[ost->source_index]->decoded_frame; //for me_threshold
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 8ae68ae..24efbd7 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1510,6 +1510,7 @@ static OutputStream *new_output_stream(OptionsContext *o, 
AVFormatContext *oc, e
 input_streams[source_index]->st->discard = 
input_streams[source_index]->user_set_discard;
 }
 ost->last_mux_dts = AV_NOPTS_VALUE;
+ost->first_pts = AV_NOPTS_VALUE;
 
 ost->muxing_queue = av_fifo_alloc(8 * sizeof(AVPacket));
 if (!ost->muxing_queue)
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/2] ffmpeg: handling copyts use case in progress report computation

[vdixit]

From: Vishwanath Dixit 

Progress report computation functionality was assuming the first
PTS value to be zero, but, when 'copyts' is enalbed, the first PTS
can be any big number. This was eventually causing display of
weird statistics during execution of an ffmpeg command. To overcome
this issue, the actual first PTS value has to be considered.
---
 fftools/ffmpeg.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d9bb78a..9b71525 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1646,7 +1646,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 int frame_number, vid, i;
 double bitrate;
 double speed;
-int64_t pts = INT64_MIN + 1;
+int64_t pts = INT64_MIN + 1, first_pts = INT64_MAX;
 static int64_t last_time = -1;
 static int qp_histogram[52];
 int hours, mins, secs, us;
@@ -1744,6 +1744,11 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 }
 vid = 1;
 }
+
+/* Find the first written PTS among all the output streams */
+first_pts = FFMIN(first_pts, av_rescale_q(ost->first_pts,
+  ost->enc_ctx->time_base,
+  AV_TIME_BASE_Q));
 /* compute min output value */
 if (av_stream_get_end_pts(ost->st) != AV_NOPTS_VALUE)
 pts = FFMAX(pts, av_rescale_q(av_stream_get_end_pts(ost->st),
@@ -1752,6 +1757,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 nb_frames_drop += ost->last_dropped;
 }
 
+pts -= first_pts;
 secs = FFABS(pts) / AV_TIME_BASE;
 us = FFABS(pts) % AV_TIME_BASE;
 mins = secs / 60;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Aman Gupta]

On Tue, Apr 24, 2018 at 7:08 PM Aman Gupta  wrote:

> From: Aman Gupta 
>
> Based largely on VLC's modules/codec/telx.c.
>
> Processes only teletext pages marked as subtitles, so depending
> on the stream it might not produce any output.
>
> Subtitles are rendered directly to ASS, with support for background
> colors and a best-effort at screen positioning.


This was meant to say foreground (text) colors. Background colors are not
implemented.

The ASS packets
> are emitted in real time (similar to ccaption_dec's real_time
> option), with -1 durations. The decoder expects that the player
> will remove all existing subtitles whenever a new packet arrives.
>
> The teletext clear command is implemented using an empty subtitle,
> which removes existing subtitles but does not render anything new.
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/teletextsubdec.c | 522
> 
>  3 files changed, 524 insertions(+)
>  create mode 100644 libavcodec/teletextsubdec.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 4b8ad121db..83f2eab513 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -593,6 +593,7 @@ OBJS-$(CONFIG_SVQ1_DECODER)+= svq1dec.o
> svq1.o svq13.o h263data.o
>  OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  h263data.o  \
>h263.o ituh263enc.o
>  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o
> h264data.o
> +OBJS-$(CONFIG_TELETEXTSUB_DECODER) += teletextsubdec.o ass.o
>  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
>  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
>  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4d4ef530e4..f0f23eccef 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -634,6 +634,7 @@ extern AVCodec ff_subrip_encoder;
>  extern AVCodec ff_subrip_decoder;
>  extern AVCodec ff_subviewer_decoder;
>  extern AVCodec ff_subviewer1_decoder;
> +extern AVCodec ff_teletextsub_decoder;
>  extern AVCodec ff_text_encoder;
>  extern AVCodec ff_text_decoder;
>  extern AVCodec ff_vplayer_decoder;
> diff --git a/libavcodec/teletextsubdec.c b/libavcodec/teletextsubdec.c
> new file mode 100644
> index 00..f5f0f935ef
> --- /dev/null
> +++ b/libavcodec/teletextsubdec.c
> @@ -0,0 +1,522 @@
> +/*
> + * Minimal Teletext subtitle decoding for ffmpeg
> + * Copyright (c) 2018 Aman Gupta
> + * Copyright (c) 2013 Marton Balint
> + * Copyright (c) 2005-2010, 2012 Wolfram Gloger
> + * Copyright (c) 2007 Vincent Penne, VLC authors and VideoLAN
> (modules/codec/telx.c)
> + * Copyright (c) 2001-2005 dvb.matt, ProjectX java dvb decoder
> + *
> + * This library 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 of the License, or (at your option) any later version.
> + *
> + * This library 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 this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street
> ,
> Fifth Floor, Boston, MA 02110-1301 USA
> + */
> +
> +#include 
> +#include "avcodec.h"
> +#include "libavcodec/ass.h"
> +#include "libavcodec/dvbtxt.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/bprint.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/log.h"
> +#include "libavutil/reverse.h"
> +
> +#define NUM_ROWS 24
> +#define ROW_SIZE 40
> +#define NUM_MAGAZINES 9
> +
> +typedef struct TeletextContext
> +{
> +AVClass *class;
> +int64_t pts;
> +AVBPrint buffer;
> +int readorder;
> +
> +uint8_t rows[NUM_ROWS][ROW_SIZE];
> +bool active[NUM_MAGAZINES];
> +int charset;
> +} TeletextContext;
> +
> +/*
> + * My doc only mentions 13 national characters, but experiments show there
> + * are more, in france for example I already found two more (0x9 and 0xb).
> + *
> + * Conversion is in this order :
> + *
> + * 0x23 0x24 0x40 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x7b 0x7c 0x7d 0x7e
> + * (these are the standard ones)
> + * 0x08 0x09 0x0a 0x0b 0x0c 0x0d (apparently a control character) 0x0e
> 0x0f
> + */
> +static const uint16_t national_charsets[][20] = {
> +{ 0x00a3, 0x0024, 0x0040, 0x00ab, 0x00bd, 0x00bb, 0x005e, 0x0023,
> +  0x002d, 0x00bc, 0x00a6, 0x00be, 0x00f7 }, /* english ,000 */
> +
> +{ 0x00e9, 0x00ef, 0x00e0, 

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Aman Gupta]

On Wed, Apr 25, 2018 at 6:15 PM Marton Balint  wrote:

>
>
> On Thu, 26 Apr 2018, Carl Eugen Hoyos wrote:
>
> > 2018-04-25 4:07 GMT+02:00, Aman Gupta :
> >
> >> Processes only teletext pages marked as subtitles, so
> >> depending on the stream it might not produce any output.
> >
> > Shouldn't there be at least an option to output whatever
> > page was requested?
> >
> > +1 for not needing an external dependency.
>
> Why? Libzvbi is LGPL. We might as well include *that* in the ffmpeg
> codebase...


I was under the impression that libzvbi was GPL2 like the rest of zapping.
If I had known it was LGPL I probably wouldn't have gone down this route.

It might make sense to merge this back into the zvbi based decoder, but
I've never used zvbi so I'm not sure how it compares to the features I've
implemented here. I will try to find some time to investigate, but to be
honest this version is working very well for my needs and I'm not
particularly motivated to add a dependency to my project.

Aman


>
> I thought having a decoder which is inferior in features to an existing
> one or re-inventing yet something again in ffmpeg code are two things we
> are trying to avoid.
>
> Regards,
> Marton
> ___
> 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] ? Inserting an image in the middle of a video stream

[John P Poet]

On Wed, Apr 25, 2018 at 4:25 PM Devin Heitmueller <
dheitmuel...@kernellabs.com> wrote:

> Hi John,
>
> On Wed, Apr 25, 2018 at 5:11 PM, John P Poet  wrote:
> > I am working on a project where I need to insert a repeating image (10
> > seconds) in the middle of a video stream while also transcoding from one
> > video codec to another.  The images are going to be either png or jpg
> > images.  I have a frame number within the video stream which tells me
> where
> > to insert the sequence of image frames.
>
> This feels like a case where you might be better off with a video
> filter that takes two inputs rather than modifying ffmpeg.c.  The
> filter would normally pass through the AVFrames from the first input,
> except when you hit the appropriate timestamp, at which point it would
> switch to the other input for some period.
>
> Look at the overlay filter as an example.
>

Hi Devin,

I would love to see some code which does this.  Google has not been kind.
I find lost of examples of doing it from the command line, but I need to do
this pragmatically since the points I insert the image can be updated in
"real time" while transcoding the video.


>
> Alternatively, the filter could take the image to insert as a filter
> argument, use libavformat/avcodec to decode it once, and then your
> pipeline would be relatively standard.  I believe there are some
> examples that do that (look at the filters page and look for entries
> that take a jpg/png as a filter argument).
>

The image will be know ahead of time, so I like this option.  It would be
much more efficient.

When you say "look at the filters page", What page is that?  I have had a
hard time finding examples of this kind of operation.  When I do find an
example, I usually discover it is for a previous "API" and uses deprecated
functions.

 Thank you,

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

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Aman Gupta]

On Wed, Apr 25, 2018 at 5:30 PM Carl Eugen Hoyos  wrote:

> 2018-04-25 4:07 GMT+02:00, Aman Gupta :
>
> > Processes only teletext pages marked as subtitles, so
> > depending on the stream it might not produce any output.
>
> Shouldn't there be at least an option to output whatever
> page was requested?


The decoder will only parse subtitle pages, and there is no way to select a
page by design. One of the reasons I wrote this is because I wanted
subtitles to just work without having to figure out which page to decode
first.


>
> +1 for not needing an external dependency.
>
> Thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/14] avcodec/vc1: re-implement and expand VC-1 overlap smooting

[James Almer]

On 4/23/2018 3:58 PM, Jerome Borsboom wrote:
> The existing implementation did overlap smoothing for progressive
> frames only. This rewritten version implements overlap smoothing
> for all applicable frame types for both progessive and
> frame/field-interlace.
> 
> Signed-off-by: Jerome Borsboom 
> ---
> This patch-set improves the VC-1 software decoder to the point where the fate
> checksums are equal to checksums from the Intel hardware decoded image on 
> Haswell.

This apparently introduced a few invalid reads and use of uninitialized
values, as found by Valgrind.

http://fate.ffmpeg.org/report.cgi?time=20180426002618=x86_64-archlinux-gcc-valgrind
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Carl Eugen Hoyos]

2018-04-26 3:15 GMT+02:00, Marton Balint :
>
>
> On Thu, 26 Apr 2018, Carl Eugen Hoyos wrote:
>
>> 2018-04-25 4:07 GMT+02:00, Aman Gupta :
>>
>>> Processes only teletext pages marked as subtitles, so
>>> depending on the stream it might not produce any output.
>>
>> Shouldn't there be at least an option to output whatever
>> page was requested?
>>
>> +1 for not needing an external dependency.
>
> Why?

Because that means more features are present and can
be tested within our codebase.
I consider this a sufficient argument even for less
important features.

> Libzvbi is LGPL.

> We might as well include *that* in the ffmpeg codebase...

I have no strong opinion, but iirc, it is significantly larger
than the proposed file.

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

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Marton Balint]

On Thu, 26 Apr 2018, Carl Eugen Hoyos wrote:


2018-04-25 4:07 GMT+02:00, Aman Gupta :


Processes only teletext pages marked as subtitles, so
depending on the stream it might not produce any output.


Shouldn't there be at least an option to output whatever
page was requested?

+1 for not needing an external dependency.


Why? Libzvbi is LGPL. We might as well include *that* in the ffmpeg 
codebase...


I thought having a decoder which is inferior in features to an existing 
one or re-inventing yet something again in ffmpeg code are two things we 
are trying to avoid.


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

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Carl Eugen Hoyos]

2018-04-25 4:07 GMT+02:00, Aman Gupta :

> Processes only teletext pages marked as subtitles, so
> depending on the stream it might not produce any output.

Shouldn't there be at least an option to output whatever
page was requested?

+1 for not needing an external dependency.

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

Re: [FFmpeg-devel] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases

[Michael Niedermayer]

On Wed, Apr 25, 2018 at 08:17:38AM +0200, Łukasz Krzciuk wrote:
> Yes, I have checked it and I implemented it according to OIPF spec: 8.4.2
> AVComponent, audioDescription case (as I wrote in my 1st email). This
> implementation is tested by official org.hbbtv_HTML50420 testcase.

ok, ill apply it then

is it (easily) possibly to add some test for this to fate ?

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 11:33:53PM +0200, Stephan Holljes wrote:
> Hi all,
> 
> I've discussed this on IRC a bit, but I don't want to exclude those
> views that are not present there.
> 
> The consensus seems to be that there are more disadvantages in using
> the http server of libavformat than there are advantages.
> 
> This arose partly out of the discussion that there is no way to get a
> connected peer's address through the public API (as the filedescriptor
> is hidden in private structs).
> 
> The alternatives that were discussed were libmicrohttpd or writing the
> whole project as an nginx module.
> 
> Both have their share of advantages and disadvantages. While I have
> started to read the documentation on both of these, I can't clearly
> point out which is the better choice.
> 
> Most people (including my mentor) spoke out in favor of utilizing nginx.
> 
> I'd like to know what the rest of the developers think is best for the
> project. Any pointers to good alternatives to look at or things to
> think of we are missing are appreciated!
> 
> I am already not sure how to incorporate rtp into an nginx module
> (since it is one of the goals on the roadmap). Maybe someone knows how
> to either work around it or knows a project where that was done?

I think making the code depend on a specific external http implementation
would be a mistake

If we look at other successfull "http related" projects they tend not
to be specific to one http server

For example if we would look at trac (the bug tracker we use) it
supports a range of http servers and also comes with its own native
http server (tracd)


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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Michael Niedermayer]

On Wed, Apr 25, 2018 at 09:32:43PM +0200, Marton Balint wrote:
> 
> 
> On Tue, 24 Apr 2018, Aman Gupta wrote:
> 
> >From: Aman Gupta 
> >
> >Based largely on VLC's modules/codec/telx.c.
> >
> >Processes only teletext pages marked as subtitles, so depending
> >on the stream it might not produce any output.
> >
> >Subtitles are rendered directly to ASS, with support for background
> >colors and a best-effort at screen positioning. The ASS packets
> >are emitted in real time (similar to ccaption_dec's real_time
> >option), with -1 durations. The decoder expects that the player
> >will remove all existing subtitles whenever a new packet arrives.
> >
> >The teletext clear command is implemented using an empty subtitle,
> >which removes existing subtitles but does not render anything new.
> 
> Why don't you add the ASS styling functionality to the existing
> libzvbi-teletextdec.c instead? You're duplicating lot's of code and doing
> teletext parsing which is hard to do properly so using libzvbi for it seems
> a better choice.

I dont know about amans arguments or reasons but
I think avoiding an external dependancy would be an argument not to make
the code depandant on libzvbi

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

[Kieran Kunhya]

On Wed, 25 Apr 2018 at 23:18 Nicolas George  wrote:

> Josh de Kock (2018-04-25):
> > If anything, this should have never been added and a suitable
> > external library should have been picked.
>
> This opinion should have been expressed three years ago. It was decided
> then that lavf deserved a HTTP server. It is done.
>

https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_the_sunk_cost_fallacy

It was objected heavily to at the time and if I recall correctly we agreed
to review its presence later.

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

[FFmpeg-devel] [PATCH 1/2] avcodec/cbs: create reference counted fragments in ff_cbs_read_extradata()

[James Almer]

This way, every CodedBitstreamType->split_fragment() function can
safely assume the fragment passed to them will be reference counted,
potentially simplifying code.

Signed-off-by: James Almer 
---
 libavcodec/cbs.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 897e0bb28e..d81b4e03f7 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -167,27 +167,6 @@ static int cbs_read_fragment_content(CodedBitstreamContext 
*ctx,
 return 0;
 }
 
-int ff_cbs_read_extradata(CodedBitstreamContext *ctx,
-  CodedBitstreamFragment *frag,
-  const AVCodecParameters *par)
-{
-int err;
-
-memset(frag, 0, sizeof(*frag));
-
-frag->data  = par->extradata;
-frag->data_size = par->extradata_size;
-
-err = ctx->codec->split_fragment(ctx, frag, 1);
-if (err < 0)
-return err;
-
-frag->data  = NULL;
-frag->data_size = 0;
-
-return cbs_read_fragment_content(ctx, frag);
-}
-
 static int cbs_fill_fragment_data(CodedBitstreamContext *ctx,
   CodedBitstreamFragment *frag,
   const uint8_t *data, size_t size)
@@ -209,6 +188,26 @@ static int cbs_fill_fragment_data(CodedBitstreamContext 
*ctx,
 return 0;
 }
 
+int ff_cbs_read_extradata(CodedBitstreamContext *ctx,
+  CodedBitstreamFragment *frag,
+  const AVCodecParameters *par)
+{
+int err;
+
+memset(frag, 0, sizeof(*frag));
+
+err = cbs_fill_fragment_data(ctx, frag, par->extradata,
+ par->extradata_size);
+if (err < 0)
+return err;
+
+err = ctx->codec->split_fragment(ctx, frag, 1);
+if (err < 0)
+return err;
+
+return cbs_read_fragment_content(ctx, frag);
+}
+
 int ff_cbs_read_packet(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
const AVPacket *pkt)
-- 
2.17.0

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

[FFmpeg-devel] [PATCH 2/2] avcodec/cbs_mpeg2: use existing buffer reference when splitting fragments

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/cbs_mpeg2.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 94b9591b21..30d2bb6fbf 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -146,16 +146,11 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext 
*ctx,
 unit_size = (end - 4) - (start - 1);
 }
 
-unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!unit_data)
-return AVERROR(ENOMEM);
-memcpy(unit_data, start - 1, unit_size);
-memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+unit_data = (uint8_t *)start - 1;
 
 err = ff_cbs_insert_unit_data(ctx, frag, i, unit_type,
-  unit_data, unit_size, NULL);
+  unit_data, unit_size, frag->data_ref);
 if (err < 0) {
-av_freep(_data);
 return err;
 }
 
-- 
2.17.0

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

Re: [FFmpeg-devel] ? Inserting an image in the middle of a video stream

[Devin Heitmueller]

Hi John,

On Wed, Apr 25, 2018 at 5:11 PM, John P Poet  wrote:
> I am working on a project where I need to insert a repeating image (10
> seconds) in the middle of a video stream while also transcoding from one
> video codec to another.  The images are going to be either png or jpg
> images.  I have a frame number within the video stream which tells me where
> to insert the sequence of image frames.

This feels like a case where you might be better off with a video
filter that takes two inputs rather than modifying ffmpeg.c.  The
filter would normally pass through the AVFrames from the first input,
except when you hit the appropriate timestamp, at which point it would
switch to the other input for some period.

Look at the overlay filter as an example.

Alternatively, the filter could take the image to insert as a filter
argument, use libavformat/avcodec to decode it once, and then your
pipeline would be relatively standard.  I believe there are some
examples that do that (look at the filters page and look for entries
that take a jpg/png as a filter argument).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 23/26] lavc/cbs: Add JPEG support

[James Almer]

On 4/25/2018 6:31 PM, Mark Thompson wrote:
> +static int cbs_jpeg_split_fragment(CodedBitstreamContext *ctx,
> +   CodedBitstreamFragment *frag,
> +   int header)
> +{
> +AVBufferRef *data_ref;
> +uint8_t *data;
> +size_t data_size;
> +int unit, start, end, marker, next_start, next_marker;
> +int err, i, j, length;
> +
> +if (frag->data_size < 4) {
> +// Definitely too short to be meaningful.
> +return AVERROR_INVALIDDATA;
> +}
> +
> +for (i = 0; i + 1 < frag->data_size && frag->data[i] != 0xff; i++);
> +if (i > 0) {
> +av_log(ctx->log_ctx, AV_LOG_WARNING, "Discarding %d bytes at "
> +   "beginning of image.\n", i);
> +}
> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size && frag->data[i]) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
> +   "no SOI marker found.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +marker = frag->data[i];
> +if (marker != JPEG_MARKER_SOI) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: first "
> +   "marker is %02x, should be SOI.\n", marker);
> +return AVERROR_INVALIDDATA;
> +}
> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
> +   "no image content found.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +marker = frag->data[i];
> +start  = i + 1;
> +
> +for (unit = 0;; unit++) {
> +if (marker == JPEG_MARKER_EOI) {
> +break;
> +} else if (marker == JPEG_MARKER_SOS) {
> +for (i = start; i + 1 < frag->data_size; i++) {
> +if (frag->data[i] != 0xff)
> +continue;
> +end = i;
> +for (++i; i + 1 < frag->data_size &&
> +  frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size) {
> +next_marker = -1;
> +} else {
> +if (frag->data[i] == 0x00)
> +continue;
> +next_marker = frag->data[i];
> +next_start  = i + 1;
> +}
> +break;
> +}
> +} else {
> +i = start;
> +if (i + 2 > frag->data_size) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
> +   "truncated at %02x marker.\n", marker);
> +return AVERROR_INVALIDDATA;
> +}
> +length = AV_RB16(frag->data + i);
> +if (i + length > frag->data_size) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
> +   "truncated at %02x marker segment.\n", marker);
> +return AVERROR_INVALIDDATA;
> +}
> +end = start + length;
> +
> +i = end;
> +if (frag->data[i] != 0xff) {
> +next_marker = -1;
> +} else {
> +for (++i; i + 1 < frag->data_size &&
> +  frag->data[i] == 0xff; i++);
> +if (i + 1 >= frag->data_size) {
> +next_marker = -1;
> +} else {
> +next_marker = frag->data[i];
> +next_start  = i + 1;
> +}
> +}
> +}
> +
> +if (marker == JPEG_MARKER_SOS) {
> +length = AV_RB16(frag->data + start);
> +
> +data_ref = av_buffer_alloc(end - start +
> +   AV_INPUT_BUFFER_PADDING_SIZE);

Allocating an AVBufferRef here, letting ff_cbs_insert_unit_data()
generate a new reference to it, then unreffing the first one seems
wasteful/redundant.

Use av_malloc(), set data_ref to NULL, and let ff_cbs_insert_unit_data()
create the AVBufferRef by taking ownership of the malloc'd data array
instead. You'd then only need to free said data array if
ff_cbs_insert_unit_data() fails.

> +if (!data_ref)
> +return AVERROR(ENOMEM);
> +data = data_ref->data;
> +
> +memcpy(data, frag->data + start, length);
> +for (i = start + length, j = length; i < end; i++, j++) {
> +if (frag->data[i] == 0xff) {
> +while (frag->data[i] == 0xff)
> +++i;
> +data[j] = 0xff;
> +} else {
> +data[j] = frag->data[i];
> +}
> +}
> +data_size = j;
> +
> +memset(data + data_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +} else {
> +data  = frag->data + start;
> +data_size = end - start;
> + 

Re: [FFmpeg-devel] [PATCH 10/26] vaapi_encode: Choose profiles dynamically

[Mark Thompson]

On 25/04/18 09:43, Xiang, Haihao wrote:>> Previously there was one fixed choice 
for each codec (e.g. H.265 -> Main
>> profile), and using anything else then required an explicit option from
>> the user.  This changes to selecting the profile based on the input format
>> and the set of profiles actually supported by the driver (e.g. P010 input
>> will choose Main 10 profile for H.265 if the driver supports it).
>>
>> The entrypoint and render target format are also chosen dynamically in the
>> same way, removing those explicit selections from the per-codec code.
>> ---
>>  doc/encoders.texi   |   3 +
>>  libavcodec/vaapi_encode.c   | 261 +++--
>> ---
>>  libavcodec/vaapi_encode.h   |  41 +--
>>  libavcodec/vaapi_encode_h264.c  |  45 ++-
>>  libavcodec/vaapi_encode_h265.c  |  43 +++
>>  libavcodec/vaapi_encode_mjpeg.c |  13 +-
>>  libavcodec/vaapi_encode_mpeg2.c |  36 ++
>>  libavcodec/vaapi_encode_vp8.c   |  11 +-
>>  libavcodec/vaapi_encode_vp9.c   |  34 ++
>>  9 files changed, 306 insertions(+), 181 deletions(-)
>>
>> ...
>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>> index 5529ee5a03..e01bdcf6b4 100644
>> --- a/libavcodec/vaapi_encode_h265.c
>> +++ b/libavcodec/vaapi_encode_h265.c
>> @@ -875,7 +875,25 @@ static av_cold int
>> vaapi_encode_h265_configure(AVCodecContext *avctx)
>>  return 0;
>>  }
>>  
>> +static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] = {
>> +{ FF_PROFILE_HEVC_MAIN, 8, 1, 1, VAProfileHEVCMain   },
>> +#if VA_CHECK_VERSION(0, 37, 0)
>> +{ FF_PROFILE_HEVC_MAIN_10, 10, 1, 1, VAProfileHEVCMain10 },
>> +#endif
>> +#if VA_CHECK_VERSION(1, 2, 0)
>> +{ FF_PROFILE_HEVC_REXT,12, 1, 1, VAProfileHEVCMain12 },
>> +{ FF_PROFILE_HEVC_REXT,10, 1, 0, VAProfileHEVCMain422_10 },
>> +{ FF_PROFILE_HEVC_REXT,12, 1, 0, VAProfileHEVCMain422_12 },
>> +{ FF_PROFILE_HEVC_REXT, 8, 0, 0, VAProfileHEVCMain444},
>> +{ FF_PROFILE_HEVC_REXT,10, 0, 0, VAProfileHEVCMain444_10 },
>> +{ FF_PROFILE_HEVC_REXT,12, 0, 0, VAProfileHEVCMain444_12 },
>> +#endif
> 
> VA API 1.2 is not released yet, currently only structures for decoding are 
> added
> . It would be better to include the above profiles in a separate patch in the
> future. 

That's fair, removed for now.  (They couldn't be chosen anyway, but not having 
them at all is more sensible.)

Thanks,

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

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

[Nicolas George]

Josh de Kock (2018-04-25):
> If anything, this should have never been added and a suitable
> external library should have been picked.

This opinion should have been expressed three years ago. It was decided
then that lavf deserved a HTTP server. It is done.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 01/26] vaapi_encode_h264: Move options and common structures into context

[Mark Thompson]

On 25/04/18 08:02, Xiang, Haihao wrote:>> This will make it easier to support 
options in common between different
>> encoders.  It also cleans up some of the field naming.
>> ---
>>  libavcodec/vaapi_encode_h264.c | 228 
>> +---
>> -
>>  1 file changed, 115 insertions(+), 113 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>> index 56ad217b4a..cc163151a6 100644
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> ...
>> @@ -882,16 +888,15 @@ static const VAAPIEncodeType vaapi_encode_type_h264 = {
>>  
>>  static av_cold int vaapi_encode_h264_init(AVCodecContext *avctx)
>>  {
>> -VAAPIEncodeContext *ctx = avctx->priv_data;
>> -VAAPIEncodeH264Options *opt =
>> -(VAAPIEncodeH264Options*)ctx->codec_options_data;
>> +VAAPIEncodeContext  *ctx = avctx->priv_data;
>> +VAAPIEncodeH264Context *priv = avctx->priv_data;
>>  
> 
> How about to replace *ctx = avctx->priv_data with ctx = >common? (Of
> course priv should be assigned first). The latter is more readable for me.
> Actually I was confused at little bit at first glance because both priv and 
> ctx
> are avtctx->priv_data.

I don't think so?  They are the same pointer with different types, so we load 
them with the same value.  Indirecting one of them through the other makes it 
look like they aren't the same pointer, which feels more confusing to me.

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

Re: [FFmpeg-devel] [PATCH 02/26] vaapi_encode_h265: Move options and common structures into context

[Mark Thompson]

On 25/04/18 08:35, Xiang, Haihao wrote:>> Matching previous commit for H.264.
>> ---
>>  libavcodec/vaapi_encode_h265.c | 114 
>> +++-
>> -
>>  1 file changed, 54 insertions(+), 60 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>> index 5203c6871d..ba6b426eed 100644
>> --- a/libavcodec/vaapi_encode_h265.c
>> +++ b/libavcodec/vaapi_encode_h265.c
>> ...
>> @@ -953,17 +951,14 @@ static av_cold int 
>> vaapi_encode_h265_init(AVCodecContext
>> *avctx)
>>  
>>  static av_cold int vaapi_encode_h265_close(AVCodecContext *avctx)
>>  {
>> -VAAPIEncodeContext *ctx = avctx->priv_data;
>> -VAAPIEncodeH265Context *priv = ctx->priv_data;
>> +VAAPIEncodeH265Context *priv = avctx->priv_data;
>>  
>> -if (priv)
>> -ff_cbs_close(>cbc);
>> +ff_cbs_close(>cbc);
>>  
> 
> I see the NULL check is still used in vaapi_encode_h264_close(), it would be
> better to remove the NULL check in vaapi_encode_h264_close() too if this check
> is unnecessary.

On 25/04/18 08:43, Xiang, Haihao wrote:
>> ---
>>  libavcodec/vaapi_encode_mpeg2.c | 50 --
>> ---
>>  1 file changed, 24 insertions(+), 26 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode_mpeg2.c 
>> b/libavcodec/vaapi_encode_mpeg2.c
>> index 42df77ea49..5dd1f39cbc 100644
>> --- a/libavcodec/vaapi_encode_mpeg2.c
>> +++ b/libavcodec/vaapi_encode_mpeg2.c
>> ...
>> @@ -638,8 +637,7 @@ static av_cold int vaapi_encode_mpeg2_init(AVCodecContext
>> *avctx)
>>  
>>  static av_cold int vaapi_encode_mpeg2_close(AVCodecContext *avctx)
>>  {
>> -VAAPIEncodeContext *ctx = avctx->priv_data;
>> -VAAPIEncodeMPEG2Context *priv = ctx->priv_data;
>> +VAAPIEncodeMPEG2Context *priv = avctx->priv_data;
>>  
>>  if (priv)
> 
> Is this check necessary?

Right; I've removed both of these (leftover from the codec-private part not 
being present if common init hadn't been called), and also the one in MJPEG.

Thanks,

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

Re: [FFmpeg-devel] fate clients

[Michael Niedermayer]

On Wed, Apr 25, 2018 at 05:52:38PM -0300, James Almer wrote:
> On 4/25/2018 1:32 PM, Michael Niedermayer wrote:
> > On Wed, Apr 25, 2018 at 12:07:53AM +0200, Michael Niedermayer wrote:
> >> Hi all
> >>
> >> before anyone notices and asks ...
> >> my box with my virtual fate clients on it died today
> >> my arm clients should still be working though
> >>
> >> Ill try to get it up and working ASAP.
> >>
> >> Symptoms for the curious
> >> attempting to power the box on causes GPU and PSU fan to momentarily spin,
> >> nothing else moves.
> >> then immedeatly powers down. no beeps, ive checked that a speaker is 
> >> connected
> >>
> >> seperating the PSU and shorting the green wire causes 12/5v/3,3/-12 to be
> >> there continously and gray to go high for a fraction of a second.
> >> I assume the gray (power check) should stay high, so if thats the case 
> >> thats a PSU failure
> >> so ill buy a new PSU tomorrow probably
> > 
> > should all be alive again.
> > If you spot something that broke then tell me.
> > at least 2 clients had corrupted git checkouts
> > 
> > thx
> 
> http://fate.ffmpeg.org/history.cgi?slot=alpha-debian-qemu-gcc-4.7
> 
> This one seems to have sent an incomplete report, as seen at the end of
> the test log from the latest run:
> http://fate.ffmpeg.org/log.cgi?time=20180425175140=alpha-debian-qemu-gcc-4.7=test
> 
> Previous runs were fine.

"No space left on device"
ive freed some space up

but ultimatly all the clients are a bit space constrained as they needed to fit
on the 512gb SSD together with everything else on that box

[...]
-- 
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 11/26] vaapi_encode: Add common options between all encoders

[Mark Thompson]

On 25/04/18 02:21, Zhao Jun wrote:
> 2018-04-22 23:29 GMT+08:00 Mark Thompson :
>> The only common option here is low_power - it was previously supported
>> for H.264 only, that specific option is removed.
>> ---
>>  doc/encoders.texi  | 14 --
>>  libavcodec/vaapi_encode.h  |  9 +
>>  libavcodec/vaapi_encode_h264.c |  8 ++--
>>  libavcodec/vaapi_encode_h265.c |  2 ++
>>  libavcodec/vaapi_encode_vp8.c  |  1 +
>>  libavcodec/vaapi_encode_vp9.c  |  1 +
>>  6 files changed, 27 insertions(+), 8 deletions(-)
>>
>> diff --git a/doc/encoders.texi b/doc/encoders.texi
>> index 16be6359b3..62a1509a96 100644
>> --- a/doc/encoders.texi
>> +++ b/doc/encoders.texi
>> @@ -2599,6 +2599,18 @@ Size / quality tradeoff: higher values are smaller / 
>> worse quality.
>>  @option{b_qoffset} / @option{b_quant_offset}
>>  @end itemize
>>
>> +All encoders support the following options:
>> +@itemize
>> +@item
>> +@option{low_power}
>> +
>> +Some drivers/platforms offer a second encoder for some codecs intended to 
>> use
>> +less power than the default encoder; setting this option will attempt to use
>> +that encoder.  Note that it may support a reduced feature set, so some other
>> +options may not be available in this mode.
>> +@end itemize
>> +
>> +Each encoder also has its own specific options:
>>  @table @option
>>
>>  @item h264_vaapi
>> @@ -2606,8 +2618,6 @@ Size / quality tradeoff: higher values are smaller / 
>> worse quality.
>>  @option{level} sets the value of @emph{level_idc}.
>>
>>  @table @option
>> -@item low_power
>> -Use low-power encoding mode.
>>  @item coder
>>  Set entropy encoder (default is @emph{cabac}).  Possible values:
>>
>> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
>> index 2b909d4d6b..9e0826b30e 100644
>> --- a/libavcodec/vaapi_encode.h
>> +++ b/libavcodec/vaapi_encode.h
>> @@ -300,4 +300,13 @@ int ff_vaapi_encode2(AVCodecContext *avctx, AVPacket 
>> *pkt,
>>  int ff_vaapi_encode_init(AVCodecContext *avctx);
>>  int ff_vaapi_encode_close(AVCodecContext *avctx);
>>
>> +
>> +#define VAAPI_ENCODE_COMMON_OPTIONS \
>> +{ "low_power", \
>> +  "Use low-power encoding mode (only available on some platforms; " \
>> +  "may not support all encoding features)", \
>> +  OFFSET(common.low_power), AV_OPT_TYPE_BOOL, \
>> +  { .i64 = 0 }, 0, 1, FLAGS }
>> +
>> +
>>  #endif /* AVCODEC_VAAPI_ENCODE_H */
>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>> index 93dc51eb40..49dc5229b5 100644
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> @@ -52,7 +52,6 @@ typedef struct VAAPIEncodeH264Context {
>>  // User options.
>>  int qp;
>>  int quality;
>> -int low_power;
> 
> The patchset other part is Ok for me, but I don't think putting
> low_power as common
> option is good idea, as I know, low_power mode only supported by few
> codec, maybe
> only support by AVC/HEVC/VP9 encoder.

That is just what is supported on the i965 driver on Cannonlake at the moment, 
right?  There isn't anything stopping it being supported for other codecs in 
any driver, and since we query the entrypoints at runtime the behaviour if it 
isn't there is just the same as if run on the i965 driver with an Intel chip 
not supporting VDENC for H.264.

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

Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/bitpacked: move ff_get_buffer

[Rostislav Pehlivanov]

On 25 April 2018 at 22:22, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:

> From: Damien Riegel 
>
> ff_get_buffer is used to allocate a buffer to hold frame's content. This
> function was called in the function in charge of decoding an AVPacket
> containing raw video with the yuv422 pixel format and a depth of 10-bit.
>
> RFC4175 supports both progressive and interlaced mode. But the
> interlaced mode doesn't consist of interlaced frames, only of fields.
> FFmpeg cannot handle fields on their own, so the codec has to recreate
> interlaced frames based on two consecutive fields.
>
> As the function `bitpacked_decode_yuv422p10` will need to be called
> twice to do that, it cannot be in charge of the buffer allocation, so
> move it into its caller.
>
> Signed-off-by: Damien Riegel 
> ---
>  libavcodec/bitpacked.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> index f0b417d..85d4bdd 100644
> --- a/libavcodec/bitpacked.c
> +++ b/libavcodec/bitpacked.c
> @@ -64,9 +64,6 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
>  uint16_t *y, *u, *v;
>  int ret, i, j;
>
> -ret = ff_get_buffer(avctx, frame, 0);
> -if (ret < 0)
> -return ret;
>
>  if (frame_size > packet_size)
>  return AVERROR_INVALIDDATA;
> @@ -128,6 +125,12 @@ static int bitpacked_decode(AVCodecContext *avctx,
> void *data, int *got_frame,
>  frame->pict_type = AV_PICTURE_TYPE_I;
>  frame->key_frame = 1;
>
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
> +res = ff_get_buffer(avctx, frame, 0);
> +if (res < 0)
> +return res;
> +}
> +
>  res = bc->decode(avctx, frame, avpkt);
>  if (res)
>  return res;
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Check out my response to your other patch, you should drop this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 2/3] avcodec/bitpacked: add interlace support

[Rostislav Pehlivanov]

On 25 April 2018 at 22:22, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:

> From: Damien Riegel 
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or only a field of the frame.
>
> There is no mechanism for interlaced frames reconstruction at the rtp
> demux level, so it has to be handled by the codec which needs to
> partially recompose an AVFrame with every incoming field AVPacket.
> A frame is ouput only when the frame is completed with the 2nd field
> (bottom).
>
> The additionnal field flags in AVPacket allow the decoder to dynamically
> determine the frame format, i.e. progressive or interlaced.
>
> Signed-off-by: Patrick Keroulas 
> Signed-off-by: Damien Riegel 
> ---
>
> Change v3 -> v4: cleanup
> ---
>  libavcodec/avcodec.h   |   8 
>  libavcodec/bitpacked.c | 113 ++
> +--
>  2 files changed, 107 insertions(+), 14 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fa..14811be 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1480,6 +1480,14 @@ typedef struct AVPacket {
>   */
>  #define AV_PKT_FLAG_DISPOSABLE 0x0010
>
> +/**
> + * The packet contains a top field.
> + */
> +#define AV_PKT_FLAG_TOP_FIELD  0x0020
> +/**
> + * The packet contains a bottom field.
> + */
> +#define AV_PKT_FLAG_BOTTOM_FIELD  0x0040
>
>  enum AVSideDataParamChangeFlags {
>  AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
> diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> index 85d4bdd..380d784 100644
> --- a/libavcodec/bitpacked.c
> +++ b/libavcodec/bitpacked.c
> @@ -32,8 +32,9 @@
>  #include "libavutil/imgutils.h"
>
>  struct BitpackedContext {
> -int (*decode)(AVCodecContext *avctx, AVFrame *frame,
> -  AVPacket *pkt);
> +int (*decode)(AVCodecContext *avctx, AVFrame *frame, AVPacket *pkt);
> +AVFrame *cur_interlaced_frame;
> +int prev_top_field;
>  };
>
>  /* For this format, it's a simple passthrough */
> @@ -60,22 +61,39 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
>  {
>  uint64_t frame_size = (uint64_t)avctx->width *
> (uint64_t)avctx->height * 20;
>  uint64_t packet_size = (uint64_t)avpkt->size * 8;
> +int interlaced = frame->interlaced_frame;
> +int top_field = (avpkt->flags & AV_PKT_FLAG_TOP_FIELD) ? 1 : 0;
>  GetBitContext bc;
>  uint16_t *y, *u, *v;
>  int ret, i, j;
>
> -
> -if (frame_size > packet_size)
> +/* check packet size depending on the interlaced/progressive format */
> +if (interlaced) {
> +if ((frame_size / 2) > packet_size)
> +return AVERROR_INVALIDDATA;
> +} else if (frame_size > packet_size) {
>  return AVERROR_INVALIDDATA;
> +}
>
>  if (avctx->width % 2)
>  return AVERROR_PATCHWELCOME;
>
> +/*
> + * if the frame is interlaced, the avpkt we are getting is either the
> top
> + * or the bottom field. If it's the bottom field, it contains all the
> odd
> + * lines of the recomposed frame, so we start at offset 1.
> + */
> +i = (interlaced && !top_field) ? 1 : 0;
> +
>  ret = init_get_bits(, avpkt->data, avctx->width * avctx->height *
> 20);
>  if (ret)
>  return ret;
>
> -for (i = 0; i < avctx->height; i++) {
> +/*
> + * Packets from interlaced frames contain either even lines, or odd
> + * lines, so increment by two in that case.
> + */
> +for (; i < avctx->height; i += 1 + interlaced) {
>  y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
>  u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
>  v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
> @@ -100,17 +118,35 @@ static av_cold int bitpacked_init_decoder(AVCodecContext
> *avctx)
>
>  if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
>  if (avctx->bits_per_coded_sample == 16 &&
> -avctx->pix_fmt == AV_PIX_FMT_UYVY422)
> +avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
> +
> +if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
> +av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported
> for 8-bit\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +
>  bc->decode = bitpacked_decode_uyvy422;
> -else if (avctx->bits_per_coded_sample == 20 &&
> - avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
> +} else if (avctx->bits_per_coded_sample == 20 &&
> + avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
>  bc->decode = bitpacked_decode_yuv422p10;
> -else
> +} else {
>  return AVERROR_INVALIDDATA;
> +  

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Mark Thompson]

On 24/04/18 11:51, Alexander Kravchenko wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
>> Mark Thompson
>> Sent: Sunday, April 22, 2018 6:49 PM
>> To: FFmpeg development discussions and patches 
>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support 
>> implementation by AMF encoder
>>
>> On 19/04/18 03:18, Song, Ruiling wrote:
 Note that OpenCL <-> D3D11 won't work on AMD for normal video
 surfaces
 (NV12) because there is no support for multiple-plane textures, so
 it's only going to work with DXVA2 currently.  Intel has an extension
 ("cl_intel_d3d11_nv12_media_sharing") which adds a simple hack
 overloading the subresource index and therefore it is usable on Intel
 GPUs, but other vendors don't have that.
>>>
>>> For OpenCL NV12 support, I think we can use two separate images as
>>> arguments, one image for Y plane, and another image for UV plane.
>>> I think AMD OpenCL should support (CL_RG + CL_UNORM_INT8), right?
>>> So, we can get same behavior across different OpenCL vendors.
>>
>> This is exactly what it does already, in a standard way with both DXVA2 and 
>> VAAPI - NV12 as R/UNORM_INT8 + RG/UNORM_INT8 is
>> indeed usable for AMD on Windows with DXVA2 interop and via direct upload.
>>
>> The problematic case is D3D11, because the standard cl_khr_d3d11_sharing 
>> extension does not support multiple-plane formats.  I
>> would prefer that AMD has an OpenCL-only extension to do it like Intel does, 
>> but an alternative route using AMF to do the mapping
>> isn't horrible (though it would be quite confusing if it isn't transparent 
>> to the user).
> 
> The AMD OpenCL only extension is requested to be published. Hopefully it is 
> coming soon.

Ah, good!  Will it be the same as the Intel one?  It would be nice if it were 
defined for any multiplanar format rather than just NV12 (at the moment getting 
P010 or anything else is only possible in the implementations which share via 
DRM, currently Beignet and Mali).

> Now it is possible to convert DX11-NV12 surface to OpenCL-NV12 using AMF 
> (AMFSurface->Convert(AMF_MEMORY_OPENCL)).
> The private helper function can be implemented as temporary workaround. It 
> can be deprecated when opencl-only extension is published by AMD

If the extension is arriving any time soon then I think it would be better to 
wait so that we can just use hwmap like all other cases do.  A via-AMF route is 
going to be somewhat more inconvenient to combine the required components, and 
also deprecating public API soon after it is added is not very nice.

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

Re: [FFmpeg-devel] [PATCH] avcodec/cbs_mpeg2: use existing buffer reference if available when splitting fragments

[Mark Thompson]

On 24/04/18 23:22, James Almer wrote:
> On 4/23/2018 11:17 PM, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/cbs_mpeg2.c | 15 +--
>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>> index bfb64a0851..086d08ed64 100644
>> --- a/libavcodec/cbs_mpeg2.c
>> +++ b/libavcodec/cbs_mpeg2.c
>> @@ -146,14 +146,17 @@ static int 
>> cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx,
>>  unit_size = (end - 4) - (start - 1);
>>  }
>>  
>> -unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
>> -if (!unit_data)
>> -return AVERROR(ENOMEM);
>> -memcpy(unit_data, start - 1, unit_size);
>> -memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>> +if (header) {
>> +unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
>> +if (!unit_data)
>> +return AVERROR(ENOMEM);
>> +memcpy(unit_data, start - 1, unit_size);
>> +memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>> +} else
>> +unit_data = (uint8_t *)start - 1;
>>  
>>  err = ff_cbs_insert_unit_data(ctx, frag, i, unit_type,
>> -  unit_data, unit_size, NULL);
>> +  unit_data, unit_size, frag->data_ref);
>>  if (err < 0) {
>>  av_freep(_data);
>>  return err;
> 
> The alternative is to make ff_cbs_read_extradata() create an AVBufferRef
> with the contents of par->extradata, so every
> CodedBitstreamType->split_fragment() function can safely assume the
> fragment will always be reference counted.
> 
> I think that would be cleaner overall.

I agree, it would be much cleaner if we can assume that the input fragment is 
always refcounted.  (The AV1 code here assumes it already too, though we didn't 
have extradata for it at the time.)

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

[FFmpeg-devel] [PATCH 23/26] lavc/cbs: Add JPEG support

[Mark Thompson]

---
On 24/04/18 03:16, James Almer wrote:
> On 4/22/2018 12:29 PM, Mark Thompson wrote:
>> +static int cbs_jpeg_split_fragment(CodedBitstreamContext *ctx,
>> +   CodedBitstreamFragment *frag,
>> +   int header)
>> +{
>> +uint8_t *unit_data;
>> +size_t unit_size;
>> +int unit, start, end, marker, next_start, next_marker;
>> +int err, i, j;
>> +
>> +if (frag->data_size < 4) {
>> +// Definitely too short to be meaningful.
>> +return AVERROR_INVALIDDATA;
>> +}
>> +
>> +for (i = 0; i + 1 < frag->data_size && frag->data[i] != 0xff; i++);
>> +if (i > 0) {
>> +av_log(ctx->log_ctx, AV_LOG_WARNING, "Discarding %d bytes at "
>> +   "beginning of image.\n", i);
>> +}
>> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size && frag->data[i]) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
>> +   "no SOI marker found.\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +marker = frag->data[i];
>> +if (marker != JPEG_MARKER_SOI) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: first "
>> +   "marker is %02x, should be SOI.\n", marker);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +for (++i; i + 1 < frag->data_size && frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size) {
>> +av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid JPEG image: "
>> +   "no image content found.\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>> +marker = frag->data[i];
>> +start  = i + 1;
>> +
>> +for (unit = 0;; unit++) {
>> +if (marker == JPEG_MARKER_EOI) {
>> +break;
>> +} else if (marker == JPEG_MARKER_SOS) {
>> +for (i = start; i + 1 < frag->data_size; i++) {
>> +if (frag->data[i] != 0xff)
>> +continue;
>> +end = i;
>> +for (++i; i + 1 < frag->data_size &&
>> +  frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size) {
>> +next_marker = -1;
>> +} else {
>> +if (frag->data[i] == 0x00)
>> +continue;
>> +next_marker = frag->data[i];
>> +next_start  = i + 1;
>> +}
>> +break;
>> +}
>> +} else {
>> +int length;
>> +i = start;
>> +if (i + 2 > frag->data_size)
>> +break;
>> +length = frag->data[i] << 8 | frag->data[i + 1];
>> +av_log(ctx->log_ctx, AV_LOG_DEBUG, "Length = %d (i = %d)\n", 
>> length, i);
>> +if (i + length > frag->data_size)
>> +break;
>> +end = start + length;
>> +
>> +i = end;
>> +if (frag->data[i] != 0xff) {
>> +next_marker = -1;
>> +} else {
>> +for (++i; i + 1 < frag->data_size &&
>> +  frag->data[i] == 0xff; i++);
>> +if (i + 1 >= frag->data_size) {
>> +next_marker = -1;
>> +} else {
>> +next_marker = frag->data[i];
>> +next_start  = i + 1;
>> +}
>> +}
>> +}
>> +
>> +av_log(ctx->log_ctx, AV_LOG_DEBUG, "start = %d, end = %d, marker = 
>> %02x\n",
>> +   start, end, marker);
>> +
>> +unit_size = end - start;
>> +unit_data = av_malloc(unit_size + AV_INPUT_BUFFER_PADDING_SIZE);
>> +if (!unit_data)
>> +return AVERROR(ENOMEM);
>> +if (marker == JPEG_MARKER_SOS) {
>> +for (i = start, j = 0; i < end; i++, j++) {
>> +if (frag->data[i] == 0xff) {
>> +while (frag->data[i] == 0xff)
>> +++i;
>> +unit_data[j] = 0xff;
>> +} else {
>> +unit_data[j] = frag->data[i];
>> +}
>> +}
>> +unit_size = j;
>> +} else {
>> +memcpy(unit_data, frag->data + start, unit_size);
> 
> Create a new frag->data_ref reference instead in this case. There's no
> need to allocate a new buffer for these units.

Yeah, changed.  I rearranged this bit to fix the incorrect marker removal in 
the scan header as well.

>> +}
>> +memset(unit_data + unit_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>> +
>> +err = ff_cbs_insert_unit_data(ctx, frag, unit, marker,
>> +  unit_data, unit_size, NULL);
>> +if (err < 0) {
>> +av_free(_data);
>> +return err;
>> +}
>> +
>> +if (next_marker == -1)
>> +break;
>> +marker = next_marker;
>> +

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

[Josh de Kock]

On 2018/04/24 22:46, Nicolas George wrote:

Stephan Holljes (2018-04-24):

The consensus seems to be that there are more disadvantages in using
the http server of libavformat than there are advantages.


I completely disagree. There is no point in having the HTTP server in
libavformat if it cannot be used to implement exactly that kind of
thing. Implementing ffserver with it is just the test bed that it
requires to become mature.

The HTTP server in libavformat was accepted three years ago, and you
worked hard for it. Do not let people tell you it was for nothing. They
had their chance to discuss this three years ago.



I do not think that using code for that sake of using it is a good way 
to look at it. If anything, this should have never been added and a 
suitable external library should have been picked. Though, I will reply 
to the larger issue at hand later today.



This arose partly out of the discussion that there is no way to get a
connected peer's address through the public API (as the filedescriptor
is hidden in private structs).


Well, then, let us add the functions that are needed in the public API.
It does not seem that difficult to design.


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

[FFmpeg-devel] [PATCH v4 3/3] avformat/rtpdec_rfc4175: handle interlace format

[Patrick Keroulas]

From: Damien Riegel 

In order to handle the interlaced formats, the demuxer has only a few
things to do:
 - parse the SDP correctly and propagate the information
 - check the field bit in the RFC4175 header, and pass that information
   to the decoder

In interlaced mode, received data only consist of fields, and their
heights are half of the frame size, so some adjustments must be done
here and there to take that into account.

Signed-off-by: Damien Riegel 
Signed-off-by: Patrick Keroulas 
---
 libavformat/rtpdec_rfc4175.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
index e9c62c1..9dc7b29 100644
--- a/libavformat/rtpdec_rfc4175.c
+++ b/libavformat/rtpdec_rfc4175.c
@@ -31,6 +31,8 @@ struct PayloadContext {
 int depth;
 int width;
 int height;
+int interlaced;
+int field;
 
 uint8_t *frame;
 unsigned int frame_size;
@@ -65,10 +67,18 @@ static int rfc4175_parse_format(AVStream *stream, 
PayloadContext *data)
 return AVERROR_INVALIDDATA;
 }
 
+if (data->interlaced)
+stream->codecpar->field_order = AV_FIELD_TT;
+else
+stream->codecpar->field_order = AV_FIELD_PROGRESSIVE;
+
 stream->codecpar->format = pixfmt;
 stream->codecpar->codec_tag = tag;
 stream->codecpar->bits_per_coded_sample = bits_per_sample;
-data->frame_size = data->width * data->height * data->pgroup / data->xinc;
+if (data->interlaced)
+data->frame_size = data->width * (data->height / 2) * data->pgroup / 
data->xinc;
+else
+data->frame_size = data->width * data->height * data->pgroup / 
data->xinc;
 
 return 0;
 }
@@ -85,6 +95,8 @@ static int rfc4175_parse_fmtp(AVFormatContext *s, AVStream 
*stream,
 data->sampling = av_strdup(value);
 else if (!strncmp(attr, "depth", 5))
 data->depth = atoi(value);
+else if (!strncmp(attr, "interlace", 9))
+data->interlaced = 1;
 
 return 0;
 }
@@ -131,7 +143,13 @@ static int rfc4175_finalize_packet(PayloadContext *data, 
AVPacket *pkt,
av_freep(>frame);
}
 
+   /* In the packet header, the field is set to 0 for top field
+* and 1 for bottom */
+if (data->interlaced)
+pkt->flags |= data->field ? AV_PKT_FLAG_BOTTOM_FIELD : 
AV_PKT_FLAG_TOP_FIELD;
+
data->frame = NULL;
+   data->field = 0;
 
return ret;
 }
@@ -141,7 +159,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
  const uint8_t * buf, int len,
  uint16_t seq, int flags)
 {
-int length, line, offset, cont;
+int length, line, offset, cont, field;
 const uint8_t *headers = buf + 2; /* skip extended seqnum */
 const uint8_t *payload = buf + 2;
 int payload_len = len - 2;
@@ -194,11 +212,14 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, 
PayloadContext *data,
 return AVERROR_INVALIDDATA;
 
 length = (headers[0] << 8) | headers[1];
+field = (headers[2] & 0x80);
 line = ((headers[2] & 0x7f) << 8) | headers[3];
 offset = ((headers[4] & 0x7f) << 8) | headers[5];
 cont = headers[4] & 0x80;
 headers += 6;
 
+data->field = field;
+
 if (length % data->pgroup)
 return AVERROR_INVALIDDATA;
 
-- 
2.7.4

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

[FFmpeg-devel] [PATCH v4 2/3] avcodec/bitpacked: add interlace support

[Patrick Keroulas]

From: Damien Riegel 

This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.

There is no mechanism for interlaced frames reconstruction at the rtp
demux level, so it has to be handled by the codec which needs to
partially recompose an AVFrame with every incoming field AVPacket.
A frame is ouput only when the frame is completed with the 2nd field
(bottom).

The additionnal field flags in AVPacket allow the decoder to dynamically
determine the frame format, i.e. progressive or interlaced.

Signed-off-by: Patrick Keroulas 
Signed-off-by: Damien Riegel 
---

Change v3 -> v4: cleanup
---
 libavcodec/avcodec.h   |   8 
 libavcodec/bitpacked.c | 113 +++--
 2 files changed, 107 insertions(+), 14 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index fb0c6fa..14811be 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1480,6 +1480,14 @@ typedef struct AVPacket {
  */
 #define AV_PKT_FLAG_DISPOSABLE 0x0010
 
+/**
+ * The packet contains a top field.
+ */
+#define AV_PKT_FLAG_TOP_FIELD  0x0020
+/**
+ * The packet contains a bottom field.
+ */
+#define AV_PKT_FLAG_BOTTOM_FIELD  0x0040
 
 enum AVSideDataParamChangeFlags {
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index 85d4bdd..380d784 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -32,8 +32,9 @@
 #include "libavutil/imgutils.h"
 
 struct BitpackedContext {
-int (*decode)(AVCodecContext *avctx, AVFrame *frame,
-  AVPacket *pkt);
+int (*decode)(AVCodecContext *avctx, AVFrame *frame, AVPacket *pkt);
+AVFrame *cur_interlaced_frame;
+int prev_top_field;
 };
 
 /* For this format, it's a simple passthrough */
@@ -60,22 +61,39 @@ static int bitpacked_decode_yuv422p10(AVCodecContext 
*avctx, AVFrame *frame,
 {
 uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
20;
 uint64_t packet_size = (uint64_t)avpkt->size * 8;
+int interlaced = frame->interlaced_frame;
+int top_field = (avpkt->flags & AV_PKT_FLAG_TOP_FIELD) ? 1 : 0;
 GetBitContext bc;
 uint16_t *y, *u, *v;
 int ret, i, j;
 
-
-if (frame_size > packet_size)
+/* check packet size depending on the interlaced/progressive format */
+if (interlaced) {
+if ((frame_size / 2) > packet_size)
+return AVERROR_INVALIDDATA;
+} else if (frame_size > packet_size) {
 return AVERROR_INVALIDDATA;
+}
 
 if (avctx->width % 2)
 return AVERROR_PATCHWELCOME;
 
+/*
+ * if the frame is interlaced, the avpkt we are getting is either the top
+ * or the bottom field. If it's the bottom field, it contains all the odd
+ * lines of the recomposed frame, so we start at offset 1.
+ */
+i = (interlaced && !top_field) ? 1 : 0;
+
 ret = init_get_bits(, avpkt->data, avctx->width * avctx->height * 20);
 if (ret)
 return ret;
 
-for (i = 0; i < avctx->height; i++) {
+/*
+ * Packets from interlaced frames contain either even lines, or odd
+ * lines, so increment by two in that case.
+ */
+for (; i < avctx->height; i += 1 + interlaced) {
 y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
 u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
 v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
@@ -100,17 +118,35 @@ static av_cold int bitpacked_init_decoder(AVCodecContext 
*avctx)
 
 if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
 if (avctx->bits_per_coded_sample == 16 &&
-avctx->pix_fmt == AV_PIX_FMT_UYVY422)
+avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
+
+if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
+av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported for 
8-bit\n");
+return AVERROR_PATCHWELCOME;
+}
+
 bc->decode = bitpacked_decode_uyvy422;
-else if (avctx->bits_per_coded_sample == 20 &&
- avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
+} else if (avctx->bits_per_coded_sample == 20 &&
+ avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
 bc->decode = bitpacked_decode_yuv422p10;
-else
+} else {
 return AVERROR_INVALIDDATA;
+}
 } else {
 return AVERROR_INVALIDDATA;
 }
 
+bc->cur_interlaced_frame = av_frame_alloc();
+
+return 0;
+}
+
+static av_cold int bitpacked_end_decoder(AVCodecContext *avctx)
+{
+struct BitpackedContext *bc = avctx->priv_data;
+
+av_frame_free(>cur_interlaced_frame);
+
 return 0;
 }
 
@@ 

[FFmpeg-devel] [PATCH v4 1/3] avcodec/bitpacked: move ff_get_buffer

[Patrick Keroulas]

From: Damien Riegel 

ff_get_buffer is used to allocate a buffer to hold frame's content. This
function was called in the function in charge of decoding an AVPacket
containing raw video with the yuv422 pixel format and a depth of 10-bit.

RFC4175 supports both progressive and interlaced mode. But the
interlaced mode doesn't consist of interlaced frames, only of fields.
FFmpeg cannot handle fields on their own, so the codec has to recreate
interlaced frames based on two consecutive fields.

As the function `bitpacked_decode_yuv422p10` will need to be called
twice to do that, it cannot be in charge of the buffer allocation, so
move it into its caller.

Signed-off-by: Damien Riegel 
---
 libavcodec/bitpacked.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
index f0b417d..85d4bdd 100644
--- a/libavcodec/bitpacked.c
+++ b/libavcodec/bitpacked.c
@@ -64,9 +64,6 @@ static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, 
AVFrame *frame,
 uint16_t *y, *u, *v;
 int ret, i, j;
 
-ret = ff_get_buffer(avctx, frame, 0);
-if (ret < 0)
-return ret;
 
 if (frame_size > packet_size)
 return AVERROR_INVALIDDATA;
@@ -128,6 +125,12 @@ static int bitpacked_decode(AVCodecContext *avctx, void 
*data, int *got_frame,
 frame->pict_type = AV_PICTURE_TYPE_I;
 frame->key_frame = 1;
 
+if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
+res = ff_get_buffer(avctx, frame, 0);
+if (res < 0)
+return res;
+}
+
 res = bc->decode(avctx, frame, avpkt);
 if (res)
 return res;
-- 
2.7.4

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

[FFmpeg-devel] ? Inserting an image in the middle of a video stream

[John P Poet]

Hi all,

I am working on a project where I need to insert a repeating image (10
seconds) in the middle of a video stream while also transcoding from one
video codec to another.  The images are going to be either png or jpg
images.  I have a frame number within the video stream which tells me where
to insert the sequence of image frames.

1) I have been looking over ffmpeg.c trying to figure out the best place to
perform this bit of "magic".  It looks to me like I would need to modify

static int transcode_step(void)

such that if I determine I am at the insertion frame number, that I call a
new function to insert the image, instead of calling process_input(int
file_index).  Something like:

if (ost->st->nb_frames == image_insert_frame_number) {
ret = process_image_input()
else
ret = process_input(ist->file_index);

Does that seem reasonable?  If so, then I have to figure out how make my
"image frames" play nice with the rest of the transcode process.

2) I assume I would need to flush the input video stream at the point I
wish to insert the images.  Then start reading from the video stream again
when the images have been processed.

3) process_input() and process_input_packet() seem to do a lot of work to
get the PTS and DTS correct.  Since I am just processing images, can
someone tell me the easiest way to handle that?  Is there anything special
I will have to do, there, when I resume transcoding the video source to
allow for the time my image frames have taken?

4) Is

static int decode_video(InputStream *ist, AVPacket *pkt, int *got_output,
int64_t *duration_pts, int eof, int *decode_failed)

generic enough, that I can directly use it to process the packets I am
reading from the image file?  The examples I have found for reading and
parsing image files, do not bother with creating an InputStream.  If I
wanted to use decode_video() I would have to deal with that.  It would be
nice if I could just call

static void add_input_streams(OptionsContext *o, AVFormatContext *ic)

with my context for my image file, but I am guessing that I don't really
want it added to the "global list of input streams".

5) If decode_video() is not appropriate for me to call with my "image"
packets, then should I call ifilter_send_frame() directly?  I have to
admit, I currently have no idea how to setup a "filter" for the images.

I am hoping someone can either point me to an example of doing this type of
operation, or can offer me some guidance.  I have been doing a lot of
"googling" but it is hard to identify which "API" the examples I have
finding, where written against.  I am using ffmpeg master for this project.

TIA,

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

Re: [FFmpeg-devel] fate clients

[James Almer]

On 4/25/2018 1:32 PM, Michael Niedermayer wrote:
> On Wed, Apr 25, 2018 at 12:07:53AM +0200, Michael Niedermayer wrote:
>> Hi all
>>
>> before anyone notices and asks ...
>> my box with my virtual fate clients on it died today
>> my arm clients should still be working though
>>
>> Ill try to get it up and working ASAP.
>>
>> Symptoms for the curious
>> attempting to power the box on causes GPU and PSU fan to momentarily spin,
>> nothing else moves.
>> then immedeatly powers down. no beeps, ive checked that a speaker is 
>> connected
>>
>> seperating the PSU and shorting the green wire causes 12/5v/3,3/-12 to be
>> there continously and gray to go high for a fraction of a second.
>> I assume the gray (power check) should stay high, so if thats the case 
>> thats a PSU failure
>> so ill buy a new PSU tomorrow probably
> 
> should all be alive again.
> If you spot something that broke then tell me.
> at least 2 clients had corrupted git checkouts
> 
> thx

http://fate.ffmpeg.org/history.cgi?slot=alpha-debian-qemu-gcc-4.7

This one seems to have sent an incomplete report, as seen at the end of
the test log from the latest run:
http://fate.ffmpeg.org/log.cgi?time=20180425175140=alpha-debian-qemu-gcc-4.7=test

Previous runs were fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/h2645_parse: Replace RNXYA by RNXY in ff_h2645_extract_rbsp()

[Michael Niedermayer]

On Sat, Mar 10, 2018 at 09:51:09PM +0100, Michael Niedermayer wrote:
> Fixes misaligned accesses
> Found-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h2645_parse.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

will apply

[...]
-- 
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] [PATCH 1/2] avcodec/h263dec: Check slice_ret in mspeg4 slice loop

[Michael Niedermayer]

On Sun, Apr 22, 2018 at 10:20:31PM +0200, Michael Niedermayer wrote:
> Fixes infinite loop
> Fixes: 
> 6858/clusterfuzz-testcase-ffmpeg_AV_CODEC_ID_MSMPEG4V3_fuzzer-4681563766784000
> Fixes: 
> 6890/clusterfuzz-testcase-ffmpeg_AV_CODEC_ID_WMV1_fuzzer-4756103142309888
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h263dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply the patchset

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH] avcodec/elsdec: Fix memleaks

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 10:12:30PM -0300, James Almer wrote:
> On 4/24/2018 9:58 PM, Michael Niedermayer wrote:
> > Fixes: 
> > 6798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5135899701542912
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/elsdec.c | 10 ++
> >  libavcodec/g2meet.c |  1 +
> >  2 files changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavcodec/elsdec.c b/libavcodec/elsdec.c
> > index 4797965457..8327662b4b 100644
> > --- a/libavcodec/elsdec.c
> > +++ b/libavcodec/elsdec.c
> > @@ -271,7 +271,7 @@ void ff_els_decoder_init(ElsDecCtx *ctx, const uint8_t 
> > *in, size_t data_size)
> >  
> >  void ff_els_decoder_uninit(ElsUnsignedRung *rung)
> >  {
> > -av_free(rung->rem_rung_list);
> > +av_freep(>rem_rung_list);
> >  }
> >  
> >  static int els_import_byte(ElsDecCtx *ctx)
> > @@ -389,16 +389,18 @@ unsigned ff_els_decode_unsigned(ElsDecCtx *ctx, 
> > ElsUnsignedRung *ur)
> >  else {
> >  if (!rung_node->next_index) {
> >  if (ur->rung_list_size <= (ur->avail_index + 2) * 
> > sizeof(ElsRungNode)) {
> > +void *ptr_tmp;
> >  // remember rung_node position
> >  ptrdiff_t pos = rung_node - ur->rem_rung_list;
> > -ur->rem_rung_list = av_realloc(ur->rem_rung_list,
> > +ptr_tmp = av_realloc(ur->rem_rung_list,
> > ur->rung_list_size +
> > RUNG_SPACE);
> 
> Use av_reallocp instead, to remove the tmp pointer and the av_freep call
> below.

will push with that change

thx

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

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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

Re: [FFmpeg-devel] [PATCH] avcodec/cbs_mpeg2: use memcpy when assembling fragments

[James Almer]

On 4/25/2018 4:35 PM, Michael Niedermayer wrote:
> On Mon, Apr 23, 2018 at 11:39:54PM -0300, James Almer wrote:
>> before:
>> 419022 decicycles in assemble_fragment,2047 runs,  1 skips
>>
>> after:
>> 104621 decicycles in assemble_fragment,2045 runs,  3 skips
>>
>> Benched with a 2 minutes long 720x480 DVD mpeg2 sample.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/cbs_mpeg2.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> LGTM
> thx

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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4_unpack_bframes: cache input packets directly

[James Almer]

On 3/21/2018 11:21 AM, James Almer wrote:
> Avoids unnecessary allocs+copies and makes the code slightly simpler.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/mpeg4_unpack_bframes_bsf.c | 55 
> +--
>  1 file changed, 20 insertions(+), 35 deletions(-)
> 
> diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c 
> b/libavcodec/mpeg4_unpack_bframes_bsf.c
> index ba970794c5..e2e73446d8 100644
> --- a/libavcodec/mpeg4_unpack_bframes_bsf.c
> +++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
> @@ -24,8 +24,7 @@
>  #include "mpeg4video.h"
>  
>  typedef struct UnpackBFramesBSFContext {
> -uint8_t *b_frame_buf;
> -int  b_frame_buf_size;
> +AVPacket *b_frame;
>  } UnpackBFramesBSFContext;
>  
>  /* search next start code */
> @@ -71,18 +70,6 @@ static void scan_buffer(const uint8_t *buf, int buf_size,
>  }
>  }
>  
> -/* allocate new buffer and copy size bytes from src */
> -static uint8_t *create_new_buffer(const uint8_t *src, int size) {
> -uint8_t *dst = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
> -
> -if (dst) {
> -memcpy(dst, src, size);
> -memset(dst + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> -}
> -
> -return dst;
> -}
> -
>  static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, AVPacket *out)
>  {
>  UnpackBFramesBSFContext *s = ctx->priv_data;
> @@ -97,20 +84,18 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, 
> AVPacket *out)
>  av_log(ctx, AV_LOG_DEBUG, "Found %d VOP startcode(s) in this packet.\n", 
> nb_vop);
>  
>  if (pos_vop2 >= 0) {
> -if (s->b_frame_buf) {
> +if (s->b_frame->data) {
>  av_log(ctx, AV_LOG_WARNING,
> "Missing one N-VOP packet, discarding one B-frame.\n");
> -av_freep(>b_frame_buf);
> -s->b_frame_buf_size = 0;
> +av_packet_unref(s->b_frame);
>  }
>  /* store the packed B-frame in the BSFContext */
> -s->b_frame_buf_size = in->size - pos_vop2;
> -s->b_frame_buf  = create_new_buffer(in->data + pos_vop2, 
> s->b_frame_buf_size);
> -if (!s->b_frame_buf) {
> -s->b_frame_buf_size = 0;
> -ret = AVERROR(ENOMEM);
> +ret = av_packet_ref(s->b_frame, in);
> +if (ret < 0) {
>  goto fail;
>  }
> +s->b_frame->size -= pos_vop2;
> +s->b_frame->data += pos_vop2;
>  }
>  
>  if (nb_vop > 2) {
> @@ -118,29 +103,23 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext 
> *ctx, AVPacket *out)
> "Found %d VOP headers in one packet, only unpacking one.\n", nb_vop);
>  }
>  
> -if (nb_vop == 1 && s->b_frame_buf) {
> +if (nb_vop == 1 && s->b_frame->data) {
>  /* use frame from BSFContext */
> +av_packet_move_ref(out, s->b_frame);
> +
> +/* use properties from current input packet */
>  ret = av_packet_copy_props(out, in);
>  if (ret < 0) {
>  goto fail;
>  }
>  
> -ret = av_packet_from_data(out, s->b_frame_buf, s->b_frame_buf_size);
> -if (ret < 0) {
> -goto fail;
> -}
>  if (in->size <= MAX_NVOP_SIZE) {
>  /* N-VOP */
>  av_log(ctx, AV_LOG_DEBUG, "Skipping N-VOP.\n");
> -s->b_frame_buf  = NULL;
> -s->b_frame_buf_size = 0;
>  } else {
>  /* copy packet into BSFContext */
> -s->b_frame_buf_size = in->size;
> -s->b_frame_buf  = create_new_buffer(in->data, in->size);
> -if (!s->b_frame_buf) {
> -s->b_frame_buf_size = 0;
> -ret = AVERROR(ENOMEM);
> +ret = av_packet_ref(s->b_frame, in);
> +if (ret < 0) {
>  goto fail;
>  }
>  }
> @@ -168,6 +147,12 @@ fail:
>  
>  static int mpeg4_unpack_bframes_init(AVBSFContext *ctx)
>  {
> +UnpackBFramesBSFContext *s = ctx->priv_data;
> +
> +s->b_frame = av_packet_alloc();
> +if (!s->b_frame)
> +return AVERROR(ENOMEM);
> +
>  if (ctx->par_in->extradata) {
>  int pos_p_ext = -1;
>  scan_buffer(ctx->par_in->extradata, ctx->par_in->extradata_size, 
> _p_ext, NULL, NULL);
> @@ -184,7 +169,7 @@ static int mpeg4_unpack_bframes_init(AVBSFContext *ctx)
>  static void mpeg4_unpack_bframes_close(AVBSFContext *bsfc)
>  {
>  UnpackBFramesBSFContext *ctx = bsfc->priv_data;
> -av_freep(>b_frame_buf);
> +av_packet_free(>b_frame);
>  }
>  
>  static const enum AVCodecID codec_ids[] = {

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

Re: [FFmpeg-devel] [PATCH] avcodec/cbs_mpeg2: use memcpy when assembling fragments

[Michael Niedermayer]

On Mon, Apr 23, 2018 at 11:39:54PM -0300, James Almer wrote:
> before:
> 419022 decicycles in assemble_fragment,2047 runs,  1 skips
> 
> after:
> 104621 decicycles in assemble_fragment,2045 runs,  3 skips
> 
> Benched with a 2 minutes long 720x480 DVD mpeg2 sample.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/cbs_mpeg2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

LGTM
thx

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/utils: function to get the formatted ntp time

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 02:46:56PM +0530, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
> 
> This utility function creates 64-bit NTP time format as per the RFC
> 5905.
> A simple explaination of 64-bit NTP time format is here
> http://www.beaglesoft.com/Manual/page53.htm
> ---
>  libavformat/internal.h |  8 
>  libavformat/utils.c| 20 
>  2 files changed, 28 insertions(+)
> 
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 3582682..e9f758f 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -240,6 +240,14 @@ void ff_read_frame_flush(AVFormatContext *s);
>  uint64_t ff_ntp_time(void);
>  
>  /**
> + * Get the NTP time stamp formatted as per the RFC-5905.
> + *
> + * @param ntp_time NTP time in micro seconds (since NTP epoch)
> + * @return the formatted NTP time stamp
> + */
> +uint64_t ff_time_ntp_format(uint64_t ntp_time);
> +
> +/**
>   * Append the media-specific SDP fragment for the media stream c
>   * to the buffer buff.
>   *
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index c25eab4..b59d426 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4637,6 +4637,26 @@ uint64_t ff_ntp_time(void)
>  return (av_gettime() / 1000) * 1000 + NTP_OFFSET_US;
>  }
>  
> +uint64_t ff_time_ntp_format(uint64_t ntp_time)
> +{
> +uint64_t ntp_ts, frac_part;
> +uint32_t sec, usec;
> +
> +//current ntp time in seconds and micro seconds

> +sec = ntp_time / 100;

This can be truncated


> +usec = ntp_time % 100;
> +
> +//encoding in ntp timestamp format
> +frac_part = usec * 0xULL;
> +frac_part /= 100;
> +
> +ntp_ts = (uint64_t) sec;
> +ntp_ts <<= 32;
> +ntp_ts |= frac_part;
> +
> +return ntp_ts;

this looks similar to what av_rescale does.


also ff_time_ntp_format() is a bad name. It does not give any hint
on if ntp time is the input or output of the call

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] avcodec: add minimal teletext subtitle decoder

[Marton Balint]

On Tue, 24 Apr 2018, Aman Gupta wrote:


From: Aman Gupta 

Based largely on VLC's modules/codec/telx.c.

Processes only teletext pages marked as subtitles, so depending
on the stream it might not produce any output.

Subtitles are rendered directly to ASS, with support for background
colors and a best-effort at screen positioning. The ASS packets
are emitted in real time (similar to ccaption_dec's real_time
option), with -1 durations. The decoder expects that the player
will remove all existing subtitles whenever a new packet arrives.

The teletext clear command is implemented using an empty subtitle,
which removes existing subtitles but does not render anything new.


Why don't you add the ASS styling functionality to the existing 
libzvbi-teletextdec.c instead? You're duplicating lot's of code and doing 
teletext parsing which is hard to do properly so using libzvbi for it 
seems a better choice.


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

Re: [FFmpeg-devel] av_read_frame() question about blocking

[Nicolas George]

Philip Prindeville (2018-04-24):
> It looks like it’s internally going to keep making multiple calls to
> the read_packet function until it’s acquired enough.
> 
> Is that correct?

Yes. There is AVFMT_FLAG_NONBLOCK that would cause demuxers to return
AVERROR(EAGAIN) if not enough data is available immediately, but almost
no demuxer implement support for it, only devices.

For now, if you want non-blocking operation, you need to run the
demuxers in a separate context, for example a thread.

Note that unless you intend to propose actual enhancements on that
issue, the correct list to ask about the use of the FFmpeg libraries is
this one:
http://ffmpeg.org/mailman/listinfo/libav-user

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avcodec/vc1: more corrections for AC inverse quantization scaling

[Jerome Borsboom]

HALFQP should only be added to the inverse quantizer when the block is
coded with PQUANT. When PQUANT is equal to ALTPQUANT, the original test
for the addition of HALFQP fails. A negative value for mquant indicates
that the value was derived from VOPDQUANT.

Fixes #4372

Signed-off-by: Jerome Borsboom 
---
 libavcodec/vc1.c   |   1 +
 libavcodec/vc1_block.c | 129 ++---
 2 files changed, 69 insertions(+), 61 deletions(-)

diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index 20cc84eb8e..949fec6bee 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -991,6 +991,7 @@ int ff_vc1_parse_frame_header_adv(VC1Context *v, 
GetBitContext* gb)
 v->pquantizer = 1;
 break;
 }
+v->dquantfrm = 0;
 if (v->postprocflag)
 v->postproc = get_bits(gb, 2);
 
diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index af40fbd21d..0caa5ebb85 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -160,13 +160,13 @@ static void vc1_put_signed_blocks_clamped(VC1Context *v)
 int edges = 0; \
 if (v->dqprofile == DQPROFILE_ALL_MBS) {   \
 if (v->dqbilevel) {\
-mquant = (get_bits1(gb)) ? v->altpq : v->pq;   \
+mquant = (get_bits1(gb)) ? -v->altpq : v->pq;  \
 } else {   \
 mqdiff = get_bits(gb, 3);  \
 if (mqdiff != 7)   \
-mquant = v->pq + mqdiff;   \
+mquant = -v->pq - mqdiff;  \
 else   \
-mquant = get_bits(gb, 5);  \
+mquant = -get_bits(gb, 5); \
 }  \
 }  \
 if (v->dqprofile == DQPROFILE_SINGLE_EDGE) \
@@ -176,13 +176,13 @@ static void vc1_put_signed_blocks_clamped(VC1Context *v)
 else if (v->dqprofile == DQPROFILE_FOUR_EDGES) \
 edges = 15;\
 if ((edges&1) && !s->mb_x) \
-mquant = v->altpq; \
+mquant = -v->altpq;\
 if ((edges&2) && s->first_slice_line)  \
-mquant = v->altpq; \
+mquant = -v->altpq;\
 if ((edges&4) && s->mb_x == (s->mb_width - 1)) \
-mquant = v->altpq; \
+mquant = -v->altpq;\
 if ((edges&8) && s->mb_y == (s->mb_height - 1))\
-mquant = v->altpq; \
+mquant = -v->altpq;\
 if (!mquant || mquant > 31) {  \
 av_log(v->s.avctx, AV_LOG_ERROR,   \
"Overriding invalid mquant %d\n", mquant);  \
@@ -388,7 +388,7 @@ static inline int ff_vc1_pred_dc(MpegEncContext *s, int 
overlap, int pq, int n,
 int dqscale_index;
 
 /* scale predictors if needed */
-q1 = s->current_picture.qscale_table[mb_pos];
+q1 = FFABS(s->current_picture.qscale_table[mb_pos]);
 dqscale_index = s->y_dc_scale_table[q1] - 1;
 if (dqscale_index < 0)
 return 0;
@@ -404,12 +404,12 @@ static inline int ff_vc1_pred_dc(MpegEncContext *s, int 
overlap, int pq, int n,
 a = dc_val[ - wrap];
 
 if (c_avail && (n != 1 && n != 3)) {
-q2 = s->current_picture.qscale_table[mb_pos - 1];
+q2 = FFABS(s->current_picture.qscale_table[mb_pos - 1]);
 if (q2 && q2 != q1)
 c = (c * s->y_dc_scale_table[q2] * ff_vc1_dqscale[dqscale_index] + 
0x2) >> 18;
 }
 if (a_avail && (n != 2 && n != 3)) {
-q2 = s->current_picture.qscale_table[mb_pos - s->mb_stride];
+q2 = FFABS(s->current_picture.qscale_table[mb_pos - s->mb_stride]);
 if (q2 && q2 != q1)
 a = (a * s->y_dc_scale_table[q2] * ff_vc1_dqscale[dqscale_index] + 
0x2) >> 18;
 }
@@ -419,7 +419,7 @@ static inline int ff_vc1_pred_dc(MpegEncContext *s, int 
overlap, int pq, int n,
 off--;
 if (n != 2)
 off -= s->mb_stride;
-q2 = s->current_picture.qscale_table[off];
+q2 = FFABS(s->current_picture.qscale_table[off]);
 if (q2 && q2 != q1)
 b = (b * s->y_dc_scale_table[q2] * ff_vc1_dqscale[dqscale_index] + 
0x2) >> 18;
 }
@@ -700,6 +700,7 @@ static int vc1_decode_i_block_adv(VC1Context *v, int16_t 
block[64], int n,

Re: [FFmpeg-devel] [PATCH 4/5] avutil/pixdesc: add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 09:05:00PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  doc/APIchanges| 3 +++
>  libavcodec/tests/imgconvert.c | 4 
>  libavutil/pixdesc.c   | 3 +--
>  libavutil/pixdesc.h   | 8 ++--
>  libavutil/tests/pixdesc.c | 4 
>  libavutil/version.h   | 2 +-
>  6 files changed, 7 insertions(+), 17 deletions(-)

this with the rest of the patchset seems not to break anything
so no objections from me

i was wondering though if when a 2nd PAL8 is introduced which will
be with alpha

PAL8 and PAL8A seemed a natural choice name wise
iam mentioning this as if these 2 would be used then the addition of alpha
to PAL8 would have to be undone.
so it would make sense to first decide if the new format will be with or 
without alpha

thx

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH 5/5] Use AV_PIX_FMT_FLAG_ALPHA for detecting transparency where nb_components was used

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 09:05:01PM +0200, Marton Balint wrote:
> Temporarily keep the old method for ffmpeg_filters.c choose_pix_fmt and
> avfiltergraph.c pick_format() until a paletted pixel format without alpha is
> introduced.
> 
> Signed-off-by: Marton Balint 
> ---
>  fftools/ffmpeg_filter.c | 1 +
>  libavcodec/ffv1enc.c| 4 ++--
>  libavfilter/avfiltergraph.c | 1 +
>  libavutil/pixdesc.c | 2 +-
>  4 files changed, 5 insertions(+), 3 deletions(-)

should be ok

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/hnm4video: fix palette alpha

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 09:04:59PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/hnm4video.c | 1 +
>  1 file changed, 1 insertion(+)

LGTM

thx

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH 1/5] avformat/qtpalette: parse color table according to the QuickTime file format specs

[Michael Niedermayer]

On Tue, Apr 24, 2018 at 09:04:57PM +0200, Marton Balint wrote:
> The specs says that the the first color component in the color array is
> not alpha, but simply 0.
> 
> Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/qtpalette.c | 12 ++--
>  tests/ref/lavf-fate/mov_qtrle_mace6 |  2 +-
>  2 files changed, 7 insertions(+), 7 deletions(-)

probably ok (if it breaks nothing, iam not aware of anything that this breaks)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] fate clients

[Michael Niedermayer]

On Wed, Apr 25, 2018 at 12:07:53AM +0200, Michael Niedermayer wrote:
> Hi all
> 
> before anyone notices and asks ...
> my box with my virtual fate clients on it died today
> my arm clients should still be working though
> 
> Ill try to get it up and working ASAP.
> 
> Symptoms for the curious
> attempting to power the box on causes GPU and PSU fan to momentarily spin,
> nothing else moves.
> then immedeatly powers down. no beeps, ive checked that a speaker is connected
> 
> seperating the PSU and shorting the green wire causes 12/5v/3,3/-12 to be
> there continously and gray to go high for a fraction of a second.
> I assume the gray (power check) should stay high, so if thats the case 
> thats a PSU failure
> so ill buy a new PSU tomorrow probably

should all be alive again.
If you spot something that broke then tell me.
at least 2 clients had corrupted git checkouts

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Rostislav Pehlivanov]

On 24 April 2018 at 07:18, Thomas Volkert  wrote:

> On 23.04.2018 21:33, Rostislav Pehlivanov wrote:
> > On 23 April 2018 at 20:16, Thomas Volkert  wrote:
> >
> >> On 23.04.2018 11:27, Thomas Volkert wrote:
> >>> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:
>  2018-04-22 20:00 GMT+02:00, Nicolas George :
> > Carl Eugen Hoyos (2018-04-22):
> >> How do you detect that this is not the "current version" of mbed?
> > Is it really our responsibility?
>  We try to always do it and I believe that allowing LGPL makes
>  more sense and less headache: Since we do the checks so
>  rigorously it makes sense to assume we did it as correctly
>  for this case.
> 
>  I don't understand why we don't go the easy way that clearly
>  has advantages instead for the complicated way (with at
>  least some disadvantages).
> >>> Okay. I looked over their web page and the Debian packages again.
> >>> The web page of mbedTLS declares Apache license as the "primary open
> >>> source license".
> >>>
> >>> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
> >>> their are no further objections.
> >> pushed
> >>
> >>
> >> Sorry, had to revert, I'd still like to know what gains (disk space,
> >> performance, maybe security-wise too if possible), this would have over
> >> existing TLS libraries. Code-wise it looked fine.
> >>
> Okay.
>
> Is the idea to have a detailed comparison (measurement values, feature
> comparison) between the TLS implementations and then decide if we accept
> or drop the patch?
> Do you have already defined threshold values for disk space and
> performance by which you will decide if it is worth to integrate mbedTLS
> in FFmpeg?
>
> Best regards,
> Thomas.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yes, I'd like to have a comparison. No, I don't have a hard threshold,
it'll depend on how well mbedtls measures up to the alternatives.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Thomas Mundt]

Hi,

2018-04-25 16:24 GMT+02:00 Vasile Toncu :

> Hello,
>
> Here is patch 3. I renamed reinterlace to tinterlace and replaced the
> functionality of tinterlace with the one from reinterlace. Please review.
>
> Thank you,
> Vasile
>

Same as I wrote for your previous version.
Lots of compiler warnings. Fate tests fail.
Please fix.

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mediacodecdec: clarify delay_flush specific code

[Matthieu Bouron]

On Tue, Apr 24, 2018 at 01:59:23PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/mediacodecdec.c| 24 +++-
>  libavcodec/mediacodecdec_common.c | 12 
>  2 files changed, 15 insertions(+), 21 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 0d4a853f07..e5d3e6a0af 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -419,27 +419,9 @@ static int mediacodec_receive_frame(AVCodecContext 
> *avctx, AVFrame *frame)
>  MediaCodecH264DecContext *s = avctx->priv_data;
>  int ret;
>  
> -/*
> - * MediaCodec.flush() discards both input and output buffers, thus we
> - * need to delay the call to this function until the user has released or
> - * renderered the frames he retains.
> - *
> - * After we have buffered an input packet, check if the codec is in the
> - * flushing state. If it is, we need to call ff_mediacodec_dec_flush.
> - *
> - * ff_mediacodec_dec_flush returns 0 if the flush cannot be performed on
> - * the codec (because the user retains frames). The codec stays in the
> - * flushing state.
> - *
> - * ff_mediacodec_dec_flush returns 1 if the flush can actually be
> - * performed on the codec. The codec leaves the flushing state and can
> - * process again packets.
> - *
> - * ff_mediacodec_dec_flush returns a negative value if an error has
> - * occurred.
> - *
> - */
> -if (ff_mediacodec_dec_is_flushing(avctx, s->ctx)) {
> +/* in delay_flush mode, wait until the user has released or rendered

NIT: In delay_flush mode, [...]

> +   all retained frames. */
> +if (s->delay_flush && ff_mediacodec_dec_is_flushing(avctx, s->ctx)) {
>  if (!ff_mediacodec_dec_flush(avctx, s->ctx)) {
>  return AVERROR(EAGAIN);
>  }
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index e59cf19aad..0c27624dea 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -764,6 +764,18 @@ int ff_mediacodec_dec_receive(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  return AVERROR(EAGAIN);
>  }
>  
> +/*
> +* ff_mediacodec_dec_flush returns 0 if the flush cannot be performed on
> +* the codec (because the user retains frames). The codec stays in the
> +* flushing state.
> +*
> +* ff_mediacodec_dec_flush returns 1 if the flush can actually be
> +* performed on the codec. The codec leaves the flushing state and can
> +* process again packets.
> +*
> +* ff_mediacodec_dec_flush returns a negative value if an error has
> +* occurred.
> +*/
>  int ff_mediacodec_dec_flush(AVCodecContext *avctx, MediaCodecDecContext *s)
>  {
>  if (!s->surface || atomic_load(>refcount) == 1) {
> -- 
> 2.14.2
> 

LGTM.

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

Re: [FFmpeg-devel] [PATCH 3/4] avcodec/mediacodecdec: refactor pts handling

[Matthieu Bouron]

On Tue, Apr 24, 2018 at 01:59:25PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Also fixes a bug where EOS buffer was sent with incorrect
> pts when not using surface generation.
> ---
>  libavcodec/mediacodecdec_common.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index 56b3c4fd1e..c0f0a6b983 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -571,6 +571,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  FFAMediaCodec *codec = s->codec;
>  int status;
>  int64_t input_dequeue_timeout_us = INPUT_DEQUEUE_TIMEOUT_US;
> +int64_t pts;
>  
>  if (s->flushing) {
>  av_log(avctx, AV_LOG_ERROR, "Decoder is flushing and cannot accept 
> new buffer "
> @@ -605,14 +606,14 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  return AVERROR_EXTERNAL;
>  }
>  
> +pts = pkt->pts;
> +if (pts != AV_NOPTS_VALUE && avctx->pkt_timebase.num && 
> avctx->pkt_timebase.den) {
> +pts = av_rescale_q(pts, avctx->pkt_timebase, AV_TIME_BASE_Q);
> +}
> +
>  if (need_draining) {
> -int64_t pts = pkt->pts;
>  uint32_t flags = ff_AMediaCodec_getBufferFlagEndOfStream(codec);
>  
> -if (s->surface) {
> -pts = av_rescale_q(pts, avctx->pkt_timebase, AV_TIME_BASE_Q);
> -}
> -
>  av_log(avctx, AV_LOG_DEBUG, "Sending End Of Stream signal\n");
>  
>  status = ff_AMediaCodec_queueInputBuffer(codec, index, 0, 0, 
> pts, flags);
> @@ -627,16 +628,10 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  s->draining = 1;
>  break;
>  } else {
> -int64_t pts = pkt->pts;
> -
>  size = FFMIN(pkt->size - offset, size);
>  memcpy(data, pkt->data + offset, size);
>  offset += size;
>  
> -if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
> -pts = av_rescale_q(pts, avctx->pkt_timebase, AV_TIME_BASE_Q);
> -}
> -
>  status = ff_AMediaCodec_queueInputBuffer(codec, index, 0, size, 
> pts, 0);
>  if (status < 0) {
>  av_log(avctx, AV_LOG_ERROR, "Failed to queue input buffer 
> (status = %d)\n", status);
> -- 
> 2.14.2
> 

LGTM.

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

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/mediacodecdec: use AV_TIME_BASE_Q

[Matthieu Bouron]

On Tue, Apr 24, 2018 at 01:59:24PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/mediacodecdec_common.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index 0c27624dea..56b3c4fd1e 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -209,7 +209,7 @@ static int mediacodec_wrap_hw_buffer(AVCodecContext 
> *avctx,
>  
>  if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
>  frame->pts = av_rescale_q(info->presentationTimeUs,
> -  av_make_q(1, 100),
> +  AV_TIME_BASE_Q,
>avctx->pkt_timebase);
>  } else {
>  frame->pts = info->presentationTimeUs;
> @@ -298,7 +298,7 @@ static int mediacodec_wrap_sw_buffer(AVCodecContext 
> *avctx,
>   *   * 0-sized avpackets are pushed to flush remaining frames at EOS */
>  if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
>  frame->pts = av_rescale_q(info->presentationTimeUs,
> -  av_make_q(1, 100),
> +  AV_TIME_BASE_Q,
>avctx->pkt_timebase);
>  } else {
>  frame->pts = info->presentationTimeUs;
> @@ -610,7 +610,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  uint32_t flags = ff_AMediaCodec_getBufferFlagEndOfStream(codec);
>  
>  if (s->surface) {
> -pts = av_rescale_q(pts, avctx->pkt_timebase, av_make_q(1, 
> 100));
> +pts = av_rescale_q(pts, avctx->pkt_timebase, AV_TIME_BASE_Q);
>  }
>  
>  av_log(avctx, AV_LOG_DEBUG, "Sending End Of Stream signal\n");
> @@ -634,7 +634,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx, 
> MediaCodecDecContext *s,
>  offset += size;
>  
>  if (avctx->pkt_timebase.num && avctx->pkt_timebase.den) {
> -pts = av_rescale_q(pts, avctx->pkt_timebase, av_make_q(1, 
> 100));
> +pts = av_rescale_q(pts, avctx->pkt_timebase, AV_TIME_BASE_Q);
>  }
>  
>  status = ff_AMediaCodec_queueInputBuffer(codec, index, 0, size, 
> pts, 0);
> -- 
> 2.14.2
> 

LGTM.

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

Re: [FFmpeg-devel] [PATCH v2] mov: Properly abide by the track's media duration

[Derek Buitenhuis]

On 4/23/2018 4:46 PM, Derek Buitenhuis wrote:
> The track's media duration from the mdhd atom takes precedence
> over both the stts and elst atom for calculating and setting
> the track's total duraion.
> 
> Technically, we shouldn't be using the stts atom at all for
> calculating stream durations.
> 
> This fixes incorrect stream and final packet durations on files
> with edit lists that are longer than the media duration.
> 
> The FATE changes are expected, and output is more correct (the
> AAC frame is not 1028 samples).
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/mov.c   | 6 +++---
>  tests/ref/fate/adtstoasc_ticket3715 | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)

Ping.

If there are no further comments, I plan to push tomorrow evening.

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

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Gyan Doshi]

On 4/25/2018 7:54 PM, Vasile Toncu wrote:

Hello,

Here is patch 3. I renamed reinterlace to tinterlace and replaced the 
functionality of tinterlace with the one from reinterlace. Please review.


If any options are new or different from the original tinterlace filter, 
please add doc entries for them in doc/filters.texi


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

Re: [FFmpeg-devel] [PATCH 3/5] reitnerlace - tinterlace-like filter under LGPL

[Thomas Mundt]

Hi,

2018-04-23 18:22 GMT+02:00 Vasile Toncu :

> Hello,
>
> Here is patch 3. Please review.
>
> Thank you,
> Vasile
>

Some fate tests fail when both patches are applied.
I also get lots of compiler warnings.
Please fix them and, as already said, run fate.
All tests must pass, otherwise there is something wrong with your filter.

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

Re: [FFmpeg-devel] [PATCH 2/5] Added reinterlace filter

[Vasile Toncu]

Hello,

Here is patch 2. In this patch I added the reinterlace filter to ffmpeg. 
Please review.


Thank you,
Vasile
>From 71458a6cba548c9d5a559cdadae7a85a7825e98d Mon Sep 17 00:00:00 2001
From: Vasile Toncu 
Date: Tue, 24 Apr 2018 17:46:45 +0300
Subject: [PATCH] Patch2

Signed-off-by: Vasile Toncu 
---
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/reinterlace.h | 125 ++
 libavfilter/vf_reinterlace.c  | 765 ++
 libavfilter/x86/Makefile  |   1 +
 libavfilter/x86/vf_reinterlace_init.c | 102 +
 6 files changed, 995 insertions(+)
 create mode 100644 libavfilter/reinterlace.h
 create mode 100644 libavfilter/vf_reinterlace.c
 create mode 100644 libavfilter/x86/vf_reinterlace_init.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8f41805..af702ba 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -294,6 +294,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
 OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
 OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
+OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
 OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
 OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 643eec2..5488ff4 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -285,6 +285,7 @@ extern AVFilter ff_vf_random;
 extern AVFilter ff_vf_readeia608;
 extern AVFilter ff_vf_readvitc;
 extern AVFilter ff_vf_realtime;
+extern AVFilter ff_vf_reinterlace;
 extern AVFilter ff_vf_remap;
 extern AVFilter ff_vf_removegrain;
 extern AVFilter ff_vf_removelogo;
diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
new file mode 100644
index 000..f90b43a
--- /dev/null
+++ b/libavfilter/reinterlace.h
@@ -0,0 +1,125 @@
+/*
+ * Copyright (c) 2018 Vasile Toncu 
+ * Copyright (c) 2017 Thomas Mundt 
+ *
+ * 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 
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "libavutil/bswap.h"
+
+enum FilterMode {
+MODE_MERGE,
+MODE_DROP_EVEN,
+MODE_DROP_ODD,
+MODE_PAD,
+MODE_INTERLEAVE_TOP,
+MODE_INTERLEAVE_BOTTOM,
+MODE_INTERLACE_X2,
+MODE_MERGE_X2,
+MODE_MERGE_TFF,
+MODE_MERGE_BFF,
+MODE_NB
+};
+
+enum FilterFlags {
+FLAG_NOTHING= 0x00,
+FLAG_VLPF   = 0x01,
+FLAG_EXACT_TB   = 0x02,
+FLAG_CVLPF  = 0x04,
+FLAG_NB
+};
+
+static const AVRational standard_tbs[] = {
+{1, 25},
+{1, 30},
+{1001, 3},
+};
+
+typedef struct {
+const AVClass *class;
+int mode;
+int flags;
+
+AVFrame *prev_frame, *current_frame;
+int64_t current_frame_index;
+
+void *black_vec[4];
+
+int skip_next_frame;
+
+void *thread_data;
+
+uint8_t bit_depth;
+
+void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t *srcp,
+ ptrdiff_t mref, ptrdiff_t pref, int clip_max);
+
+AVRational preout_time_base;
+
+} ReInterlaceContext;
+
+#if CONFIG_GPL
+void ff_reinterlace_init_x86(ReInterlaceContext *reinterlace);
+#endif
+
+#define OFFSET(x) offsetof(ReInterlaceContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption reinterlace_options[] = {
+{ "mode", "set mode", OFFSET(mode), AV_OPT_TYPE_INT, {.i64=MODE_MERGE}, 0, MODE_NB - 1, FLAGS, "mode" },
+{ "merge", "merge frames",0, AV_OPT_TYPE_CONST, {.i64=MODE_MERGE},INT_MIN, INT_MAX, FLAGS, "mode"},
+{ "drop_even", "drop even frames",0, AV_OPT_TYPE_CONST, {.i64=MODE_DROP_EVEN},INT_MIN, 

Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace

[Vasile Toncu]

Hello,

Here is patch 3. I renamed reinterlace to tinterlace and replaced the 
functionality of tinterlace with the one from reinterlace. Please review.


Thank you,
Vasile
>From ee33ed769207a99adb193eece32a5043ff0b6d94 Mon Sep 17 00:00:00 2001
From: Vasile Toncu 
Date: Wed, 25 Apr 2018 11:02:46 +0300
Subject: [PATCH] Patch3

Signed-off-by: Vasile Toncu 
---
 configure |   1 -
 libavfilter/Makefile  |   1 -
 libavfilter/allfilters.c  |   1 -
 libavfilter/reinterlace.h | 125 -
 libavfilter/tinterlace.h  | 155 +--
 libavfilter/vf_reinterlace.c  | 765 ---
 libavfilter/vf_tinterlace.c   | 831 +-
 libavfilter/x86/Makefile  |   1 -
 libavfilter/x86/vf_reinterlace_init.c | 102 -
 libavfilter/x86/vf_tinterlace_init.c  |  42 +-
 10 files changed, 664 insertions(+), 1360 deletions(-)
 delete mode 100644 libavfilter/reinterlace.h
 delete mode 100644 libavfilter/vf_reinterlace.c
 delete mode 100644 libavfilter/x86/vf_reinterlace_init.c

diff --git a/configure b/configure
index dee507c..d8bc940 100755
--- a/configure
+++ b/configure
@@ -3388,7 +3388,6 @@ stereo3d_filter_deps="gpl"
 subtitles_filter_deps="avformat avcodec libass"
 super2xsai_filter_deps="gpl"
 pixfmts_super2xsai_test_deps="super2xsai_filter"
-tinterlace_filter_deps="gpl"
 tinterlace_merge_test_deps="tinterlace_filter"
 tinterlace_pad_test_deps="tinterlace_filter"
 tonemap_filter_deps="const_nan"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index af702ba..8f41805 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -294,7 +294,6 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
 OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o
 OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
-OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
 OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
 OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5488ff4..643eec2 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -285,7 +285,6 @@ extern AVFilter ff_vf_random;
 extern AVFilter ff_vf_readeia608;
 extern AVFilter ff_vf_readvitc;
 extern AVFilter ff_vf_realtime;
-extern AVFilter ff_vf_reinterlace;
 extern AVFilter ff_vf_remap;
 extern AVFilter ff_vf_removegrain;
 extern AVFilter ff_vf_removelogo;
diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
deleted file mode 100644
index f90b43a..000
--- a/libavfilter/reinterlace.h
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
- * Copyright (c) 2018 Vasile Toncu 
- * Copyright (c) 2017 Thomas Mundt 
- *
- * 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 
-
-#include "avfilter.h"
-#include "formats.h"
-#include "internal.h"
-#include "video.h"
-#include "libavutil/avassert.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/opt.h"
-#include "libavutil/pixdesc.h"
-
-#include "libavutil/bswap.h"
-
-enum FilterMode {
-MODE_MERGE,
-MODE_DROP_EVEN,
-MODE_DROP_ODD,
-MODE_PAD,
-MODE_INTERLEAVE_TOP,
-MODE_INTERLEAVE_BOTTOM,
-MODE_INTERLACE_X2,
-MODE_MERGE_X2,
-MODE_MERGE_TFF,
-MODE_MERGE_BFF,
-MODE_NB
-};
-
-enum FilterFlags {
-FLAG_NOTHING= 0x00,
-FLAG_VLPF   = 0x01,
-FLAG_EXACT_TB   = 0x02,
-FLAG_CVLPF  = 0x04,
-FLAG_NB
-};
-
-static const AVRational standard_tbs[] = {
-{1, 25},
-{1, 30},
-{1001, 3},
-};
-
-typedef struct {
-const AVClass *class;
-int mode;
-int flags;
-
-AVFrame *prev_frame, *current_frame;
-int64_t current_frame_index;
-
-void *black_vec[4];
-
-int skip_next_frame;
-
-void *thread_data;
-
-uint8_t bit_depth;
-
-void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t *srcp,
- ptrdiff_t mref, 

Re: [FFmpeg-devel] [GSoC] FFserver further development direction

[wm4]

On Tue, 24 Apr 2018 23:46:09 +0200
Nicolas George  wrote:

> Stephan Holljes (2018-04-24):
> > The consensus seems to be that there are more disadvantages in using
> > the http server of libavformat than there are advantages.  
> 
> I completely disagree. There is no point in having the HTTP server in
> libavformat if it cannot be used to implement exactly that kind of
> thing. Implementing ffserver with it is just the test bed that it
> requires to become mature.
> 
> The HTTP server in libavformat was accepted three years ago, and you
> worked hard for it. Do not let people tell you it was for nothing. They
> had their chance to discuss this three years ago.

Sunk cost fallacy, and future maintenance overhead.

> > This arose partly out of the discussion that there is no way to get a
> > connected peer's address through the public API (as the filedescriptor
> > is hidden in private structs).  
> 
> Well, then, let us add the functions that are needed in the public API.
> It does not seem that difficult to design.
> 
> Regards,
> 

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: use the new SAR early when setting the decoder

[wm4]

On Wed, 25 Apr 2018 09:55:10 +0200
Steve Lhomme  wrote:

> Le 24/04/2018 à 08:28, Hendrik Leppkes a écrit :
> > On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme  wrote:  
> >> If we don't do that get_format might not be called for a while and the 
> >> proper
> >> SAR not used.
> >>
> >> See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435
> >> ---
> >>   libavcodec/h264_slice.c | 4 +++-
> >>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> >> index e6b7998834..319a37f5b6 100644
> >> --- a/libavcodec/h264_slice.c
> >> +++ b/libavcodec/h264_slice.c
> >> @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const 
> >> H264SliceContext *sl, int first_sl
> >>   || (non_j_pixfmt(h->avctx->pix_fmt) != 
> >> non_j_pixfmt(get_pixel_format(h, 0
> >>   must_reinit = 1;
> >>
> >> -if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio))
> >> +if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) 
> >> {
> >>   must_reinit = 1;
> >> +ff_set_sar(h->avctx, sps->sar);
> >> +}
> >>
> >>   if (!h->setup_finished) {
> >>   h->avctx->profile = ff_h264_get_profile(sps);
> >> --
> >> 2.14.2  
> > Why do we even do a get_format call for aspect ratio changes in the
> > first place? It doesn't change the physical image properties, the
> > format of image buffers etc remains the same, hwaccel decisions remain
> > the same.. anyone know why this is?  
> 
> How are we supposed to know the display format has changed ? Checking 
> each AVFrame sample_aspect_ratio to see if something changed ?

Yes. get_format is for allocating memory only.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Nicolas George]

Paul B Mahol (2018-04-25):
> Looks like interest is very low...

Obviously you think it is interesting enough to post several mails about
it.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Paul B Mahol]

On 4/25/18, Tomas Haerdin  wrote:
> ons 2018-04-25 klockan 09:55 +0100 skrev Josh de Kock:
>> On 2018/04/25 9:35, Paul B Mahol wrote:
>> > On 4/25/18, Tomas Haerdin  wrote:
>> > > [...]
>> > >
>> > > I'll push this this some time later this week if I don't hear any
>> > > objections
>> >
>> > What is point of it if there is only one nickname?
>>
>> There are two nicknames.
>
> Suggest more then, or just push your own in the future

Looks like interest is very low...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Tomas Härdin]

ons 2018-04-25 klockan 09:55 +0100 skrev Josh de Kock:
> On 2018/04/25 9:35, Paul B Mahol wrote:
> > On 4/25/18, Tomas Haerdin  wrote:
> > > [...]
> > > 
> > > I'll push this this some time later this week if I don't hear any
> > > objections
> > 
> > What is point of it if there is only one nickname?
> 
> There are two nicknames.

Suggest more then, or just push your own in the future

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: use the new SAR early when setting the decoder

[Hendrik Leppkes]

On Wed, Apr 25, 2018 at 9:55 AM, Steve Lhomme  wrote:
> Le 24/04/2018 à 08:28, Hendrik Leppkes a écrit :
>>
>> On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme  wrote:
>>>
>>> If we don't do that get_format might not be called for a while and the
>>> proper
>>> SAR not used.
>>>
>>> See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435
>>> ---
>>>   libavcodec/h264_slice.c | 4 +++-
>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
>>> index e6b7998834..319a37f5b6 100644
>>> --- a/libavcodec/h264_slice.c
>>> +++ b/libavcodec/h264_slice.c
>>> @@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const
>>> H264SliceContext *sl, int first_sl
>>>   || (non_j_pixfmt(h->avctx->pix_fmt) !=
>>> non_j_pixfmt(get_pixel_format(h, 0
>>>   must_reinit = 1;
>>>
>>> -if (first_slice && av_cmp_q(sps->sar,
>>> h->avctx->sample_aspect_ratio))
>>> +if (first_slice && av_cmp_q(sps->sar,
>>> h->avctx->sample_aspect_ratio)) {
>>>   must_reinit = 1;
>>> +ff_set_sar(h->avctx, sps->sar);
>>> +}
>>>
>>>   if (!h->setup_finished) {
>>>   h->avctx->profile = ff_h264_get_profile(sps);
>>> --
>>> 2.14.2
>>
>> Why do we even do a get_format call for aspect ratio changes in the
>> first place? It doesn't change the physical image properties, the
>> format of image buffers etc remains the same, hwaccel decisions remain
>> the same.. anyone know why this is?
>
>
> How are we supposed to know the display format has changed ? Checking each
> AVFrame sample_aspect_ratio to see if something changed ?
>

Exactly. There is a lot more properties that do not and should not
call get_format, like color properties
(matrix,trc,primaries,range,etc).
get_format should be called when the physical properties of the image
buffer change, not its interpretation.

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

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Josh de Kock]

On 2018/04/25 9:35, Paul B Mahol wrote:

On 4/25/18, Tomas Haerdin  wrote:

[...]

I'll push this this some time later this week if I don't hear any
objections


What is point of it if there is only one nickname?


There are two nicknames.

--
Josh

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

Re: [FFmpeg-devel] [PATCH 10/26] vaapi_encode: Choose profiles dynamically

[Xiang, Haihao]

> Previously there was one fixed choice for each codec (e.g. H.265 -> Main
> profile), and using anything else then required an explicit option from
> the user.  This changes to selecting the profile based on the input format
> and the set of profiles actually supported by the driver (e.g. P010 input
> will choose Main 10 profile for H.265 if the driver supports it).
> 
> The entrypoint and render target format are also chosen dynamically in the
> same way, removing those explicit selections from the per-codec code.
> ---
>  doc/encoders.texi   |   3 +
>  libavcodec/vaapi_encode.c   | 261 +++--
> ---
>  libavcodec/vaapi_encode.h   |  41 +--
>  libavcodec/vaapi_encode_h264.c  |  45 ++-
>  libavcodec/vaapi_encode_h265.c  |  43 +++
>  libavcodec/vaapi_encode_mjpeg.c |  13 +-
>  libavcodec/vaapi_encode_mpeg2.c |  36 ++
>  libavcodec/vaapi_encode_vp8.c   |  11 +-
>  libavcodec/vaapi_encode_vp9.c   |  34 ++
>  9 files changed, 306 insertions(+), 181 deletions(-)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 7b095754d1..16be6359b3 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2565,6 +2565,9 @@ The following standard libavcodec options are used:
>  @option{bf} / @option{max_b_frames}
>  @item
>  @option{profile}
> +
> +If not set, this will be determined automatically from the format of the
> input
> +frames and the profiles supported by the driver.
>  @item
>  @option{level}
>  @item
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 9c5cfc7a65..9c39bcdeff 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -983,70 +983,237 @@ static av_cold void
> vaapi_encode_add_global_param(AVCodecContext *avctx,
>  ++ctx->nb_global_params;
>  }
>  
> -static av_cold int vaapi_encode_config_attributes(AVCodecContext *avctx)
> +typedef struct VAAPIEncodeRTFormat {
> +const char *name;
> +unsigned int value;
> +int depth;
> +int log2_chroma_w;
> +int log2_chroma_h;
> +} VAAPIEncodeRTFormat;
> +
> +static const VAAPIEncodeRTFormat vaapi_encode_rt_formats[] = {
> +{ "YUV420",VA_RT_FORMAT_YUV420,8, 1, 1 },
> +{ "YUV422",VA_RT_FORMAT_YUV422,8, 1, 0 },
> +{ "YUV444",VA_RT_FORMAT_YUV444,8, 0, 0 },
> +{ "YUV411",VA_RT_FORMAT_YUV411,8, 2, 0 },
> +#if VA_CHECK_VERSION(0, 38, 1)
> +{ "YUV420_10", VA_RT_FORMAT_YUV420_10BPP, 10, 1, 1 },
> +#endif
> +};
> +
> +static const VAEntrypoint vaapi_encode_entrypoints_normal[] = {
> +VAEntrypointEncSlice,
> +VAEntrypointEncPicture,
> +VAEntrypointEncSliceLP,
> +0
> +};
> +static const VAEntrypoint vaapi_encode_entrypoints_low_power[] = {
> +VAEntrypointEncSliceLP,
> +0
> +};
> +
> +static av_cold int vaapi_encode_profile_entrypoint(AVCodecContext *avctx)
>  {
> -VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAAPIEncodeContext  *ctx = avctx->priv_data;
> +VAProfile*va_profiles= NULL;
> +VAEntrypoint *va_entrypoints = NULL;
>  VAStatus vas;
> -int i, n, err;
> -VAProfile*profiles= NULL;
> -VAEntrypoint *entrypoints = NULL;
> -VAConfigAttrib attr[] = {
> -{ VAConfigAttribRTFormat },
> -{ VAConfigAttribRateControl  },
> -{ VAConfigAttribEncMaxRefFrames  },
> -{ VAConfigAttribEncPackedHeaders },
> -};
> +const VAEntrypoint *usable_entrypoints;
> +const VAAPIEncodeProfile *profile;
> +const AVPixFmtDescriptor *desc;
> +VAConfigAttrib rt_format_attr;
> +const VAAPIEncodeRTFormat *rt_format;
> +int i, j, n, depth, err;
> +
> +
> +if (ctx->low_power) {
> +#if VA_CHECK_VERSION(0, 39, 2)
> +usable_entrypoints = vaapi_encode_entrypoints_low_power;
> +#else
> +av_log(avctx, AV_LOG_ERROR, "Low-power encoding is not "
> +   "supported with this VAAPI version.\n");
> +return AVERROR(EINVAL);
> +#endif
> +} else {
> +usable_entrypoints = vaapi_encode_entrypoints_normal;
> +}
> +
> +desc = av_pix_fmt_desc_get(ctx->input_frames->sw_format);
> +if (!desc) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid input pixfmt (%d).\n",
> +   ctx->input_frames->sw_format);
> +return AVERROR(EINVAL);
> +}
> +depth = desc->comp[0].depth;
> +for (i = 1; i < desc->nb_components; i++) {
> +if (desc->comp[i].depth != depth) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid input pixfmt (%s).\n",
> +   desc->name);
> +return AVERROR(EINVAL);
> +}
> +}
> +av_log(avctx, AV_LOG_VERBOSE, "Input surface format is %s.\n",
> +   desc->name);
>  
>  n = vaMaxNumProfiles(ctx->hwctx->display);
> -profiles = av_malloc_array(n, sizeof(VAProfile));
> -if (!profiles) {
> +va_profiles = av_malloc_array(n, sizeof(VAProfile));
> +if (!va_profiles) {
>  err = 

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Paul B Mahol]

On 4/25/18, Tomas Haerdin  wrote:
> tor 2018-04-12 klockan 16:54 +0200 skrev Tomas Haerdin:
>> tor 2018-04-12 klockan 16:47 +0200 skrev wm4:
>> > On Thu, 12 Apr 2018 16:43:48 +0200
>> > Tomas Haerdin  wrote:
>> >
>> > > soen 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
>> > > > On Sun, Apr 8, 2018, at 3:05 AM, Tomas Haerdin wrote:
>> > > > >
>> > > > > Good suggestion
>> > > > >
>> > > > > /Tomas
>> > > >
>> > > > Patch LGTM with the suggestion from James. Although I'm not on
>> > > > IRC
>> > > > very often lately you can add mine too if you feel like it:
>> > > > llogan.
>> > >
>> > > Alright, how about this?
>> >
>> > Btw. not everyone is going to have a GPG fingerprint.
>>
>> That's true. I'd suggest they make themselves known :)
>>
>> We could of course just omit fingerprint for those folks
>
> I'll push this this some time later this week if I don't hear any
> objections

What is point of it if there is only one nickname?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Add IRC nicknames to MAINTAINERS?

[Tomas Härdin]

tor 2018-04-12 klockan 16:54 +0200 skrev Tomas Härdin:
> tor 2018-04-12 klockan 16:47 +0200 skrev wm4:
> > On Thu, 12 Apr 2018 16:43:48 +0200
> > Tomas Härdin  wrote:
> > 
> > > sön 2018-04-08 klockan 09:20 -0800 skrev Lou Logan:
> > > > On Sun, Apr 8, 2018, at 3:05 AM, Tomas Härdin wrote:
> > > > > 
> > > > > Good suggestion
> > > > > 
> > > > > /Tomas
> > > > 
> > > > Patch LGTM with the suggestion from James. Although I'm not on
> > > > IRC
> > > > very often lately you can add mine too if you feel like it:
> > > > llogan.
> > > 
> > > Alright, how about this?
> > 
> > Btw. not everyone is going to have a GPG fingerprint.
> 
> That's true. I'd suggest they make themselves known :)
> 
> We could of course just omit fingerprint for those folks

I'll push this this some time later this week if I don't hear any
objections

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

Re: [FFmpeg-devel] [PATCH] make swresample optional for ffmpeg

[Paul B Mahol]

On 4/16/18, Paul B Mahol  wrote:
> On 4/12/18, Paul B Mahol  wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  configure| 2 +-
>>  fftools/ffmpeg_opt.c | 2 ++
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>
> ping
>

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: use the new SAR early when setting the decoder

[Steve Lhomme]

Le 24/04/2018 à 08:28, Hendrik Leppkes a écrit :

On Fri, Jan 19, 2018 at 1:01 PM, Steve Lhomme  wrote:

If we don't do that get_format might not be called for a while and the proper
SAR not used.

See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435
---
  libavcodec/h264_slice.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index e6b7998834..319a37f5b6 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const 
H264SliceContext *sl, int first_sl
  || (non_j_pixfmt(h->avctx->pix_fmt) != 
non_j_pixfmt(get_pixel_format(h, 0
  must_reinit = 1;

-if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio))
+if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) {
  must_reinit = 1;
+ff_set_sar(h->avctx, sps->sar);
+}

  if (!h->setup_finished) {
  h->avctx->profile = ff_h264_get_profile(sps);
--
2.14.2

Why do we even do a get_format call for aspect ratio changes in the
first place? It doesn't change the physical image properties, the
format of image buffers etc remains the same, hwaccel decisions remain
the same.. anyone know why this is?


How are we supposed to know the display format has changed ? Checking 
each AVFrame sample_aspect_ratio to see if something changed ?




- Hendrik
___
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 04/26] vaapi_encode_mpeg2: Move common structure into context

[Xiang, Haihao]

> ---
>  libavcodec/vaapi_encode_mpeg2.c | 50 --
> ---
>  1 file changed, 24 insertions(+), 26 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c
> index 42df77ea49..5dd1f39cbc 100644
> --- a/libavcodec/vaapi_encode_mpeg2.c
> +++ b/libavcodec/vaapi_encode_mpeg2.c
> @@ -28,6 +28,9 @@
>  #include "vaapi_encode.h"
>  
>  typedef struct VAAPIEncodeMPEG2Context {
> +VAAPIEncodeContext common;
> +
> +// Derived settings.
>  int mb_width;
>  int mb_height;
>  
> @@ -35,15 +38,6 @@ typedef struct VAAPIEncodeMPEG2Context {
>  int quant_p;
>  int quant_b;
>  
> -MPEG2RawSequenceHeader sequence_header;
> -MPEG2RawExtensionData  sequence_extension;
> -MPEG2RawExtensionData  sequence_display_extension;
> -MPEG2RawGroupOfPicturesHeader gop_header;
> -MPEG2RawPictureHeader  picture_header;
> -MPEG2RawExtensionData  picture_coding_extension;
> -
> -int64_t last_i_frame;
> -
>  unsigned int bit_rate;
>  unsigned int vbv_buffer_size;
>  
> @@ -52,6 +46,17 @@ typedef struct VAAPIEncodeMPEG2Context {
>  unsigned int f_code_horizontal;
>  unsigned int f_code_vertical;
>  
> +// Stream state.
> +int64_t last_i_frame;
> +
> +// Writer structures.
> +MPEG2RawSequenceHeader sequence_header;
> +MPEG2RawExtensionData  sequence_extension;
> +MPEG2RawExtensionData  sequence_display_extension;
> +MPEG2RawGroupOfPicturesHeader gop_header;
> +MPEG2RawPictureHeader  picture_header;
> +MPEG2RawExtensionData  picture_coding_extension;
> +
>  CodedBitstreamContext *cbc;
>  CodedBitstreamFragment current_fragment;
>  } VAAPIEncodeMPEG2Context;
> @@ -61,8 +66,7 @@ static int vaapi_encode_mpeg2_write_fragment(AVCodecContext
> *avctx,
>   char *data, size_t *data_len,
>   CodedBitstreamFragment *frag)
>  {
> -VAAPIEncodeContext   *ctx = avctx->priv_data;
> -VAAPIEncodeMPEG2Context *priv = ctx->priv_data;
> +VAAPIEncodeMPEG2Context *priv = avctx->priv_data;
>  int err;
>  
>  err = ff_cbs_write_fragment_data(priv->cbc, frag);
> @@ -88,8 +92,7 @@ static int vaapi_encode_mpeg2_add_header(AVCodecContext
> *avctx,
>   CodedBitstreamFragment *frag,
>   int type, void *header)
>  {
> -VAAPIEncodeContext   *ctx = avctx->priv_data;
> -VAAPIEncodeMPEG2Context *priv = ctx->priv_data;
> +VAAPIEncodeMPEG2Context *priv = avctx->priv_data;
>  int err;
>  
>  err = ff_cbs_insert_unit_content(priv->cbc, frag, -1, type, header,
> NULL);
> @@ -105,8 +108,7 @@ static int vaapi_encode_mpeg2_add_header(AVCodecContext
> *avctx,
>  static int vaapi_encode_mpeg2_write_sequence_header(AVCodecContext *avctx,
>  char *data, size_t
> *data_len)
>  {
> -VAAPIEncodeContext   *ctx = avctx->priv_data;
> -VAAPIEncodeMPEG2Context *priv = ctx->priv_data;
> +VAAPIEncodeMPEG2Context *priv = avctx->priv_data;
>  CodedBitstreamFragment  *frag = >current_fragment;
>  int err;
>  
> @@ -140,8 +142,7 @@ static int
> vaapi_encode_mpeg2_write_picture_header(AVCodecContext *avctx,
> VAAPIEncodePicture *pic,
> char *data, size_t
> *data_len)
>  {
> -VAAPIEncodeContext   *ctx = avctx->priv_data;
> -VAAPIEncodeMPEG2Context *priv = ctx->priv_data;
> +VAAPIEncodeMPEG2Context *priv = avctx->priv_data;
>  CodedBitstreamFragment  *frag = >current_fragment;
>  int err;
>  
> @@ -164,7 +165,7 @@ fail:
>  static int vaapi_encode_mpeg2_init_sequence_params(AVCodecContext *avctx)
>  {
>  VAAPIEncodeContext *ctx = avctx->priv_data;
> -VAAPIEncodeMPEG2Context   *priv = ctx->priv_data;
> +VAAPIEncodeMPEG2Context   *priv = avctx->priv_data;
>  MPEG2RawSequenceHeader  *sh = >sequence_header;
>  MPEG2RawSequenceExtension   *se = 
> >sequence_extension.data.sequence;
>  MPEG2RawSequenceDisplayExtension   *sde = 
> >sequence_display_extension.data.sequence_display;
> @@ -416,8 +417,7 @@ static int
> vaapi_encode_mpeg2_init_sequence_params(AVCodecContext *avctx)
>  static int vaapi_encode_mpeg2_init_picture_params(AVCodecContext *avctx,
>   VAAPIEncodePicture *pic)
>  {
> -VAAPIEncodeContext*ctx = avctx->priv_data;
> -VAAPIEncodeMPEG2Context  *priv = ctx->priv_data;
> +VAAPIEncodeMPEG2Context  *priv = avctx->priv_data;
>  MPEG2RawPictureHeader  *ph = >picture_header;
>  MPEG2RawPictureCodingExtension*pce = 
> >picture_coding_extension.data.picture_coding;
>  VAEncPictureParameterBufferMPEG2 *vpic = 

Re: [FFmpeg-devel] [PATCH 02/26] vaapi_encode_h265: Move options and common structures into context

[Xiang, Haihao]

> Matching previous commit for H.264.
> ---
>  libavcodec/vaapi_encode_h265.c | 114 +++-
> -
>  1 file changed, 54 insertions(+), 60 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 5203c6871d..ba6b426eed 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -35,6 +35,15 @@
>  
>  
>  typedef struct VAAPIEncodeH265Context {
> +VAAPIEncodeContext common;
> +
> +// User options.
> +int qp;
> +int aud;
> +int profile;
> +int level;
> +
> +// Derived settings.
>  unsigned int ctu_width;
>  unsigned int ctu_height;
>  
> @@ -42,12 +51,7 @@ typedef struct VAAPIEncodeH265Context {
>  int fixed_qp_p;
>  int fixed_qp_b;
>  
> -H265RawAUD aud;
> -H265RawVPS vps;
> -H265RawSPS sps;
> -H265RawPPS pps;
> -H265RawSlice slice;
> -
> +// Stream state.
>  int64_t last_idr_frame;
>  int pic_order_cnt;
>  
> @@ -55,25 +59,24 @@ typedef struct VAAPIEncodeH265Context {
>  int slice_type;
>  int pic_type;
>  
> +// Writer structures.
> +H265RawAUD   raw_aud;
> +H265RawVPS   raw_vps;
> +H265RawSPS   raw_sps;
> +H265RawPPS   raw_pps;
> +H265RawSlice raw_slice;
> +
>  CodedBitstreamContext *cbc;
>  CodedBitstreamFragment current_access_unit;
>  int aud_needed;
>  } VAAPIEncodeH265Context;
>  
> -typedef struct VAAPIEncodeH265Options {
> -int qp;
> -int aud;
> -int profile;
> -int level;
> -} VAAPIEncodeH265Options;
> -
>  
>  static int vaapi_encode_h265_write_access_unit(AVCodecContext *avctx,
> char *data, size_t *data_len,
> CodedBitstreamFragment *au)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH265Context *priv = ctx->priv_data;
> +VAAPIEncodeH265Context *priv = avctx->priv_data;
>  int err;
>  
>  err = ff_cbs_write_fragment_data(priv->cbc, au);
> @@ -99,8 +102,7 @@ static int vaapi_encode_h265_add_nal(AVCodecContext *avctx,
>   CodedBitstreamFragment *au,
>   void *nal_unit)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH265Context *priv = ctx->priv_data;
> +VAAPIEncodeH265Context *priv = avctx->priv_data;
>  H265RawNALUnitHeader *header = nal_unit;
>  int err;
>  
> @@ -118,27 +120,26 @@ static int vaapi_encode_h265_add_nal(AVCodecContext
> *avctx,
>  static int vaapi_encode_h265_write_sequence_header(AVCodecContext *avctx,
> char *data, size_t
> *data_len)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH265Context *priv = ctx->priv_data;
> +VAAPIEncodeH265Context *priv = avctx->priv_data;
>  CodedBitstreamFragment   *au = >current_access_unit;
>  int err;
>  
>  if (priv->aud_needed) {
> -err = vaapi_encode_h265_add_nal(avctx, au, >aud);
> +err = vaapi_encode_h265_add_nal(avctx, au, >raw_aud);
>  if (err < 0)
>  goto fail;
>  priv->aud_needed = 0;
>  }
>  
> -err = vaapi_encode_h265_add_nal(avctx, au, >vps);
> +err = vaapi_encode_h265_add_nal(avctx, au, >raw_vps);
>  if (err < 0)
>  goto fail;
>  
> -err = vaapi_encode_h265_add_nal(avctx, au, >sps);
> +err = vaapi_encode_h265_add_nal(avctx, au, >raw_sps);
>  if (err < 0)
>  goto fail;
>  
> -err = vaapi_encode_h265_add_nal(avctx, au, >pps);
> +err = vaapi_encode_h265_add_nal(avctx, au, >raw_pps);
>  if (err < 0)
>  goto fail;
>  
> @@ -153,19 +154,18 @@ static int
> vaapi_encode_h265_write_slice_header(AVCodecContext *avctx,
>  VAAPIEncodeSlice *slice,
>  char *data, size_t *data_len)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH265Context *priv = ctx->priv_data;
> +VAAPIEncodeH265Context *priv = avctx->priv_data;
>  CodedBitstreamFragment   *au = >current_access_unit;
>  int err;
>  
>  if (priv->aud_needed) {
> -err = vaapi_encode_h265_add_nal(avctx, au, >aud);
> +err = vaapi_encode_h265_add_nal(avctx, au, >raw_aud);
>  if (err < 0)
>  goto fail;
>  priv->aud_needed = 0;
>  }
>  
> -err = vaapi_encode_h265_add_nal(avctx, au, >slice);
> +err = vaapi_encode_h265_add_nal(avctx, au, >raw_slice);
>  if (err < 0)
>  goto fail;
>  
> @@ -178,10 +178,10 @@ fail:
>  static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>  {
>  VAAPIEncodeContext*ctx = avctx->priv_data;
> -VAAPIEncodeH265Context   *priv = ctx->priv_data;
> -H265RawVPS*vps = >vps;
> -H265RawSPS   

Re: [FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious initialisations

[Alexander Kravchenko]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Rostislav Pehlivanov
> Sent: Tuesday, April 24, 2018 4:04 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious 
> initialisations
> 
> On 24 April 2018 at 12:29, Alexander Kravchenko 
> wrote:
> 
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > Of Mark Thompson
> > > Sent: Sunday, April 22, 2018 6:37 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious
> > initialisations
> > >
> > > On 15/04/18 20:45, Alexander Kravchenko wrote:
> > > >> -Original Message-
> > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > >> Behalf Of Mark Thompson
> > > >> Sent: Sunday, April 15, 2018 7:31 PM
> > > >> To: ffmpeg-devel@ffmpeg.org
> > > >> Subject: Re: [FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious
> > > >> initialisations
> > > >>
> > > >>
> > > >>> I am waiting patches to be applied to propose new patch with
> > hwcontext_amf in libavutil.
> > > >>
> > > >> Can you explain what you're intending to use that for?  It's not
> > > >> clear to me how an extra wrapper around the D3D(9|11) surfaces is
> > > >> going to help, given that the support for them with AMF is
> > > >> already pretty good.  (Compare the Intel libmfx stuff (the
> > > >> misleadingly- named "qsv") where the extra wrapping does help for
> > > >> some cases because the underlying library has weird constraints,
> > > >> but overall adds a lot of complexity (and failure modes) for
> > > >> rather unclear benefit.  It's also inconvenient in that it
> > > >> promotes the existence of antifeatures like the "_qsv" decoders
> > > >> which are inferior to the builtin hwaccels in pretty much every
> > > >> respect.)
> > > >>
> > > >
> > > > Hi Mark,
> > > > I am intending to create amf common helpers(tools) in libavutil.
> > > > They will be used in amfenc and vf_scaleamf. (vf_scaleamf is
> > > > hw-accelerated color-space converter and scaler)
> > > >
> > > > amf helpers should provide:
> > > > * amf_library: functions to load/unload amf dll based on reference
> > > > count mechanism
> > > > * amf_context: functions to create AMFContext derived from DXVA2,
> > > > D3D11, opencl and Vulcan in future
> > > > * av_frame <-> AMFSurface map functions (move from amfenc.c)
> > > >
> > > > amfav_context can be implemented like hwdevice_ctx
> > > > (AVAMFDeviceContext) and can be managed by
> > > > av_hwdevice_ctx_create_derived (in case of incoming hw frames) and
> > > > av_hwdevice_ctx_create or it can be implemented not using of
> > > > av_hwdevice_ctx* mechanism
> > > >
> > > > I think don’t need AVAMFFrameContext, and amf components will
> > > > send/receive hwframes based on existing framecontexts
> > > > (dxva/opencl...)
> > > >
> > > > Could you recommend the best way how to do this fit in current
> > architecture?
> > >
> > > I agree that using a hwdevice context here makes sense, since it
> > > wraps
> > all of the right properties (in particular, derivation from other
> > > devices).
> > >
> > > It's less clear to me what to do with the frames.  A hwframes
> > > context
> > could work just for derivation because you don't actually need to
> > > implement the allocation stuff (the existing DRM hwcontext does
> > > this,
> > since it's only for interop).  What other approach would you
> > > think of taking?  Adding special external API to use internally
> > > between
> > libraries is not nice and we try to avoid it quite strongly.
> > >
> >
> > Hi Mark,
> > I agree it is good to stay within current API (hwdevice and hwframes),
> > but I am not sure it is always possible.
> >
> > is it ok create hwcontext_amf_internal.h which can be placeholder for
> > the API like the following, or probably some helper functions can be
> > published as pointers in AVAMFDeviceContext structure:
> > amf_set_property_buffer
> > amf_get_property_buffer
> > amf_create_buffer_with_frame_ref
> > amf_release_buffer_with_frame_ref
> >
> 
> No, I think there should be no avpriv functions for hwcontexts, nor any 
> public API changes. Better duplicate that code in lavfi.

Ok, if avutil is not proper place to put shared code between libavcodec and 
libavfilter, may be there should be another place?
Duplicating code will increase cost of maintenance, which is not good. 
Probably there should be some other place to put shared code?
May be shared code can be just set of static functions and macroses are put in 
headers?

Thanks,
Alexander






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

Re: [FFmpeg-devel] [PATCH 01/26] vaapi_encode_h264: Move options and common structures into context

[Xiang, Haihao]

> This will make it easier to support options in common between different
> encoders.  It also cleans up some of the field naming.
> ---
>  libavcodec/vaapi_encode_h264.c | 228 +---
> -
>  1 file changed, 115 insertions(+), 113 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 56ad217b4a..cc163151a6 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -47,6 +47,19 @@ static const uint8_t
> vaapi_encode_h264_sei_identifier_uuid[16] = {
>  };
>  
>  typedef struct VAAPIEncodeH264Context {
> +VAAPIEncodeContext common;
> +
> +// User options.
> +int qp;
> +int quality;
> +int low_power;
> +int coder;
> +int aud;
> +int sei;
> +int profile;
> +int level;
> +
> +// Derived settings.
>  int mb_width;
>  int mb_height;
>  
> @@ -54,18 +67,7 @@ typedef struct VAAPIEncodeH264Context {
>  int fixed_qp_p;
>  int fixed_qp_b;
>  
> -H264RawAUD aud;
> -H264RawSPS sps;
> -H264RawPPS pps;
> -H264RawSEI sei;
> -H264RawSlice slice;
> -
> -H264RawSEIBufferingPeriod buffering_period;
> -H264RawSEIPicTiming pic_timing;
> -H264RawSEIRecoveryPoint recovery_point;
> -H264RawSEIUserDataUnregistered identifier;
> -char *identifier_string;
> -
> +// Stream state.
>  int frame_num;
>  int pic_order_cnt;
>  int next_frame_num;
> @@ -78,32 +80,33 @@ typedef struct VAAPIEncodeH264Context {
>  int cpb_delay;
>  int dpb_delay;
>  
> +// Writer structures.
>  CodedBitstreamContext *cbc;
>  CodedBitstreamFragment current_access_unit;
> +
> +H264RawAUD   raw_aud;
> +H264RawSPS   raw_sps;
> +H264RawPPS   raw_pps;
> +H264RawSEI   raw_sei;
> +H264RawSlice raw_slice;
> +
> +H264RawSEIBufferingPeriod  sei_buffering_period;
> +H264RawSEIPicTimingsei_pic_timing;
> +H264RawSEIRecoveryPointsei_recovery_point;
> +H264RawSEIUserDataUnregistered sei_identifier;
> +char  *sei_identifier_string;
> +
>  int aud_needed;
>  int sei_needed;
>  int sei_cbr_workaround_needed;
>  } VAAPIEncodeH264Context;
>  
> -typedef struct VAAPIEncodeH264Options {
> -int qp;
> -int quality;
> -int low_power;
> -// Entropy encoder type.
> -int coder;
> -int aud;
> -int sei;
> -int profile;
> -int level;
> -} VAAPIEncodeH264Options;
> -
>  
>  static int vaapi_encode_h264_write_access_unit(AVCodecContext *avctx,
> char *data, size_t *data_len,
> CodedBitstreamFragment *au)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH264Context *priv = ctx->priv_data;
> +VAAPIEncodeH264Context *priv = avctx->priv_data;
>  int err;
>  
>  err = ff_cbs_write_fragment_data(priv->cbc, au);
> @@ -129,8 +132,7 @@ static int vaapi_encode_h264_add_nal(AVCodecContext
> *avctx,
>   CodedBitstreamFragment *au,
>   void *nal_unit)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH264Context *priv = ctx->priv_data;
> +VAAPIEncodeH264Context *priv = avctx->priv_data;
>  H264RawNALUnitHeader *header = nal_unit;
>  int err;
>  
> @@ -148,23 +150,22 @@ static int vaapi_encode_h264_add_nal(AVCodecContext
> *avctx,
>  static int vaapi_encode_h264_write_sequence_header(AVCodecContext *avctx,
> char *data, size_t
> *data_len)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH264Context *priv = ctx->priv_data;
> +VAAPIEncodeH264Context *priv = avctx->priv_data;
>  CodedBitstreamFragment   *au = >current_access_unit;
>  int err;
>  
>  if (priv->aud_needed) {
> -err = vaapi_encode_h264_add_nal(avctx, au, >aud);
> +err = vaapi_encode_h264_add_nal(avctx, au, >raw_aud);
>  if (err < 0)
>  goto fail;
>  priv->aud_needed = 0;
>  }
>  
> -err = vaapi_encode_h264_add_nal(avctx, au, >sps);
> +err = vaapi_encode_h264_add_nal(avctx, au, >raw_sps);
>  if (err < 0)
>  goto fail;
>  
> -err = vaapi_encode_h264_add_nal(avctx, au, >pps);
> +err = vaapi_encode_h264_add_nal(avctx, au, >raw_pps);
>  if (err < 0)
>  goto fail;
>  
> @@ -179,19 +180,18 @@ static int
> vaapi_encode_h264_write_slice_header(AVCodecContext *avctx,
>  VAAPIEncodeSlice *slice,
>  char *data, size_t *data_len)
>  {
> -VAAPIEncodeContext  *ctx = avctx->priv_data;
> -VAAPIEncodeH264Context *priv = ctx->priv_data;
> +VAAPIEncodeH264Context *priv = avctx->priv_data;
>  CodedBitstreamFragment   *au = >current_access_unit;
> 

Re: [FFmpeg-devel] avformat/mpegts: set AV_DISPOSITION_DESCRIPTIONS for OIPF cases

[Łukasz Krzciuk]

Yes, I have checked it and I implemented it according to OIPF spec: 8.4.2
AVComponent, audioDescription case (as I wrote in my 1st email). This
implementation is tested by official org.hbbtv_HTML50420 testcase.

Regards,

*Łukasz Krzciuk*
Developer

Vewd
ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska


On Wed, Apr 25, 2018 at 2:09 AM, Michael Niedermayer  wrote:

> On Tue, Apr 24, 2018 at 10:36:50AM +0200, Łukasz Krzciuk wrote:
> > Any updates on this?
>
> did you base this on teh specification / have checked that it matches
> the specification ?
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> 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