Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning

2017-11-16 Thread Li, Zhong
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Carl Eugen Hoyos
> > Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling
> > warning
> >
> > 2017-11-15 10:04 GMT+01:00 Zhong Li :
> > > fix the compiling warning of "ignoring return value"
> >
> > > -ff_formats_ref(in_fmts, >inputs[0]->out_formats);
> > > -ff_formats_ref(out_fmts, >outputs[0]->in_formats);
> > > +if ((ret = ff_formats_ref(in_fmts, >inputs[0]->out_formats)) <
> 0)
> > > +return ret;
> > > +if ((ret = ff_formats_ref(out_fmts,
> > > + >outputs[0]->in_formats)) <
> > 0)
> >
> > Two additional lines are cheap.
> 
> Just don't like any compiling warnings which may have potential issues just
> like this one.
> Personally speaking, I prefer to clear most of FFmpeg compiling warnings.

Sorry, I may misunderstood due to miss some history discussion, here you mean 
should be coding style making code clearer, right? Just like this:
"ret = ff_formats_ref();
 if (ret < 0) return ret;"
Please correct me if I am wrong.

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


Re: [FFmpeg-devel] FFmpeg 3.4.1

2017-11-16 Thread Michael Niedermayer
On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> >> > Hi all
> >> >
> >> > I intend to make 3.4.1 very soon
> >>
> >> Shouldn't we first decide on how to proceed with #6775?
> >
> > This would be ideal.
> >
> > IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04
> 
> This was confirmed by more than one developer, yes.
> 
> > I see a patch that is said to improve 6775, can that be applied and
> > would that resolve this ?
> 
> Iiuc, it would not completely resolve the issue, see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> 
> > If so why was it not applied yet ?
> 
> The patch did not get support here, see:
> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> in compat_decode


Is someone working on fixing this better than with the available patch ?

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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


Re: [FFmpeg-devel] [PATCH 5/6] Add suppoort for using libklvanc from within decklink capture module

2017-11-16 Thread James Almer
On 11/16/2017 3:34 PM, Devin Heitmueller wrote:
> Make use of libklvanc from within the decklink capture module,
> initially for EIA-708 and AFD.  Support for other VANC types will
> come in subsequent patches.
> 
> Signed-off-by: Devin Heitmueller 
> ---
>  libavdevice/decklink_dec.cpp | 135 
> +++
>  1 file changed, 135 insertions(+)
> 
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 11b7e60..bea9213 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -3,6 +3,7 @@
>   * Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
>   * Copyright (c) 2014 Rafaël Carré
>   * Copyright (c) 2017 Akamai Technologies, Inc.
> + * Copyright (c) 2017 LTN Global Communications, Inc.
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -669,10 +670,128 @@ error:
>  return ret;
>  }
>  
> +#if CONFIG_LIBKLVANC
> +/* VANC Callbacks */
> +struct vanc_cb_ctx {
> +AVFormatContext *avctx;
> +AVPacket *pkt;
> +};
> +static int cb_AFD(void *callback_context, struct klvanc_context_s *ctx,
> +  struct klvanc_packet_afd_s *pkt)
> +{
> +struct vanc_cb_ctx *cb_ctx = (struct vanc_cb_ctx *)callback_context;
> +uint8_t *afd;
> +
> +afd = (uint8_t *)av_malloc(1);
> +if (afd == NULL)
> +return AVERROR(ENOMEM);
> +
> +afd[0] = pkt->hdr.payload[0] >> 3;
> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, afd, 1) < 0)
> +av_free(afd);

For this, av_packet_new_side_data() seems more adequate than av_malloc()
+ av_packet_add_side_data().

Also, you should propagate the errors av_packet_{add,new}_side_data return.

> +
> +return 0;
> +}
> +
> +static int cb_EIA_708B(void *callback_context, struct klvanc_context_s *ctx,
> +   struct klvanc_packet_eia_708b_s *pkt)
> +{
> +struct vanc_cb_ctx *cb_ctx = (struct vanc_cb_ctx *)callback_context;
> +decklink_cctx *cctx = (struct decklink_cctx *)cb_ctx->avctx->priv_data;
> +struct decklink_ctx *decklink_ctx = (struct decklink_ctx *)cctx->ctx;
> +
> +uint16_t expected_cdp;
> +uint8_t *cc;
> +
> +if (!pkt->checksum_valid)
> +return 0;
> +
> +if (!pkt->header.ccdata_present)
> +return 0;
> +
> +expected_cdp = decklink_ctx->cdp_sequence_num + 1;
> +decklink_ctx->cdp_sequence_num = pkt->header.cdp_hdr_sequence_cntr;
> +if (pkt->header.cdp_hdr_sequence_cntr != expected_cdp) {
> +av_log(cb_ctx->avctx, AV_LOG_DEBUG,
> +   "CDP counter inconsistent.  Received=0x%04x Expected=%04x\n",
> +   pkt->header.cdp_hdr_sequence_cntr, expected_cdp);
> +return 0;
> +}
> +
> +cc = (uint8_t *)av_malloc(pkt->ccdata.cc_count * 3);
> +if (cc == NULL)
> +return AVERROR(ENOMEM);
> +
> +for (int i = 0; i < pkt->ccdata.cc_count; i++) {
> +cc[3*i] = 0xf8 | (pkt->ccdata.cc[i].cc_valid ? 0x04 : 0x00) |
> +  (pkt->ccdata.cc[i].cc_type & 0x03);
> +cc[3*i+1] = pkt->ccdata.cc[i].cc_data[0];
> +cc[3*i+2] = pkt->ccdata.cc[i].cc_data[1];
> +}
> +
> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_A53_CC, cc, 
> pkt->ccdata.cc_count * 3) < 0)
> +av_free(cc);

Same as above.

> +
> +return 0;
> +}
> +
> +static struct klvanc_callbacks_s callbacks =
> +{
> +.afd   = cb_AFD,
> +.eia_708b  = cb_EIA_708B,
> +.eia_608   = NULL,
> +.scte_104  = NULL,
> +.all   = NULL,
> +.kl_i64le_counter  = NULL,
> +};
> +/* End: VANC Callbacks */
> +
> +/* Take one line of V210 from VANC, colorspace convert and feed it to the
> + * VANC parser. We'll expect our VANC message callbacks to happen on this
> + * same calling thread.
> + */
> +static void klvanc_handle_line(AVFormatContext *avctx, struct 
> klvanc_context_s *vanc_ctx,
> +   unsigned char *buf, unsigned int uiWidth, 
> unsigned int lineNr,
> +   AVPacket *pkt)
> +{
> +/* Convert the vanc line from V210 to CrCB422, then vanc parse it */
> +
> +/* We need two kinds of type pointers into the source vbi buffer */
> +/* TODO: What the hell is this, two ptrs? */
> +const uint32_t *src = (const uint32_t *)buf;
> +
> +/* Convert Blackmagic pixel format to nv20.
> + * src pointer gets mangled during conversion, hence we need its own
> + * ptr instead of passing vbiBufferPtr.
> + * decoded_words should be atleast 2 * uiWidth.
> + */
> +uint16_t decoded_words[16384];
> +
> +/* On output each pixel will be decomposed into three 16-bit words (one 
> for Y, U, V) */
> +memset(_words[0], 0, sizeof(decoded_words));
> +uint16_t *p_anc = decoded_words;
> +if (klvanc_v210_line_to_nv20_c(src, p_anc, sizeof(decoded_words), 
> (uiWidth / 6) * 6) < 0)
> +return;
> +
> +if (vanc_ctx) {
> +struct vanc_cb_ctx cb_ctx = {
> 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread James Almer
On 11/16/2017 10:43 PM, Michael Niedermayer wrote:
> On Thu, Nov 16, 2017 at 07:47:55PM -0500, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, Nov 16, 2017 at 4:41 PM, Michael Niedermayer >> wrote:
>>
>>> On Thu, Nov 16, 2017 at 01:21:19PM -0500, Ronald S. Bultje wrote:
 Hi,

 On Thu, Nov 16, 2017 at 11:50 AM, Michael Niedermayer <
 mich...@niedermayer.cc> wrote:

> On Thu, Nov 16, 2017 at 06:26:06AM -0500, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos <
>>> ceffm...@gmail.com>
>> wrote:
>>
>>> 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
>>>
 So, commit it without the error message? I really don't see the
> issue.
>>>
>>> As explained, the issue is that without an error message, it
>>> is impossible to parse any related bug report.
>>
>>
>> We've been OK with that situation so far. Since it only happens for
> fuzzed
>> files, it's OK to continue going like that.
>
> Thats not the case, the snow spec contains no limit in the place where
> we need to check. Its a natural and expected limit so likely all files
> will be within that but a file outside would still be arguably valid.
>
> So a valid file could potentially be outside this range and the
> maintainer (that being me) need to know about this.
>
> Please dont see every change that originated from a fuzzer generated
> report as only related to fuzzed files.


 We are re-hashing old arguments here. I'm not really interested in that.
>>>

 My review comment is and remains: please remove the log msg. Otherwise,
>>> the
 patch is perfectly fine.
>>>
>>> Thank you for your review comment.
>>>
>>> please awnser my question, if this is just a suggestion or a
>>> veto, so we can move forward. Its not clear from your wording to me
>>> if you belive you have authority over other maintainers or not.
>>
>>
>> I'm sorry, what? Authority? Are you kidding me? Amend the patch, stop being
>> difficult. This whole discussion is ridiculous. I thought you were on a
>> deadline for a remote root code execution exploit or something?
> 
> The patch should be commited theres no question about this.
> Why should i amend it and remove the error message which help me to
> maintain the code ?
> 
> Do you realize how ridiculous your request is ?
> This is code i wrote, code i maintain, you dont work on this code
> or have anything to do with it. And these error messages help me
> maintain the code.
> 
> I think you should relax a bit and jump over your shadow and let me
> maintain my code instead of threads like this.
> 
> ill remove the messages so this gets resolved but its harder to maintain
> this way so this means fewer usefull contributions from me and lower
> code quality.
> I dont think thats the ideal outcome ...
> 
> Thanks

Use ff_dlog() for the log message. It'll still be enabled on debug
builds but not on release builds. Ronald said he's ok with it for this
case on IRC.

Unless this was suggested before and the idea discarded/rejected for
some reason...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Michael Niedermayer
On Thu, Nov 16, 2017 at 07:47:55PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Nov 16, 2017 at 4:41 PM, Michael Niedermayer  > wrote:
> 
> > On Thu, Nov 16, 2017 at 01:21:19PM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Thu, Nov 16, 2017 at 11:50 AM, Michael Niedermayer <
> > > mich...@niedermayer.cc> wrote:
> > >
> > > > On Thu, Nov 16, 2017 at 06:26:06AM -0500, Ronald S. Bultje wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos <
> > ceffm...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
> > > > > >
> > > > > > > So, commit it without the error message? I really don't see the
> > > > issue.
> > > > > >
> > > > > > As explained, the issue is that without an error message, it
> > > > > > is impossible to parse any related bug report.
> > > > >
> > > > >
> > > > > We've been OK with that situation so far. Since it only happens for
> > > > fuzzed
> > > > > files, it's OK to continue going like that.
> > > >
> > > > Thats not the case, the snow spec contains no limit in the place where
> > > > we need to check. Its a natural and expected limit so likely all files
> > > > will be within that but a file outside would still be arguably valid.
> > > >
> > > > So a valid file could potentially be outside this range and the
> > > > maintainer (that being me) need to know about this.
> > > >
> > > > Please dont see every change that originated from a fuzzer generated
> > > > report as only related to fuzzed files.
> > >
> > >
> > > We are re-hashing old arguments here. I'm not really interested in that.
> >
> > >
> > > My review comment is and remains: please remove the log msg. Otherwise,
> > the
> > > patch is perfectly fine.
> >
> > Thank you for your review comment.
> >
> > please awnser my question, if this is just a suggestion or a
> > veto, so we can move forward. Its not clear from your wording to me
> > if you belive you have authority over other maintainers or not.
> 
> 
> I'm sorry, what? Authority? Are you kidding me? Amend the patch, stop being
> difficult. This whole discussion is ridiculous. I thought you were on a
> deadline for a remote root code execution exploit or something?

The patch should be commited theres no question about this.
Why should i amend it and remove the error message which help me to
maintain the code ?

Do you realize how ridiculous your request is ?
This is code i wrote, code i maintain, you dont work on this code
or have anything to do with it. And these error messages help me
maintain the code.

I think you should relax a bit and jump over your shadow and let me
maintain my code instead of threads like this.

ill remove the messages so this gets resolved but its harder to maintain
this way so this means fewer usefull contributions from me and lower
code quality.
I dont think thats the ideal outcome ...

Thanks

[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] ffmpeg_filter: use nb_threads=1 on unused filtergraph

2017-11-16 Thread DeHackEd
Hello,

Simple one-line patch to avoid creating threads on a filtergrpah which does not
get used during execution. This saves a superfluous thread creation and
tear-down cycle.

Besides cleanliness, the main driver for this feature is a system I have access
to with a large number of cores/threads. Threads count towards ulimits and the
default of 1 filtergraph thread per CPU thread is undesirable.
>From 999a38ae38178c2ab3ba8a9ef116e7ec08474302 Mon Sep 17 00:00:00 2001
From: DHE 
Date: Thu, 16 Nov 2017 20:09:37 -0500
Subject: [PATCH] ffmpeg_filter: use nb_threads=1 on unused filtergraph

Signed-off-by: DHE 
---
 fftools/ffmpeg_filter.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index aacc185..877fd67 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -340,6 +340,7 @@ int init_complex_filtergraph(FilterGraph *fg)
 graph = avfilter_graph_alloc();
 if (!graph)
 return AVERROR(ENOMEM);
+graph->nb_threads = 1;
 
 ret = avfilter_graph_parse2(graph, fg->graph_desc, , );
 if (ret < 0)
-- 
2.9.5

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


Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

2017-11-16 Thread Colin NG
Excluded the fix for byte range issue and update some coding style issues.


From: Colin NG 
Sent: November 15, 2017 10:58 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)


Have submitted already for the byte range issue in another email with title 
"Download dash content with byte range info"



From: ffmpeg-devel  on behalf of Carl Eugen 
Hoyos 
Sent: November 15, 2017 10:54 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

2017-11-15 3:54 GMT+01:00 Colin NG :
> - Add a function to handle the base URL Processing described in section 5.6.5 
> of IEC_23009-1.
>
> - Fix for downloading dash content with byte range info

As said: If these are two separate issues, please send two patches.

Use tools/patcheck to check your patch for many style issues.
(No Changelog entry necessary.)

Try to avoid if ((var1 = var2) > 1), instead add an additional line.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...



diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..4d89374 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -148,6 +148,11 @@ static uint64_t get_current_time_in_sec(void)
 return  av_gettime() / 100;
 }
 
+static char * ishttp(char *url) {
+char *proto_name = avio_find_protocol_name(url);
+return av_strstart(proto_name, "http", NULL);
+}
+
 static uint64_t get_utc_date_time_insec(AVFormatContext *s, const char 
*datetime)
 {
 struct tm timeinfo;
@@ -392,7 +397,10 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
 return AVERROR_INVALIDDATA;
 
-ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
+if (pb) av_freep(pb);
+   // set_httpheader_options(c, );
+ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, );
+
 if (ret >= 0) {
 // update cookies on http response with setcookies.
 char *new_cookies = NULL;
@@ -613,6 +621,77 @@ static int parse_manifest_segmenttimeline(AVFormatContext 
*s, struct representat
 return 0;
 }
 
+
+static int resolve_content_path(AVFormatContext *s, const char *url,  
xmlNodePtr *baseurl_nodes,  int n_baseurl_nodes) {
+
+int i;
+char *text;
+char tmp_str[MAX_URL_SIZE];
+char tmp_str_2[MAX_URL_SIZE];
+
+char *path = av_mallocz(MAX_URL_SIZE);
+int nameSize = 0;
+int updated = 0;
+
+av_strlcpy(tmp_str, url, strlen(url)+1);
+char *mpdName = strtok (tmp_str," /");
+
+while ((mpdName =strtok (NULL, "/"))) {
+nameSize = strlen(mpdName);
+}
+
+av_strlcpy (path, url, strlen(url)-nameSize+1 );
+
+int rootId = 0;
+xmlNodePtr  *node = NULL;
+char *proto_name = NULL;
+for (rootId = n_baseurl_nodes-1; rootId >0; rootId--)  {
+if (!(node = baseurl_nodes[rootId])) continue;
+
+   if (ishttp(xmlNodeGetContent(node)))  {
+break;
+}
+}
+
+node = baseurl_nodes[rootId];
+char *baseurl = xmlNodeGetContent(node);
+char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
+
+if (node)  {
+xmlNodeSetContent(node, root_url);
+}
+
+int size = strlen(root_url);
+char *isRootHttp= ishttp(root_url);
+
+char token ='/';
+if (strncmp(_url[size-1],, 1) != 0) {
+av_strlcat(root_url, "/", size+2);
+size+=2;
+}
+
+for (i = 0; i < n_baseurl_nodes; ++i)  {
+if (i==rootId) continue;
+text = xmlNodeGetContent(baseurl_nodes[i]);
+if (text) {
+memset(tmp_str, 0, sizeof(tmp_str));
+
+if (!ishttp(text) && isRootHttp)  {
+av_strlcpy(tmp_str, root_url, size+1);
+}
+int start = (strncmp(text, , 1) == 0) ? 1: 0;
+memset(tmp_str_2, 0, sizeof(tmp_str_2));
+av_strlcat(tmp_str, text+start, MAX_URL_SIZE);
+xmlFree(text);
+xmlNodeSetContent(baseurl_nodes[i], tmp_str);
+updated = 1;
+}
+}
+
+av_free(path);
+return updated;
+
+}
 static int parse_manifest_representation(AVFormatContext *s, const char *url,
  xmlNodePtr node,
  xmlNodePtr adaptionset_node,
@@ -672,6 +751,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Ronald S. Bultje
Hi,

On Thu, Nov 16, 2017 at 4:41 PM, Michael Niedermayer  wrote:

> On Thu, Nov 16, 2017 at 01:21:19PM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Nov 16, 2017 at 11:50 AM, Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> >
> > > On Thu, Nov 16, 2017 at 06:26:06AM -0500, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos <
> ceffm...@gmail.com>
> > > > wrote:
> > > >
> > > > > 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
> > > > >
> > > > > > So, commit it without the error message? I really don't see the
> > > issue.
> > > > >
> > > > > As explained, the issue is that without an error message, it
> > > > > is impossible to parse any related bug report.
> > > >
> > > >
> > > > We've been OK with that situation so far. Since it only happens for
> > > fuzzed
> > > > files, it's OK to continue going like that.
> > >
> > > Thats not the case, the snow spec contains no limit in the place where
> > > we need to check. Its a natural and expected limit so likely all files
> > > will be within that but a file outside would still be arguably valid.
> > >
> > > So a valid file could potentially be outside this range and the
> > > maintainer (that being me) need to know about this.
> > >
> > > Please dont see every change that originated from a fuzzer generated
> > > report as only related to fuzzed files.
> >
> >
> > We are re-hashing old arguments here. I'm not really interested in that.
>
> >
> > My review comment is and remains: please remove the log msg. Otherwise,
> the
> > patch is perfectly fine.
>
> Thank you for your review comment.
>
> please awnser my question, if this is just a suggestion or a
> veto, so we can move forward. Its not clear from your wording to me
> if you belive you have authority over other maintainers or not.


I'm sorry, what? Authority? Are you kidding me? Amend the patch, stop being
difficult. This whole discussion is ridiculous. I thought you were on a
deadline for a remote root code execution exploit or something?

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


Re: [FFmpeg-devel] [PATCH 2/6] decklink: Introduce support for capture of multiple audio streams

2017-11-16 Thread Derek Buitenhuis
On 11/17/2017 12:32 AM, Devin Heitmueller wrote:
> I don’t have strong feelings either way.  I’m happy to jam this into a 
> subsequent cleanup patch if nobody has an objection (it’s just much easier 
> since I have about 15 commits after this one in my Git tree).

Looks like nobody is bothered, in any case.

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


Re: [FFmpeg-devel] [PATCH 4/6] Support encoding of Active Format Description (AFD) in libx264

2017-11-16 Thread Derek Buitenhuis
On 11/17/2017 12:38 AM, Devin Heitmueller wrote:
> For whatever reason, the spec explicitly calls for the country code to be set 
> to these values.  Here’s the specific language from the spec:
> 
> itu_t_t35_country_code – A fixed 8-bit field, the value of which shall be 
> 0xB5.
> itu_t_35_provider_code – A fixed 16-bit field registered by the ATSC. The 
> value shall be 0x0031.

"Spec says so" is a good enough answer for me.

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


Re: [FFmpeg-devel] [PATCH 6/6] decklink: Add support for SCTE-104 to decklink capture

2017-11-16 Thread Devin Heitmueller

> On Nov 16, 2017, at 7:35 PM, Derek Buitenhuis  
> wrote:
> 
> On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
>> ---
>> libavcodec/avcodec.h|  1 +
>> libavcodec/codec_desc.c |  6 
>> libavdevice/decklink_common.h   |  6 
>> libavdevice/decklink_common_c.h |  1 +
>> libavdevice/decklink_dec.cpp| 64 
>> -
>> libavdevice/decklink_dec_c.c|  1 +
>> 6 files changed, 78 insertions(+), 1 deletion(-)
> 
> Needs a version bump.
> 
>> +static int setup_data(AVFormatContext *avctx)
>> +{
>> +struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
>> +struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
>> +AVStream *st;
>> +int ret = 0;
>> +
>> +if (cctx->enable_scte_104) {
>> +st = avformat_new_stream(avctx, NULL);
>> +if (!st) {
>> +av_log(avctx, AV_LOG_ERROR, "Cannot add data stream\n");
>> +ret = AVERROR(ENOMEM);
>> +goto error;
>> +}
> 
> This is the only error path in the function, so the goto is superfluous.

Yeah, the goto was a product of some refactoring.  I will get rid of it for the 
V2 series.

Thanks,

Devin

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


Re: [FFmpeg-devel] [PATCH 4/6] Support encoding of Active Format Description (AFD) in libx264

2017-11-16 Thread Devin Heitmueller
Hello Derek,

Thanks for taking the time to review these patches.  Comments below.

> On Nov 16, 2017, at 7:20 PM, Derek Buitenhuis  
> wrote:
> 
> On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
> 
>> +/* Active Format Description */
>> +if (x4->afd) {
>> +void *sei_data;
>> +size_t sei_size;
>> +
>> +ret = ff_alloc_afd_sei(frame, 0, _data, _size);
>> +if (ret < 0) {
>> +av_log(ctx, AV_LOG_ERROR, "Not enough memory for AFD, 
>> skipping\n");
>> +} else if (sei_data) {
> 
> In an OOM situation, we always fail hard.

Ok.

> 
>> +x4->pic.extra_sei.payloads = 
>> av_realloc(x4->pic.extra_sei.payloads,
>> +
>> sizeof(x4->pic.extra_sei.payloads[0]) * (num_payloads + 1));
>> +if (x4->pic.extra_sei.payloads == NULL) {
>> +av_log(ctx, AV_LOG_ERROR, "Not enough memory for AFD, 
>> skipping\n");
> 
> This will leak the original x4->pic.extra_sei.payloads on failure, won't it?
> 
> Also, as above, we should fail hard here.

Ok.

> 
>> +/* country code (SCTE 128-1 Sec 8.1.1) */
>> +sei_data[0] = 181;
>> +sei_data[1] = 0;
>> +sei_data[2] = 49;
>> +
>> +/* country code (SCTE 128-1 Sec 8.1.2) */
>> +AV_WL32(sei_data + 3, MKTAG('D', 'T', 'G', '1'));
>> +
>> +/* country code (SCTE 128-1 Sec 8.2.5) */
>> +sei_data[7] = 0x41;
>> +sei_data[8] = 0xf0 | side_data->data[0];
> 
> I assume these values are supposed to always be the same? Excuse my 
> unfamiliarity
> with SCTE-128 - country codes sounds like something you wouldn't want to 
> hardcode.


For whatever reason, the spec explicitly calls for the country code to be set 
to these values.  Here’s the specific language from the spec:

itu_t_t35_country_code – A fixed 8-bit field, the value of which shall be 0xB5.
itu_t_35_provider_code – A fixed 16-bit field registered by the ATSC. The value 
shall be 0x0031.

(Note, the code in question was actually copied from the function directly 
above it which creates the SEI for A53 captions).

All that said, it looks like I did screw up the comments.  The Spec section 
references are correct but for some reason all three say “country code”, which 
is a typo.

I’ll clean up the OOM handling as you requested, as well as fix the comments in 
a V2 patch.

Just an FYI, the spec is freely available here in case you want to know more:

https://www.scte.org/documents/pdf/Standards/ANSI_SCTE%20128-1%202013.pdf 


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


Re: [FFmpeg-devel] [PATCH] avformat/mov: Propagate errors in mov_switch_root.

2017-11-16 Thread Derek Buitenhuis
On 11/17/2017 12:28 AM, Jacob Trimble wrote:
> Signed-off-by: Jacob Trimble 
> ---
>  libavformat/mov.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Looks OK.

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


Re: [FFmpeg-devel] [PATCH 2/6] decklink: Introduce support for capture of multiple audio streams

2017-11-16 Thread James Almer
On 11/16/2017 9:22 PM, Derek Buitenhuis wrote:
> On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
>> +uint8_t *audio_in = ((uint8_t *) audioFrameBytes) + 
>> audio_offset;
>> +for (int x = 0; x < pkt.size; x += sample_size) {
> 
> I realize this is C++, but I'm not sure if we still try to stick
> to our C style (aka no mixed variable decls) in our C++ too.
> 
> Not familiar enough with decklink stuff to review this properly,
> though.
> 
> - Derek

Whatever compiler had issues with mixed code and decl will probably
either have no issues with c++98, or just not support c++ at all.
Also, I see a bunch of for (int ...) lines in decklink sources already,
so IMO no point changing that now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 6/6] decklink: Add support for SCTE-104 to decklink capture

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
> ---
>  libavcodec/avcodec.h|  1 +
>  libavcodec/codec_desc.c |  6 
>  libavdevice/decklink_common.h   |  6 
>  libavdevice/decklink_common_c.h |  1 +
>  libavdevice/decklink_dec.cpp| 64 
> -
>  libavdevice/decklink_dec_c.c|  1 +
>  6 files changed, 78 insertions(+), 1 deletion(-)

Needs a version bump.

> +static int setup_data(AVFormatContext *avctx)
> +{
> +struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
> +struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
> +AVStream *st;
> +int ret = 0;
> +
> +if (cctx->enable_scte_104) {
> +st = avformat_new_stream(avctx, NULL);
> +if (!st) {
> +av_log(avctx, AV_LOG_ERROR, "Cannot add data stream\n");
> +ret = AVERROR(ENOMEM);
> +goto error;
> +}

This is the only error path in the function, so the goto is superfluous.

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


Re: [FFmpeg-devel] [PATCH 2/6] decklink: Introduce support for capture of multiple audio streams

2017-11-16 Thread Devin Heitmueller

> On Nov 16, 2017, at 7:22 PM, Derek Buitenhuis  
> wrote:
> 
> On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
>> +uint8_t *audio_in = ((uint8_t *) audioFrameBytes) + 
>> audio_offset;
>> +for (int x = 0; x < pkt.size; x += sample_size) {
> 
> I realize this is C++, but I'm not sure if we still try to stick
> to our C style (aka no mixed variable decls) in our C++ too.
> 

I don’t have strong feelings either way.  I’m happy to jam this into a 
subsequent cleanup patch if nobody has an objection (it’s just much easier 
since I have about 15 commits after this one in my Git tree).

Devin

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


Re: [FFmpeg-devel] [PATCH 5/6] Add suppoort for using libklvanc from within decklink capture module

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
> Make use of libklvanc from within the decklink capture module,
> initially for EIA-708 and AFD.  Support for other VANC types will
> come in subsequent patches.
> 
> Signed-off-by: Devin Heitmueller 
> ---
>  libavdevice/decklink_dec.cpp | 135 
> +++
>  1 file changed, 135 insertions(+)
> 
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 11b7e60..bea9213 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -3,6 +3,7 @@
>   * Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
>   * Copyright (c) 2014 Rafaël Carré
>   * Copyright (c) 2017 Akamai Technologies, Inc.
> + * Copyright (c) 2017 LTN Global Communications, Inc.
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -669,10 +670,128 @@ error:
>  return ret;
>  }
>  
> +afd[0] = pkt->hdr.payload[0] >> 3;
> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, afd, 1) < 0)
> +av_free(afd);

Is there a reason we shouldn't fail hard here?

> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_A53_CC, cc, 
> pkt->ccdata.cc_count * 3) < 0)
> +av_free(cc);

Ditto here.

> +static struct klvanc_callbacks_s callbacks =
> +{
> +.afd   = cb_AFD,
> +.eia_708b  = cb_EIA_708B,
> +.eia_608   = NULL,
> +.scte_104  = NULL,
> +.all   = NULL,
> +.kl_i64le_counter  = NULL,
> +};

I thought C++ didn't have designated initializers? Maybe my C++ is rusty.

Same for other occurrences.

> +/* Convert the vanc line from V210 to CrCB422, then vanc parse it */
> +
> +/* We need two kinds of type pointers into the source vbi buffer */
> +/* TODO: What the hell is this, two ptrs? */
> +const uint32_t *src = (const uint32_t *)buf;

Is buf guaranteed to be properly aligned for this, or will cause aliasing 
problems?

> +vanc_ctx->callback_context = _ctx;
> +int ret = klvanc_packet_parse(vanc_ctx, lineNr, decoded_words, 
> sizeof(decoded_words) / (sizeof(unsigned short)));

Nobody should be typing 'short' in any C/C++ code in 2017..

> +if (ret < 0) {
> +/* No VANC on this line */
> +}

Huh?

> +#if CONFIG_LIBKLVANC
> +klvanc_handle_line(avctx, ctx->vanc_ctx,
> +   buf, videoFrame->GetWidth(), 
> i, );
> +#else

No error checking possible?

>  }
> +
>  vanc->Release();

Stray change.

> +#if CONFIG_LIBKLVANC
> +if (klvanc_context_create(>vanc_ctx) < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Cannot create VANC library context\n");
> +} else {
> +ctx->vanc_ctx->verbose = 0;
> +ctx->vanc_ctx->callbacks = 
> +}
> +#endif

Should fail hard, no?

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


[FFmpeg-devel] [PATCH] avformat/mov: Propagate errors in mov_switch_root.

2017-11-16 Thread Jacob Trimble
Signed-off-by: Jacob Trimble 
---
 libavformat/mov.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index d49d820d2b..c5f07595df 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6747,6 +6747,7 @@ static int should_retry(AVIOContext *pb, int error_code) {
 
 static int mov_switch_root(AVFormatContext *s, int64_t target, int index)
 {
+int ret;
 MOVContext *mov = s->priv_data;
 
 if (index >= 0 && index < mov->frag_index.nb_items)
@@ -6769,8 +6770,9 @@ static int mov_switch_root(AVFormatContext *s, int64_t 
target, int index)
 
 mov->found_mdat = 0;
 
-if (mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), INT64_MAX }) 
< 0 ||
-avio_feof(s->pb))
+if ((ret = mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), 
INT64_MAX })) < 0)
+return ret;
+if (avio_feof(s->pb))
 return AVERROR_EOF;
 av_log(s, AV_LOG_TRACE, "read fragments, offset 0x%"PRIx64"\n", 
avio_tell(s->pb));
 
-- 
2.15.0.448.gf294e3d99a-goog

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


Re: [FFmpeg-devel] [PATCH 2/6] decklink: Introduce support for capture of multiple audio streams

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
> +uint8_t *audio_in = ((uint8_t *) audioFrameBytes) + 
> audio_offset;
> +for (int x = 0; x < pkt.size; x += sample_size) {

I realize this is C++, but I'm not sure if we still try to stick
to our C style (aka no mixed variable decls) in our C++ too.

Not familiar enough with decklink stuff to review this properly,
though.

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


Re: [FFmpeg-devel] [PATCH 4/6] Support encoding of Active Format Description (AFD) in libx264

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote:

> +/* Active Format Description */
> +if (x4->afd) {
> +void *sei_data;
> +size_t sei_size;
> +
> +ret = ff_alloc_afd_sei(frame, 0, _data, _size);
> +if (ret < 0) {
> +av_log(ctx, AV_LOG_ERROR, "Not enough memory for AFD, 
> skipping\n");
> +} else if (sei_data) {

In an OOM situation, we always fail hard.

> +x4->pic.extra_sei.payloads = 
> av_realloc(x4->pic.extra_sei.payloads,
> +
> sizeof(x4->pic.extra_sei.payloads[0]) * (num_payloads + 1));
> +if (x4->pic.extra_sei.payloads == NULL) {
> +av_log(ctx, AV_LOG_ERROR, "Not enough memory for AFD, 
> skipping\n");

This will leak the original x4->pic.extra_sei.payloads on failure, won't it?

Also, as above, we should fail hard here.

> +/* country code (SCTE 128-1 Sec 8.1.1) */
> +sei_data[0] = 181;
> +sei_data[1] = 0;
> +sei_data[2] = 49;
> +
> +/* country code (SCTE 128-1 Sec 8.1.2) */
> +AV_WL32(sei_data + 3, MKTAG('D', 'T', 'G', '1'));
> +
> +/* country code (SCTE 128-1 Sec 8.2.5) */
> +sei_data[7] = 0x41;
> +sei_data[8] = 0xf0 | side_data->data[0];

I assume these values are supposed to always be the same? Excuse my 
unfamiliarity
with SCTE-128 - country codes sounds like something you wouldn't want to 
hardcode.

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


Re: [FFmpeg-devel] [PATCH 3/6] Preserve AFD side data when going from AVPacket to AVFrame

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
> This is needed to ensure that AFD data continues to work when
> capturing V210 video with the Decklink libavdevice input.
> 
> Signed-off-by: Devin Heitmueller 
> ---
>  libavcodec/decode.c | 1 +
>  1 file changed, 1 insertion(+)

Looks OK.

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


Re: [FFmpeg-devel] [PATCH 1/6] decklink: Fix case where return value wasn't being set before checked for errors

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 6:34 PM, Devin Heitmueller wrote:
> I missed an assignement which cauesd the error case to not ever be properly
> checked.
> 
> Signed-off-by: Devin Heitmueller 
> ---
>  libavdevice/decklink_enc.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM.

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


Re: [FFmpeg-devel] [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410

2017-11-16 Thread Dave Rice

> On Nov 16, 2017, at 6:08 PM, Carl Eugen Hoyos  wrote:
> 
> 2017-11-16 17:54 GMT+01:00 Dave Rice :
> 
>> +if (track->mode == MODE_MOV && track->par->codec_id == AV_CODEC_ID_V410)
>> +avio_wb16(pb, 0x18);
>> +else if (track->mode == MODE_MOV && track->par->codec_id == 
>> AV_CODEC_ID_V210)
>> +avio_wb16(pb, 0x18);
> 
> It appears you can merge the two cases.

The patch is updated with merged cases below.

> Or maybe patch bits_per_coded_sample in the encoder…


With Apple’s TN2162 there doesn’t appear to be a reliable relationship between 
the bits_per_coded_sample and what the ImageDescription depth value should be 
for the uncompressed yuv formats. TN2162 simply lists what the depth value 
should be and this patch corrects the few instances, where ffmpeg’s behavior 
doesn’t correlate to what TN2162 defines.


From cfa5b2cd959154f2896a9557d9ca2ed2d2d3834e Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Thu, 16 Nov 2017 11:53:32 -0500
Subject: [PATCH 2/2] avformat/movenc: correct ImageDescription depth for v210
 v410

Per
https://developer.apple.com/library/content/technotes/tn2162/_index.html
.
---
 libavformat/movenc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 98fcc7a44b..d9d3c2bf1e 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1896,7 +1896,10 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 avio_w8(pb, strlen(compressor_name));
 avio_write(pb, compressor_name, 31);
 
-if (track->mode == MODE_MOV && track->par->bits_per_coded_sample)
+if (track->mode == MODE_MOV &&
+   (track->par->codec_id == AV_CODEC_ID_V410 || track->par->codec_id == 
AV_CODEC_ID_V210))
+avio_wb16(pb, 0x18);
+else if (track->mode == MODE_MOV && track->par->bits_per_coded_sample)
 avio_wb16(pb, track->par->bits_per_coded_sample |
   (track->par->format == AV_PIX_FMT_GRAY8 ? 0x20 : 0));
 else
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410

2017-11-16 Thread Carl Eugen Hoyos
2017-11-16 17:54 GMT+01:00 Dave Rice :

> +if (track->mode == MODE_MOV && track->par->codec_id == AV_CODEC_ID_V410)
> +avio_wb16(pb, 0x18);
> +else if (track->mode == MODE_MOV && track->par->codec_id == 
> AV_CODEC_ID_V210)
> +avio_wb16(pb, 0x18);

It appears you can merge the two cases.

Or maybe patch bits_per_coded_sample in the encoder...

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


Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated in multiple threads.

2017-11-16 Thread Nick Lewycky
Sorry! Let's try an attachment then.

On 16 November 2017 at 14:36, Michael Niedermayer
 wrote:
> On Thu, Nov 16, 2017 at 12:41:32PM -0800, Nick Lewycky wrote:
>> I initially discovered a signed integer overflow on this line. Since
>> this value is updated in multiple threads, I use an atomic update and
>> as it happens atomic addition is defined to wrap around. However,
>> there's still a potential bug in that the error_count may wrap around
>> and equal zero again causing problems down the line.
>>
>> ---
>>  libavcodec/mpeg12dec.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
>> index d5bc5f21b2..b7c3b5106e 100644
>> --- a/libavcodec/mpeg12dec.c
>> +++ b/libavcodec/mpeg12dec.c
>> @@ -28,6 +28,7 @@
>>  #define UNCHECKED_BITSTREAM_READER 1
>>  #include 
>>
>> +#include "libavutil/atomic.h"
>>  #include "libavutil/attributes.h"
>>  #include "libavutil/imgutils.h"
>>  #include "libavutil/internal.h"
>> @@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx,
>> AVFrame *picture,
>> >thread_context[0], NULL,
>> s->slice_count, sizeof(void *));
>>  for (i = 0; i < s->slice_count; i++)
>> -s2->er.error_count +=
>> s2->thread_context[i]->er.error_count;
>> +
>> avpriv_atomic_int_add_and_fetch(>er.error_count,
>> s2->thread_context[i]->er.error_count);
>>  }
>
> This patch is corrupted by newlines
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From cd8ed0ee35853ae089df3d904846879ce4f00c4a Mon Sep 17 00:00:00 2001
From: Nick Lewycky 
Date: Thu, 16 Nov 2017 11:50:38 -0800
Subject: [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated
 in multiple threads.

---
 libavcodec/mpeg12dec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index d5bc5f21b2..b7c3b5106e 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -28,6 +28,7 @@
 #define UNCHECKED_BITSTREAM_READER 1
 #include 
 
+#include "libavutil/atomic.h"
 #include "libavutil/attributes.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/internal.h"
@@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame *picture,
>thread_context[0], NULL,
s->slice_count, sizeof(void *));
 for (i = 0; i < s->slice_count; i++)
-s2->er.error_count += s2->thread_context[i]->er.error_count;
+avpriv_atomic_int_add_and_fetch(>er.error_count, s2->thread_context[i]->er.error_count);
 }
 
 ret = slice_end(avctx, picture);
-- 
2.15.0.448.gf294e3d99a-goog



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/mxfenc: Support 60fps output

2017-11-16 Thread Carl Eugen Hoyos
2017-11-16 15:08 GMT+01:00 Derek Buitenhuis :
> On 11/16/2017 1:27 PM, Carl Eugen Hoyos wrote:
>> This was successfully tested so I will push if there are no objections.
>
> Seems harmless enough if it isn't violating some spec (it is MXF after all...)
>
> If someone had objections, they would have responded by now, probably.

Patch applied.

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


Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write 0 duration for subtitles

2017-11-16 Thread Carl Eugen Hoyos
2017-11-16 9:07 GMT+01:00 Jerome Martinez :
> On 12/11/2017 03:12, Carl Eugen Hoyos wrote:
>>
>> The matroska spec says blockduration == 0 means the frame is not a
>> keyframe.  Since all subtitles are "keyframes", 0 blockduration should
>> not be written.
>
>
> The issue is in the specifications:
> https://github.com/Matroska-Org/matroska-specification/pull/207
>
> The patch should not be integrated as the reason is no more valid.

Thank you!

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


Re: [FFmpeg-devel] fate/hapdec : add test for hap alpha only

2017-11-16 Thread Martin Vignali
>
> New patch in attach (use gray8 pix_fmt)
> Need to be apply after patch in discussion
> avcodec/hapdec : use gray8 for HapAlphaOnly decoding instead of RGB0
>
> Martin
>

With the attachment


0007-fate-hapAlphaOnly-add-test-for-hap-alpha-only-decodi.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] fate/hapdec : add test for hap alpha only

2017-11-16 Thread Martin Vignali
2017-09-28 21:53 GMT+02:00 Martin Vignali :

>
>
> 2017-09-24 11:53 GMT+02:00 Michael Niedermayer :
>
>> On Sat, Sep 23, 2017 at 09:53:45PM +0200, Martin Vignali wrote:
>> > Hello,
>> >
>> > sample can be found here :
>> > https://we.tl/cP0pW9IfBJ
>> >
>> > and need to be put inside ./fate-suite/hap
>>
>> uploaded
>>
>> [...]
>>
>
> New patch in attach (after change of pixfmt in HapAlphaOnly decoding)
>
>

New patch in attach (use gray8 pix_fmt)
Need to be apply after patch in discussion
avcodec/hapdec : use gray8 for HapAlphaOnly decoding instead of RGB0

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


[FFmpeg-devel] avcodec/hapdec : use gray8 for HapAlphaOnly decoding instead of RGB0

2017-11-16 Thread Martin Vignali
Hello,

Following previous discussion
patch in attach change pix_fmt for hap alpha only decoding to use gray8
instead of RGB0


0005-avcodec-texturedsp-add-rgtc1u-gray-decoding.patch
add rgtc1u_gray func in order to decode in a gray8 picture


0006-avcodec-hapdec-use-gray8-for-HapAlphaOnly-decoding
use new texturedsp func, and modify the texture_uncompress_thread to use
4 byte/pixel or 1 byte/pixel texture


Martin


0005-avcodec-texturedsp-add-rgtc1u-gray-decoding.patch
Description: Binary data


0006-avcodec-hapdec-use-gray8-for-HapAlphaOnly-decoding.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

2017-11-16 Thread Carl Eugen Hoyos
2017-11-13 6:41 GMT+01:00 Umair Khan :
> Hi,
>
> On Mon, Nov 13, 2017 at 1:09 AM, Carl Eugen Hoyos  wrote:
>> 2017-11-12 20:30 GMT+01:00 Umair Khan :
>>> Hi,
>>>
>>> On Mon, Nov 13, 2017 at 12:45 AM, Carl Eugen Hoyos  
>>> wrote:
 2017-11-12 20:05 GMT+01:00 Umair Khan :

> The attached patch fixes the address sanitizer issue.

 Breaks compilation here, how did you test?

 libavcodec/alsdec.c: In function ‘decode_var_block_data’:
 libavcodec/alsdec.c:938:7: error: expected ‘}’ before ‘else’
>>>
>>> Sorry for the faulty patch. Here is the fixed one.
>>
>> The commit message of your patch is:
>> libavcodec/als: fix address sanitization error in decoder
>>
>> Is there an error in current FFmpeg git head that asan
>> shows? If not, the commit message makes no sense.
>>
>> I believe you should send two patches that are meant
>> to be committed together, one of them fixing ticket #6297.
>
> This is the complete patchset.

Pushed.

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


Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated in multiple threads.

2017-11-16 Thread Michael Niedermayer
On Thu, Nov 16, 2017 at 12:41:32PM -0800, Nick Lewycky wrote:
> I initially discovered a signed integer overflow on this line. Since
> this value is updated in multiple threads, I use an atomic update and
> as it happens atomic addition is defined to wrap around. However,
> there's still a potential bug in that the error_count may wrap around
> and equal zero again causing problems down the line.
> 
> ---
>  libavcodec/mpeg12dec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index d5bc5f21b2..b7c3b5106e 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -28,6 +28,7 @@
>  #define UNCHECKED_BITSTREAM_READER 1
>  #include 
> 
> +#include "libavutil/atomic.h"
>  #include "libavutil/attributes.h"
>  #include "libavutil/imgutils.h"
>  #include "libavutil/internal.h"
> @@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx,
> AVFrame *picture,
> >thread_context[0], NULL,
> s->slice_count, sizeof(void *));
>  for (i = 0; i < s->slice_count; i++)
> -s2->er.error_count +=
> s2->thread_context[i]->er.error_count;
> +
> avpriv_atomic_int_add_and_fetch(>er.error_count,
> s2->thread_context[i]->er.error_count);
>  }

This patch is corrupted by newlines

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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


Re: [FFmpeg-devel] [PATCH] lavf/movenc: allow writing avc3 sample entry type

2017-11-16 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 09:17:39AM -0800, John Stebbins wrote:
> The avc3 sample entry type is useful for adaptive streaming.  It permits
> parameter sets to be written inline in the video stream.
> ---
>  libavformat/movenc.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

thanks

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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


Re: [FFmpeg-devel] Check size of STSC allocation

2017-11-16 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 05:25:47PM -0800, Fredrik Hubinette wrote:
> Fixed indentation.
> 
> 
> On Wed, Nov 15, 2017 at 3:40 PM, Carl Eugen Hoyos 
> wrote:
> 
> > 2017-11-16 0:21 GMT+01:00 Fredrik Hubinette  > org>:
> > > This patch checks that the memory allocated for stsc entries isn't larger
> > > than the atom.
> >
> > Consider fixing the indentation of the second added line,
> > making the committer's life easier.
> >
> > Thank you, Carl Eugen
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  mov.c |2 ++
>  1 file changed, 2 insertions(+)
> ddf55d33d4ddd7358a6562921eecd7703b0b1993  
> 0001-Check-size-of-STSC-allocation.patch
> From 13afb2b1a5d135b6aed55b910a4146da972a6e01 Mon Sep 17 00:00:00 2001
> From: Fredrik Hubinette 
> Date: Wed, 15 Nov 2017 17:24:30 -0800
> Subject: [PATCH] Check size of STSC allocation

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Kieran Kunhya
On Thu, 16 Nov 2017 at 18:21 Ronald S. Bultje  wrote:

> We are re-hashing old arguments here. I'm not really interested in that.
>
> My review comment is and remains: please remove the log msg. Otherwise, the
> patch is perfectly fine.
>

I agree with Ronald's argument. I don't care about this particular instance
however since Snow is not of interest to me.

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Michael Niedermayer
On Thu, Nov 16, 2017 at 01:21:19PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Nov 16, 2017 at 11:50 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> 
> > On Thu, Nov 16, 2017 at 06:26:06AM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos 
> > > wrote:
> > >
> > > > 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
> > > >
> > > > > So, commit it without the error message? I really don't see the
> > issue.
> > > >
> > > > As explained, the issue is that without an error message, it
> > > > is impossible to parse any related bug report.
> > >
> > >
> > > We've been OK with that situation so far. Since it only happens for
> > fuzzed
> > > files, it's OK to continue going like that.
> >
> > Thats not the case, the snow spec contains no limit in the place where
> > we need to check. Its a natural and expected limit so likely all files
> > will be within that but a file outside would still be arguably valid.
> >
> > So a valid file could potentially be outside this range and the
> > maintainer (that being me) need to know about this.
> >
> > Please dont see every change that originated from a fuzzer generated
> > report as only related to fuzzed files.
> 
> 
> We are re-hashing old arguments here. I'm not really interested in that.

>
> My review comment is and remains: please remove the log msg. Otherwise, the
> patch is perfectly fine.

Thank you for your review comment.

please awnser my question, if this is just a suggestion or a
veto, so we can move forward. Its not clear from your wording to me
if you belive you have authority over other maintainers or not.

Normally developers withdraw a comment if the maintainer disagrees
or one would start some poll to find out what the majority preferres
and create a rule from that for all (which i suggested already)
yet you just repeat the same comment.

It feels impolite if i would just go ahead and push the patch without
confirming that this is just a suggestion and not some kind of veto.
So please clarify this

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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


Re: [FFmpeg-devel] [PATCH] avfilter/vf_cropdetect: change license to LGPL

2017-11-16 Thread Aman Gupta
On Tue, Nov 14, 2017 at 2:35 PM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> This filter was imported from mplayer's libmpcodecs/vf_cropdetect.c, and
> marked as GPL when originally copied over.
>
> On the mplayer side, it was authored originally by arpi and subsequently
> touched by
> the following contributors. See https://github.com/pigoz/
> mplayer-svn/commits/master/libmpcodecs/vf_cropdetect.c
>
>   arpi
>   albeu
>   diego
>   reimar
>   michael
>   reynaldo
>   lucabe
>   cehoyos
>
> Of these contributors, all except the last two granted their permission to
> relicense
> mplayer changes to LGPL. See https://github.com/mpv-player/
> mpv/wiki/List-of-MPlayer-LGPL-relicensing-agreements
>
> The change by lucabe was to remove an include header, and the change by
> cehoyos was to
> change whitespace. Both are trivial and can be ignored for copyright
> purposes. See
> https://github.com/pigoz/mplayer-svn/commit/6da0237a4#diff-
> 2d400db883ad8bca0e5d6a78f12613fd
> and https://github.com/pigoz/mplayer-svn/commit/04d069fcb#diff-
> 2d400db883ad8bca0e5d6a78f12613fd
>
> The import into ffmpeg was done by Stefano Sabatini. It was then touched
> by the following
> contributors, who specifically made changes to the filter. This does not
> include
> commits which changed this file but were part of larger refactorings that
> changed
> lavfi APIs and other LGPL filters as well. See
> https://github.com/FFmpeg/FFmpeg/commits/master/
> libavfilter/vf_cropdetect.c
>
>   Stefano Sabatini
>   Michael Niedermayer
>   Anton Khirnov
>   Clément Bœsch
>   Paul B Mahol
>   Carl Eugen Hoyos
>   Vittorio Giovara
>   Ganesh Ajjanagadde
>
> The people above are CC'd on this patch for their permission to relicense
> vf_cropdetect as LGPL.
>

I received an OK from Ganesh.

-- Forwarded message --
From: yV7e6RyE gAQ0A4k4 
Date: Tue, Nov 14, 2017 at 4:16 PM
Subject: Re: [PATCH] avfilter/vf_cropdetect: change license to LGPL
To: Aman Gupta 


I am fine with the license change.

Best wishes,
Ganesh


> ---
>  configure   |  1 -
>  libavfilter/vf_cropdetect.c | 18 +-
>  2 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/configure b/configure
> index 3788f26956..c1bdea9fa5 100755
> --- a/configure
> +++ b/configure
> @@ -3185,7 +3185,6 @@ coreimage_filter_extralibs="-framework OpenGL"
>  coreimagesrc_filter_deps="coreimage appkit"
>  coreimagesrc_filter_extralibs="-framework OpenGL"
>  cover_rect_filter_deps="avcodec avformat gpl"
> -cropdetect_filter_deps="gpl"
>  deinterlace_qsv_filter_deps="libmfx"
>  deinterlace_vaapi_filter_deps="vaapi"
>  delogo_filter_deps="gpl"
> diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
> index 7c7d0b953a..84abbe714c 100644
> --- a/libavfilter/vf_cropdetect.c
> +++ b/libavfilter/vf_cropdetect.c
> @@ -2,19 +2,19 @@
>   * Copyright (c) 2002 A'rpi
>   * This file is part of FFmpeg.
>   *
> - * FFmpeg is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> + * 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 General Public License for more details.
> + * 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 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.
> + * 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
>   */
>
>  /**
> --
> 2.14.2
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] libavcodec/mpeg12dec: Use atomic addition for value updated in multiple threads.

2017-11-16 Thread Nick Lewycky
I initially discovered a signed integer overflow on this line. Since
this value is updated in multiple threads, I use an atomic update and
as it happens atomic addition is defined to wrap around. However,
there's still a potential bug in that the error_count may wrap around
and equal zero again causing problems down the line.

---
 libavcodec/mpeg12dec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index d5bc5f21b2..b7c3b5106e 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -28,6 +28,7 @@
 #define UNCHECKED_BITSTREAM_READER 1
 #include 

+#include "libavutil/atomic.h"
 #include "libavutil/attributes.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/internal.h"
@@ -2476,7 +2477,7 @@ static int decode_chunks(AVCodecContext *avctx,
AVFrame *picture,
>thread_context[0], NULL,
s->slice_count, sizeof(void *));
 for (i = 0; i < s->slice_count; i++)
-s2->er.error_count +=
s2->thread_context[i]->er.error_count;
+
avpriv_atomic_int_add_and_fetch(>er.error_count,
s2->thread_context[i]->er.error_count);
 }

 ret = slice_end(avctx, picture);
-- 
2.15.0.448.gf294e3d99a-goog


smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

2017-11-16 Thread Thilo Borgmann
Am 16.11.17 um 19:24 schrieb Thilo Borgmann:
> Am 14.11.17 um 08:23 schrieb Umair Khan:
>> Hi,
>>
>> On Tue, Nov 14, 2017 at 4:05 AM, Carl Eugen Hoyos  wrote:
>>> 2017-11-13 6:41 GMT+01:00 Umair Khan :
 Hi,

 On Mon, Nov 13, 2017 at 1:09 AM, Carl Eugen Hoyos  
 wrote:
> 2017-11-12 20:30 GMT+01:00 Umair Khan :
>> Hi,
>>
>> On Mon, Nov 13, 2017 at 12:45 AM, Carl Eugen Hoyos  
>> wrote:
>>> 2017-11-12 20:05 GMT+01:00 Umair Khan :
>>>
 The attached patch fixes the address sanitizer issue.
>>>
>>> Breaks compilation here, how did you test?
>>>
>>> libavcodec/alsdec.c: In function ‘decode_var_block_data’:
>>> libavcodec/alsdec.c:938:7: error: expected ‘}’ before ‘else’
>>
>> Sorry for the faulty patch. Here is the fixed one.
>
> The commit message of your patch is:
> libavcodec/als: fix address sanitization error in decoder
>
> Is there an error in current FFmpeg git head that asan
> shows? If not, the commit message makes no sense.
>
> I believe you should send two patches that are meant
> to be committed together, one of them fixing ticket #6297.

 This is the complete patchset.
>>>
>>> Bonus points for mentioning the ticket number in the
>>> commit message (can be done by the committer).
>>>
>>> Thank you for looking into this!
>>
>> I have attached the complete patch. Ticket link is mentioned in the
>> commit description.
> 
> Thanks, will have a look at it asap!

Ok to apply!

Will do myself tomorrow if nobody else does it earlier.

Thanks,
Thilo

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


[FFmpeg-devel] [PATCH] Download dash content with byte range info

2017-11-16 Thread Colin NG
---
 libavformat/dashdec.c | 32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..33255f2 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * get_Fragment(char *range) {
+struct fragment * seg = av_mallocz(sizeof(struct fragment));
+
+if (!seg)
+return NULL;
+
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", _end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset+1;
+}
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
representation *rep,
  xmlNodePtr fragmenturl_node,
  xmlNodePtr *baseurl_nodes,
@@ -530,11 +546,13 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 {
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *range_val = NULL;
 
 if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"Initialization")) {
 initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
-if (initialization_val) {
-rep->init_section = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "range");
+if (initialization_val || range_val) {
+rep->init_section = get_Fragment(range_val);
 if (!rep->init_section) {
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
@@ -548,13 +566,14 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
 }
-rep->init_section->size = -1;
 xmlFree(initialization_val);
+xmlFree(range_val);
 }
 } else if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"SegmentURL")) {
 media_val = xmlGetProp(fragmenturl_node, "media");
-if (media_val) {
-struct fragment *seg = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "mediaRange");
+if (media_val || range_val) {
+struct fragment *seg =  get_Fragment(range_val);
 if (!seg) {
 xmlFree(media_val);
 return AVERROR(ENOMEM);
@@ -568,15 +587,14 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(media_val);
 return AVERROR(ENOMEM);
 }
-seg->size = -1;
 dynarray_add(>fragments, >n_fragments, seg);
 xmlFree(media_val);
+xmlFree(range_val);
 }
 }
 
 return 0;
 }
-
 static int parse_manifest_segmenttimeline(AVFormatContext *s, struct 
representation *rep,
   xmlNodePtr fragment_timeline_node)
 {
-- 
2.7.4

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


[FFmpeg-devel] [PATCH 5/6] Add suppoort for using libklvanc from within decklink capture module

2017-11-16 Thread Devin Heitmueller
Make use of libklvanc from within the decklink capture module,
initially for EIA-708 and AFD.  Support for other VANC types will
come in subsequent patches.

Signed-off-by: Devin Heitmueller 
---
 libavdevice/decklink_dec.cpp | 135 +++
 1 file changed, 135 insertions(+)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 11b7e60..bea9213 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -3,6 +3,7 @@
  * Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
  * Copyright (c) 2014 Rafaël Carré
  * Copyright (c) 2017 Akamai Technologies, Inc.
+ * Copyright (c) 2017 LTN Global Communications, Inc.
  *
  * This file is part of FFmpeg.
  *
@@ -669,10 +670,128 @@ error:
 return ret;
 }
 
+#if CONFIG_LIBKLVANC
+/* VANC Callbacks */
+struct vanc_cb_ctx {
+AVFormatContext *avctx;
+AVPacket *pkt;
+};
+static int cb_AFD(void *callback_context, struct klvanc_context_s *ctx,
+  struct klvanc_packet_afd_s *pkt)
+{
+struct vanc_cb_ctx *cb_ctx = (struct vanc_cb_ctx *)callback_context;
+uint8_t *afd;
+
+afd = (uint8_t *)av_malloc(1);
+if (afd == NULL)
+return AVERROR(ENOMEM);
+
+afd[0] = pkt->hdr.payload[0] >> 3;
+if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, afd, 1) < 0)
+av_free(afd);
+
+return 0;
+}
+
+static int cb_EIA_708B(void *callback_context, struct klvanc_context_s *ctx,
+   struct klvanc_packet_eia_708b_s *pkt)
+{
+struct vanc_cb_ctx *cb_ctx = (struct vanc_cb_ctx *)callback_context;
+decklink_cctx *cctx = (struct decklink_cctx *)cb_ctx->avctx->priv_data;
+struct decklink_ctx *decklink_ctx = (struct decklink_ctx *)cctx->ctx;
+
+uint16_t expected_cdp;
+uint8_t *cc;
+
+if (!pkt->checksum_valid)
+return 0;
+
+if (!pkt->header.ccdata_present)
+return 0;
+
+expected_cdp = decklink_ctx->cdp_sequence_num + 1;
+decklink_ctx->cdp_sequence_num = pkt->header.cdp_hdr_sequence_cntr;
+if (pkt->header.cdp_hdr_sequence_cntr != expected_cdp) {
+av_log(cb_ctx->avctx, AV_LOG_DEBUG,
+   "CDP counter inconsistent.  Received=0x%04x Expected=%04x\n",
+   pkt->header.cdp_hdr_sequence_cntr, expected_cdp);
+return 0;
+}
+
+cc = (uint8_t *)av_malloc(pkt->ccdata.cc_count * 3);
+if (cc == NULL)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < pkt->ccdata.cc_count; i++) {
+cc[3*i] = 0xf8 | (pkt->ccdata.cc[i].cc_valid ? 0x04 : 0x00) |
+  (pkt->ccdata.cc[i].cc_type & 0x03);
+cc[3*i+1] = pkt->ccdata.cc[i].cc_data[0];
+cc[3*i+2] = pkt->ccdata.cc[i].cc_data[1];
+}
+
+if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_A53_CC, cc, 
pkt->ccdata.cc_count * 3) < 0)
+av_free(cc);
+
+return 0;
+}
+
+static struct klvanc_callbacks_s callbacks =
+{
+.afd   = cb_AFD,
+.eia_708b  = cb_EIA_708B,
+.eia_608   = NULL,
+.scte_104  = NULL,
+.all   = NULL,
+.kl_i64le_counter  = NULL,
+};
+/* End: VANC Callbacks */
+
+/* Take one line of V210 from VANC, colorspace convert and feed it to the
+ * VANC parser. We'll expect our VANC message callbacks to happen on this
+ * same calling thread.
+ */
+static void klvanc_handle_line(AVFormatContext *avctx, struct klvanc_context_s 
*vanc_ctx,
+   unsigned char *buf, unsigned int uiWidth, 
unsigned int lineNr,
+   AVPacket *pkt)
+{
+/* Convert the vanc line from V210 to CrCB422, then vanc parse it */
+
+/* We need two kinds of type pointers into the source vbi buffer */
+/* TODO: What the hell is this, two ptrs? */
+const uint32_t *src = (const uint32_t *)buf;
+
+/* Convert Blackmagic pixel format to nv20.
+ * src pointer gets mangled during conversion, hence we need its own
+ * ptr instead of passing vbiBufferPtr.
+ * decoded_words should be atleast 2 * uiWidth.
+ */
+uint16_t decoded_words[16384];
+
+/* On output each pixel will be decomposed into three 16-bit words (one 
for Y, U, V) */
+memset(_words[0], 0, sizeof(decoded_words));
+uint16_t *p_anc = decoded_words;
+if (klvanc_v210_line_to_nv20_c(src, p_anc, sizeof(decoded_words), (uiWidth 
/ 6) * 6) < 0)
+return;
+
+if (vanc_ctx) {
+struct vanc_cb_ctx cb_ctx = {
+.avctx = avctx,
+.pkt = pkt
+};
+vanc_ctx->callback_context = _ctx;
+int ret = klvanc_packet_parse(vanc_ctx, lineNr, decoded_words, 
sizeof(decoded_words) / (sizeof(unsigned short)));
+if (ret < 0) {
+/* No VANC on this line */
+}
+}
+}
+#endif
+
 HRESULT decklink_input_callback::VideoInputFrameArrived(
 IDeckLinkVideoInputFrame *videoFrame, IDeckLinkAudioInputPacket 
*audioFrame)
 {
 decklink_cctx *cctx = (struct decklink_cctx 

[FFmpeg-devel] [PATCH 4/6] Support encoding of Active Format Description (AFD) in libx264

2017-11-16 Thread Devin Heitmueller
If AFD side data is present, include it in an H.264 SEI payload when
encoding with libx264.

This is done in the same manner that we currently handle A53 closed
captions (where the business logic for constructing the SEI is in
libavcodec/utils.c), so it should be portable to the other encoder
types (i.e. videotoolbox, etc).

Signed-off-by: Devin Heitmueller 
---
 libavcodec/internal.h |  3 +++
 libavcodec/libx264.c  | 38 ++
 libavcodec/utils.c| 36 
 3 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index d47ce0e..a2c7be4 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -408,6 +408,9 @@ int ff_side_data_set_encoder_stats(AVPacket *pkt, int 
quality, int64_t *error, i
 int ff_alloc_a53_sei(const AVFrame *frame, size_t prefix_len,
  void **data, size_t *sei_size);
 
+int ff_alloc_afd_sei(const AVFrame *frame, size_t prefix_len,
+ void **data, size_t *sei_size);
+
 /**
  * Get an estimated video bitrate based on frame size, frame rate and coded
  * bits per pixel.
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 9c67c91..f0f3260 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -86,6 +86,7 @@ typedef struct X264Context {
 int forced_idr;
 int coder;
 int a53_cc;
+int afd;
 int b_frame_strategy;
 int chroma_offset;
 int scenechange_threshold;
@@ -275,6 +276,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 x264_nal_t *nal;
 int nnal, i, ret;
 x264_picture_t pic_out = {0};
+int num_payloads = 0;
 int pict_type;
 
 x264_picture_init( >pic );
@@ -323,10 +325,37 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 } else {
 x4->pic.extra_sei.sei_free = av_free;
 
-x4->pic.extra_sei.payloads[0].payload_size = sei_size;
-x4->pic.extra_sei.payloads[0].payload = sei_data;
-x4->pic.extra_sei.num_payloads = 1;
-x4->pic.extra_sei.payloads[0].payload_type = 4;
+x4->pic.extra_sei.payloads[num_payloads].payload_size = 
sei_size;
+x4->pic.extra_sei.payloads[num_payloads].payload = 
sei_data;
+x4->pic.extra_sei.payloads[num_payloads].payload_type = 4;
+x4->pic.extra_sei.num_payloads++;
+num_payloads++;
+}
+}
+}
+
+/* Active Format Description */
+if (x4->afd) {
+void *sei_data;
+size_t sei_size;
+
+ret = ff_alloc_afd_sei(frame, 0, _data, _size);
+if (ret < 0) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for AFD, 
skipping\n");
+} else if (sei_data) {
+x4->pic.extra_sei.payloads = 
av_realloc(x4->pic.extra_sei.payloads,
+
sizeof(x4->pic.extra_sei.payloads[0]) * (num_payloads + 1));
+if (x4->pic.extra_sei.payloads == NULL) {
+av_log(ctx, AV_LOG_ERROR, "Not enough memory for AFD, 
skipping\n");
+av_free(sei_data);
+} else {
+x4->pic.extra_sei.sei_free = av_free;
+
+x4->pic.extra_sei.payloads[num_payloads].payload_size = 
sei_size;
+x4->pic.extra_sei.payloads[num_payloads].payload = 
sei_data;
+x4->pic.extra_sei.payloads[num_payloads].payload_type = 4;
+x4->pic.extra_sei.num_payloads++;
+num_payloads++;
 }
 }
 }
@@ -892,6 +921,7 @@ static const AVOption options[] = {
 {"passlogfile", "Filename for 2 pass stats", OFFSET(stats), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"a53cc",  "Use A53 Closed Captions (if available)",  
OFFSET(a53_cc),AV_OPT_TYPE_BOOL,   {.i64 = 1}, 0, 1, VE},
+{"afd","Use Active Format Description (AFD) (if 
available)",OFFSET(afd),AV_OPT_TYPE_BOOL,   {.i64 = 1}, 0, 1, VE},
 {"x264opts", "x264 options", OFFSET(x264opts), AV_OPT_TYPE_STRING, 
{.str=NULL}, 0, 0, VE},
 { "crf",   "Select the quality for constant quality mode",
OFFSET(crf),   AV_OPT_TYPE_FLOAT,  {.dbl = -1 }, -1, FLT_MAX, VE },
 { "crf_max",   "In CRF mode, prevents VBV from lowering quality beyond 
this point.",OFFSET(crf_max), AV_OPT_TYPE_FLOAT, {.dbl = -1 }, -1, FLT_MAX, VE 
},
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e50de6e..550b030 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2396,6 +2396,42 @@ int 

[FFmpeg-devel] [PATCH 6/6] decklink: Add support for SCTE-104 to decklink capture

2017-11-16 Thread Devin Heitmueller
Make use of libklvanc to parse SCTE-104 packets and announce them
as a new stream.  Right now we just pass the payload straight
through, but once this is hoooked into libklscte35 we'll be able
to generate SCTE-35 messages in the MPEG TS stream.

Note that this feature needs to be explicitly enabled by the user
through the "-enable_scte_104" option, since we cannot autodetect
the presence of SCTE-104 (because unlike with 708/AFD messages are
not set except when trigger occurs, thus the stream wouldn't get
created during the read_header phase).

Signed-off-by: Devin Heitmueller 
---
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  6 
 libavdevice/decklink_common.h   |  6 
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 64 -
 libavdevice/decklink_dec_c.c|  1 +
 6 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 6981f07..453b6be 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -667,6 +667,7 @@ enum AVCodecID {
 AV_CODEC_ID_TTF = 0x18000,
 
 AV_CODEC_ID_SCTE_35, ///< Contain timestamp estimated through PCR of 
program stream.
+AV_CODEC_ID_SCTE_104,
 AV_CODEC_ID_BINTEXT= 0x18800,
 AV_CODEC_ID_XBIN,
 AV_CODEC_ID_IDF,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index c3688de..e198985 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3103,6 +3103,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .name  = "scte_35",
 .long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
 },
+{
+.id= AV_CODEC_ID_SCTE_104,
+.type  = AVMEDIA_TYPE_DATA,
+.name  = "scte_104",
+.long_name = NULL_IF_CONFIG_SMALL("SCTE 104 Digital Program 
Insertion"),
+},
 
 /* deprecated codec ids */
 };
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index bbe4deb..3ecdb19 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -35,6 +35,10 @@
Actual number for any particular model of card may be lower */
 #define DECKLINK_MAX_AUDIO_CHANNELS 32
 
+/* This isn't actually tied to the Blackmagic hardware - it's an arbitrary
+   number used to size the array of streams */
+#define DECKLINK_MAX_DATA_STREAMS 16
+
 class decklink_output_callback;
 class decklink_input_callback;
 
@@ -86,6 +90,8 @@ struct decklink_ctx {
 unsigned int dropped;
 AVStream *audio_st[DECKLINK_MAX_AUDIO_CHANNELS];
 int num_audio_streams;
+AVStream *data_st[DECKLINK_MAX_DATA_STREAMS];
+int num_data_streams;
 AVStream *video_st;
 AVStream *teletext_st;
 uint16_t cdp_sequence_num;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 02011ed..cb73ec9 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -58,6 +58,7 @@ struct decklink_cctx {
 char *format_code;
 int raw_format;
 int64_t queue_size;
+int enable_scte_104;
 };
 
 #endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index bea9213..47323b1 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -670,6 +670,33 @@ error:
 return ret;
 }
 
+static int setup_data(AVFormatContext *avctx)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+AVStream *st;
+int ret = 0;
+
+if (cctx->enable_scte_104) {
+st = avformat_new_stream(avctx, NULL);
+if (!st) {
+av_log(avctx, AV_LOG_ERROR, "Cannot add data stream\n");
+ret = AVERROR(ENOMEM);
+goto error;
+}
+st->codecpar->codec_type  = AVMEDIA_TYPE_DATA;
+st->time_base.den = ctx->bmd_tb_den;
+st->time_base.num = ctx->bmd_tb_num;
+st->codecpar->codec_id= AV_CODEC_ID_SCTE_104;
+avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
+ctx->data_st[ctx->num_data_streams] = st;
+ctx->num_data_streams++;
+}
+
+error:
+return ret;
+}
+
 #if CONFIG_LIBKLVANC
 /* VANC Callbacks */
 struct vanc_cb_ctx {
@@ -735,12 +762,44 @@ static int cb_EIA_708B(void *callback_context, struct 
klvanc_context_s *ctx,
 return 0;
 }
 
+static int cb_SCTE_104(void *callback_context, struct klvanc_context_s *ctx,
+   struct klvanc_packet_scte_104_s *pkt)
+{
+struct vanc_cb_ctx *cb_ctx = (struct vanc_cb_ctx *)callback_context;
+decklink_cctx *decklink_cctx = (struct decklink_cctx 
*)cb_ctx->avctx->priv_data;
+struct decklink_ctx *decklink_ctx = (struct decklink_ctx 
*)decklink_cctx->ctx;
+AVPacket avpkt;
+av_init_packet();
+
+avpkt.stream_index = -1;
+for (int i = 0; i < 

[FFmpeg-devel] [PATCH 3/6] Preserve AFD side data when going from AVPacket to AVFrame

2017-11-16 Thread Devin Heitmueller
This is needed to ensure that AFD data continues to work when
capturing V210 video with the Decklink libavdevice input.

Signed-off-by: Devin Heitmueller 
---
 libavcodec/decode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a7f1e23..e981651 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1537,6 +1537,7 @@ int ff_init_buffer_info(AVCodecContext *avctx, AVFrame 
*frame)
 { AV_PKT_DATA_MASTERING_DISPLAY_METADATA, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
 { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
 { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
+{ AV_PKT_DATA_AFD,AV_FRAME_DATA_AFD },
 };
 
 if (pkt) {
-- 
1.8.3.1

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


[FFmpeg-devel] [PATCH 2/6] decklink: Introduce support for capture of multiple audio streams

2017-11-16 Thread Devin Heitmueller
Add support for the ability to capture all audio pairs available
to the capture hardware.  Each pair is exposed as a different audio
stream, which matches up with the most common use cases for the
broadcast space (i.e. where there is one stereo pair per audio
language).

To support the existing use case where multi-channel audio can be
captured (i.e. 7.1), we introduced a new configuration option, which
defaults to the existing behavior.

Signed-off-by: Devin Heitmueller 
---
 libavdevice/decklink_common.cpp |   9 +++
 libavdevice/decklink_common.h   |   8 ++-
 libavdevice/decklink_common_c.h |   6 ++
 libavdevice/decklink_dec.cpp| 134 +++-
 libavdevice/decklink_dec_c.c|   3 +
 5 files changed, 130 insertions(+), 30 deletions(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index c425f4a..050b839 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -473,5 +473,14 @@ int ff_decklink_init_device(AVFormatContext *avctx, const 
char* name)
 return AVERROR_EXTERNAL;
 }
 
+if (ctx->attr->GetInt(BMDDeckLinkMaximumAudioChannels, 
>max_audio_channels) != S_OK) {
+av_log(avctx, AV_LOG_WARNING, "Could not determine number of audio 
channels\n");
+ctx->max_audio_channels = 0;
+}
+if (ctx->max_audio_channels > DECKLINK_MAX_AUDIO_CHANNELS) {
+av_log(avctx, AV_LOG_WARNING, "Decklink card reported support for more 
channels than ffmpeg supports\n");
+ctx->max_audio_channels = DECKLINK_MAX_AUDIO_CHANNELS;
+}
+
 return 0;
 }
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index e951b17..bbe4deb 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -31,6 +31,10 @@
 #include "libklvanc/vanc.h"
 #endif
 
+/* Maximum number of channels possible across variants of Blackmagic cards.
+   Actual number for any particular model of card may be lower */
+#define DECKLINK_MAX_AUDIO_CHANNELS 32
+
 class decklink_output_callback;
 class decklink_input_callback;
 
@@ -65,6 +69,7 @@ struct decklink_ctx {
 int bmd_height;
 int bmd_field_dominance;
 int supports_vanc;
+int64_t max_audio_channels;
 
 /* Capture buffer queue */
 AVPacketQueue queue;
@@ -79,7 +84,8 @@ struct decklink_ctx {
 int64_t last_pts;
 unsigned long frameCount;
 unsigned int dropped;
-AVStream *audio_st;
+AVStream *audio_st[DECKLINK_MAX_AUDIO_CHANNELS];
+int num_audio_streams;
 AVStream *video_st;
 AVStream *teletext_st;
 uint16_t cdp_sequence_num;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 368ac25..02011ed 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -30,6 +30,11 @@ typedef enum DecklinkPtsSource {
 PTS_SRC_WALLCLOCK = 4,
 } DecklinkPtsSource;
 
+typedef enum DecklinkAudioMode {
+AUDIO_MODE_DISCRETE = 0,
+AUDIO_MODE_PAIRS = 1,
+} DecklinkAudioMode;
+
 struct decklink_cctx {
 const AVClass *cclass;
 
@@ -42,6 +47,7 @@ struct decklink_cctx {
 double preroll;
 int v210;
 int audio_channels;
+int audio_mode;
 int audio_depth;
 int duplex_mode;
 DecklinkPtsSource audio_pts_source;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index e90b428..11b7e60 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -625,9 +625,54 @@ static int64_t get_pkt_pts(IDeckLinkVideoInputFrame 
*videoFrame,
 return pts;
 }
 
+static int setup_audio(AVFormatContext *avctx)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+AVStream *st;
+int ret = 0;
+
+if (cctx->audio_mode == AUDIO_MODE_DISCRETE) {
+st = avformat_new_stream(avctx, NULL);
+if (!st) {
+av_log(avctx, AV_LOG_ERROR, "Cannot add stream\n");
+ret = AVERROR(ENOMEM);
+goto error;
+}
+st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id= ctx->audio_depth == 32 ? 
AV_CODEC_ID_PCM_S32LE : AV_CODEC_ID_PCM_S16LE;
+st->codecpar->sample_rate = bmdAudioSampleRate48kHz;
+st->codecpar->channels= cctx->audio_channels;
+avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
+ctx->audio_st[0] = st;
+ctx->num_audio_streams++;
+} else {
+for (int i = 0; i < ctx->max_audio_channels / 2; i++) {
+st = avformat_new_stream(avctx, NULL);
+if (!st) {
+av_log(avctx, AV_LOG_ERROR, "Cannot add stream %d\n", i);
+ret = AVERROR(ENOMEM);
+goto error;
+}
+st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id= ctx->audio_depth == 32 ? 
AV_CODEC_ID_PCM_S32LE : AV_CODEC_ID_PCM_S16LE;

[FFmpeg-devel] [RFC PATCH 0/6] Decklink capture VANC improvements and AFD in libx264

2017-11-16 Thread Devin Heitmueller
The following patch series extends the decklink capture module to use
libklvanc for EIA-708, AFD, and SCTE-104 VANC messages.  It also
introduces support for generating multiple streams of audio, one for
each SDI pair.

The ffmpeg glue for libx264 has been improved to support encoding
of Active Format Description if present as side-data.  This was
needed in order to capture AFD on the decklink interface and have it
end up in the final TS (assuming an encoding use case).

Devin Heitmueller (6):
  decklink: Fix case where return value wasn't being set before checked
for errors
  decklink: Introduce support for capture of multiple audio streams
  Preserve AFD side data when going from AVPacket to AVFrame
  Support encoding of Active Format Description (AFD) in libx264
  Add suppoort for using libklvanc from within decklink capture module
  decklink: Add support for SCTE-104 to decklink capture

 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   6 +
 libavcodec/decode.c |   1 +
 libavcodec/internal.h   |   3 +
 libavcodec/libx264.c|  38 -
 libavcodec/utils.c  |  36 +
 libavdevice/decklink_common.cpp |   9 ++
 libavdevice/decklink_common.h   |  14 +-
 libavdevice/decklink_common_c.h |   7 +
 libavdevice/decklink_dec.cpp| 331 
 libavdevice/decklink_dec_c.c|   4 +
 libavdevice/decklink_enc.cpp|   2 +-
 12 files changed, 417 insertions(+), 35 deletions(-)

-- 
1.8.3.1

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


[FFmpeg-devel] [PATCH 1/6] decklink: Fix case where return value wasn't being set before checked for errors

2017-11-16 Thread Devin Heitmueller
I missed an assignement which cauesd the error case to not ever be properly
checked.

Signed-off-by: Devin Heitmueller 
---
 libavdevice/decklink_enc.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 070bfad..1fb986e 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -300,7 +300,7 @@ static int decklink_construct_vanc(AVFormatContext *avctx, 
struct decklink_ctx *
 if (ret != 0)
 return AVERROR(ENOMEM);
 
-klvanc_set_framerate_EIA_708B(pkt, ctx->bmd_tb_num, ctx->bmd_tb_den);
+ret = klvanc_set_framerate_EIA_708B(pkt, ctx->bmd_tb_num, 
ctx->bmd_tb_den);
 if (ret != 0) {
 av_log(avctx, AV_LOG_ERROR, "Invalid framerate specified: 
%lld/%lld\n",
ctx->bmd_tb_num, ctx->bmd_tb_den);
-- 
1.8.3.1

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Ronald S. Bultje
Hi,

On Thu, Nov 16, 2017 at 11:50 AM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> On Thu, Nov 16, 2017 at 06:26:06AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos 
> > wrote:
> >
> > > 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
> > >
> > > > So, commit it without the error message? I really don't see the
> issue.
> > >
> > > As explained, the issue is that without an error message, it
> > > is impossible to parse any related bug report.
> >
> >
> > We've been OK with that situation so far. Since it only happens for
> fuzzed
> > files, it's OK to continue going like that.
>
> Thats not the case, the snow spec contains no limit in the place where
> we need to check. Its a natural and expected limit so likely all files
> will be within that but a file outside would still be arguably valid.
>
> So a valid file could potentially be outside this range and the
> maintainer (that being me) need to know about this.
>
> Please dont see every change that originated from a fuzzer generated
> report as only related to fuzzed files.


We are re-hashing old arguments here. I'm not really interested in that.

My review comment is and remains: please remove the log msg. Otherwise, the
patch is perfectly fine.

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


Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

2017-11-16 Thread Thilo Borgmann
Am 14.11.17 um 08:23 schrieb Umair Khan:
> Hi,
> 
> On Tue, Nov 14, 2017 at 4:05 AM, Carl Eugen Hoyos  wrote:
>> 2017-11-13 6:41 GMT+01:00 Umair Khan :
>>> Hi,
>>>
>>> On Mon, Nov 13, 2017 at 1:09 AM, Carl Eugen Hoyos  
>>> wrote:
 2017-11-12 20:30 GMT+01:00 Umair Khan :
> Hi,
>
> On Mon, Nov 13, 2017 at 12:45 AM, Carl Eugen Hoyos  
> wrote:
>> 2017-11-12 20:05 GMT+01:00 Umair Khan :
>>
>>> The attached patch fixes the address sanitizer issue.
>>
>> Breaks compilation here, how did you test?
>>
>> libavcodec/alsdec.c: In function ‘decode_var_block_data’:
>> libavcodec/alsdec.c:938:7: error: expected ‘}’ before ‘else’
>
> Sorry for the faulty patch. Here is the fixed one.

 The commit message of your patch is:
 libavcodec/als: fix address sanitization error in decoder

 Is there an error in current FFmpeg git head that asan
 shows? If not, the commit message makes no sense.

 I believe you should send two patches that are meant
 to be committed together, one of them fixing ticket #6297.
>>>
>>> This is the complete patchset.
>>
>> Bonus points for mentioning the ticket number in the
>> commit message (can be done by the committer).
>>
>> Thank you for looking into this!
> 
> I have attached the complete patch. Ticket link is mentioned in the
> commit description.

Thanks, will have a look at it asap!

-Thilo

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


Re: [FFmpeg-devel] [PATCH] configure: call flatten_extralibs in a subshell

2017-11-16 Thread Timo Rothenpieler

applied



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] movenc: write clap tag

2017-11-16 Thread Dave Rice

> On Nov 16, 2017, at 11:30 AM, Dave Rice  wrote:
> 
>> On Jul 9, 2017, at 7:26 PM, Dave Rice  wrote:
>> 
>>> On Jul 7, 2017, at 7:06 PM, Derek Buitenhuis  
>>> wrote:
>>> 
>>> On 7/7/2017 10:13 PM, James Almer wrote:
 Isn't this necessary only for files with raw video? As is, this box
 would be written on any mov file with a video stream.
>>> 
>>> This was addressed a previous email:
>>> 
>>>  http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213350.html
>>> 
>>> I guess the spec is up for interpretation.
>> 
>> The quicktime spec says "This is a mandatory extension for all uncompressed 
>> Y´CbCr data formats”. It doesn’t clarify if the clap atom is recommended or 
>> not in mov files that are not “uncompressed Y´CbCr”, though it would make 
>> sense if the video container needs to store cropping data. I think 
>> constraining the change for only  “uncompressed Y´CbCr” would be more 
>> cautious though. I’ll revise my patch to include the condition and resubmit.
>> 
>> If the patch only impacts “uncompressed Y´CbCr” would any fate updates be 
>> needed?
>> Dave Rice
> 
> Here’s an update to only write the clap atom for the specific uncompressed 
> encodings listed in TN2162.
> 
> From 37457c1ee135f39452b91b047af4adf1ec43464b Mon Sep 17 00:00:00 2001
> From: Dave Rice 
> Date: Thu, 16 Nov 2017 11:29:06 -0500
> Subject: [PATCH] avformat/movenc: write clap atom for uncompressed yuv in mov

Sorry, this patch should supersede the prior email's patch. I realized that 
Apple requires new uncompressed ycbcr files to use version 2 in the Image 
Description, so I reused the uncompressed_ycbcr variable to add that in as well.

From 3ea99e7d22f67b8a556152acbcbc8bf2eeec8a39 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Thu, 16 Nov 2017 11:29:06 -0500
Subject: [PATCH 1/2] avformat/movenc: write clap atom for uncompressed yuv in
 mov

fixes 6145
---
 libavformat/movenc.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cc3fc19d9b..98fcc7a44b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1686,6 +1686,21 @@ static int mov_write_sv3d_tag(AVFormatContext *s, 
AVIOContext *pb, AVSphericalMa
 return update_size(pb, sv3d_pos);
 }
 
+static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
+{
+avio_wb32(pb, 40);
+ffio_wfourcc(pb, "clap");
+avio_wb32(pb, track->par->width); /* apertureWidth_N */
+avio_wb32(pb, 1); /* apertureWidth_D (= 1) */
+avio_wb32(pb, track->height); /* apertureHeight_N */
+avio_wb32(pb, 1); /* apertureHeight_D (= 1) */
+avio_wb32(pb, 0); /* horizOff_N (= 0) */
+avio_wb32(pb, 1); /* horizOff_D (= 1) */
+avio_wb32(pb, 0); /* vertOff_N (= 0) */
+avio_wb32(pb, 1); /* vertOff_D (= 1) */
+return 40;
+}
+
 static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
 {
 AVRational sar;
@@ -1832,6 +1847,13 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 char compressor_name[32] = { 0 };
 int avid = 0;
 
+int uncompressed_ycbcr = ((track->par->codec_id == AV_CODEC_ID_RAWVIDEO && 
track->par->format == AV_PIX_FMT_UYVY422)
+   || (track->par->codec_id == AV_CODEC_ID_RAWVIDEO && 
track->par->format == AV_PIX_FMT_YUYV422)
+   ||  track->par->codec_id == AV_CODEC_ID_V308
+   ||  track->par->codec_id == AV_CODEC_ID_V408
+   ||  track->par->codec_id == AV_CODEC_ID_V410
+   ||  track->par->codec_id == AV_CODEC_ID_V210);
+
 avio_wb32(pb, 0); /* size */
 if (mov->encryption_scheme != MOV_ENC_NONE) {
 ffio_wfourcc(pb, "encv");
@@ -1842,7 +1864,11 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 avio_wb16(pb, 0); /* Reserved */
 avio_wb16(pb, 1); /* Data-reference index */
 
-avio_wb16(pb, 0); /* Codec stream version */
+if (uncompressed_ycbcr) {
+avio_wb16(pb, 2); /* Codec stream version */
+} else {
+avio_wb16(pb, 0); /* Codec stream version */
+}
 avio_wb16(pb, 0); /* Codec stream revision (=0) */
 if (track->mode == MODE_MOV) {
 ffio_wfourcc(pb, "FFMP"); /* Vendor */
@@ -1969,6 +1995,10 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 if (track->par->sample_aspect_ratio.den && 
track->par->sample_aspect_ratio.num) {
 mov_write_pasp_tag(pb, track);
 }
+
+if (uncompressed_ycbcr){
+mov_write_clap_tag(pb, track);
+}
 
 if (mov->encryption_scheme != MOV_ENC_NONE) {
 ff_mov_cenc_write_sinf_tag(track, pb, mov->encryption_kid);
-- 
2.15.0


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] configure: use subarch instead of arch to create .def files on mingw

2017-11-16 Thread James Almer
On 11/15/2017 11:09 PM, James Almer wrote:
> arch is "x86" regardless of target being x86_32 or x86_64, and if
> configuring with asm disabled it's "c" instead.
> Using subarch (Always either "x86_32" or "x86_64") and adapting
> makedef makes sure the symbols are always detected correctly on
> x86_32.
> ---
>  compat/windows/makedef | 2 +-
>  configure  | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)

Patch dropped, a better solution was merged.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410

2017-11-16 Thread Dave Rice
This corrects a few values in the Image Description for v210 and v410 in mov. 
Apple defines what the depth value for these uncompressed formats should be in 
https://developer.apple.com/library/content/technotes/tn2162/_index.html 
.


From 47def189b270ac93245e002580463b254daf8484 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Thu, 16 Nov 2017 11:53:32 -0500
Subject: [PATCH] avformat/movenc: correct ImageDescription depth for v210 v410

Per
https://developer.apple.com/library/content/technotes/tn2162/_index.html
.
---
 libavformat/movenc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 18232e8ba3..f7b08e2885 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1885,7 +1885,11 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 avio_w8(pb, strlen(compressor_name));
 avio_write(pb, compressor_name, 31);
 
-if (track->mode == MODE_MOV && track->par->bits_per_coded_sample)
+if (track->mode == MODE_MOV && track->par->codec_id == AV_CODEC_ID_V410)
+avio_wb16(pb, 0x18);
+else if (track->mode == MODE_MOV && track->par->codec_id == 
AV_CODEC_ID_V210)
+avio_wb16(pb, 0x18);
+else if (track->mode == MODE_MOV && track->par->bits_per_coded_sample)
 avio_wb16(pb, track->par->bits_per_coded_sample |
   (track->par->format == AV_PIX_FMT_GRAY8 ? 0x20 : 0));
 else
-- 
2.15.0

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Michael Niedermayer
On Thu, Nov 16, 2017 at 06:26:06AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos 
> wrote:
> 
> > 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
> >
> > > So, commit it without the error message? I really don't see the issue.
> >
> > As explained, the issue is that without an error message, it
> > is impossible to parse any related bug report.
> 
> 
> We've been OK with that situation so far. Since it only happens for fuzzed
> files, it's OK to continue going like that.

Thats not the case, the snow spec contains no limit in the place where
we need to check. Its a natural and expected limit so likely all files
will be within that but a file outside would still be arguably valid.

So a valid file could potentially be outside this range and the
maintainer (that being me) need to know about this.

Please dont see every change that originated from a fuzzer generated
report as only related to fuzzed files.

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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


Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning

2017-11-16 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv_vpp: fix compiling warning
> 
> 2017-11-15 10:04 GMT+01:00 Zhong Li :
> > fix the compiling warning of "ignoring return value"
> 
> > -ff_formats_ref(in_fmts, >inputs[0]->out_formats);
> > -ff_formats_ref(out_fmts, >outputs[0]->in_formats);
> > +if ((ret = ff_formats_ref(in_fmts, >inputs[0]->out_formats)) < 0)
> > +return ret;
> > +if ((ret = ff_formats_ref(out_fmts, >outputs[0]->in_formats)) <
> 0)
> 
> Two additional lines are cheap.

Just don't like any compiling warnings which may have potential issues just 
like this one.
Personally speaking, I prefer to clear most of FFmpeg compiling warnings.

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


[FFmpeg-devel] [PATCH] avcodec: Implement mpeg2 nvdec hwaccel

2017-11-16 Thread Philip Langdale
This is mostly straight-forward. The weird part is that it should
just work for mpeg1, but I see corruption in my test cases, so I'm
going to try and fix that separately.

Signed-off-by: Philip Langdale 
---
 Changelog |   2 +-
 configure |   2 +
 libavcodec/Makefile   |   1 +
 libavcodec/allcodecs.c|   1 +
 libavcodec/mpeg12dec.c|   3 +
 libavcodec/nvdec.c|  11 ++--
 libavcodec/nvdec_mpeg12.c | 153 ++
 libavcodec/version.h  |   2 +-
 8 files changed, 168 insertions(+), 7 deletions(-)
 create mode 100644 libavcodec/nvdec_mpeg12.c

diff --git a/Changelog b/Changelog
index d2b5530ad7..385fe4037c 100644
--- a/Changelog
+++ b/Changelog
@@ -13,7 +13,7 @@ version :
 - PCE support for extended channel layouts in the AAC encoder
 - native aptX encoder and decoder
 - Raw aptX muxer and demuxer
-- NVIDIA NVDEC-accelerated H.264, HEVC, VC1 and VP9 hwaccel decoding
+- NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-2, VC1 and VP9 hwaccel decoding
 - Intel QSV-accelerated overlay filter
 
 
diff --git a/configure b/configure
index 84f0a04925..1eedad208b 100755
--- a/configure
+++ b/configure
@@ -2713,6 +2713,8 @@ mpeg2_dxva2_hwaccel_deps="dxva2"
 mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
 mpeg2_mediacodec_hwaccel_deps="mediacodec"
 mpeg2_mmal_hwaccel_deps="mmal"
+mpeg2_nvdec_hwaccel_deps="nvdec"
+mpeg2_nvdec_hwaccel_select="mpeg2video_decoder"
 mpeg2_qsv_hwaccel_deps="libmfx"
 mpeg2_vaapi_hwaccel_deps="vaapi"
 mpeg2_vaapi_hwaccel_select="mpeg2video_decoder"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6315672573..494c76da76 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -854,6 +854,7 @@ OBJS-$(CONFIG_MPEG1_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
 OBJS-$(CONFIG_MPEG1_XVMC_HWACCEL) += mpegvideo_xvmc.o
 OBJS-$(CONFIG_MPEG2_D3D11VA_HWACCEL)  += dxva2_mpeg2.o
 OBJS-$(CONFIG_MPEG2_DXVA2_HWACCEL)+= dxva2_mpeg2.o
+OBJS-$(CONFIG_MPEG2_NVDEC_HWACCEL)+= nvdec_mpeg12.o
 OBJS-$(CONFIG_MPEG2_QSV_HWACCEL)  += qsvdec_other.o
 OBJS-$(CONFIG_MPEG2_VAAPI_HWACCEL)+= vaapi_mpeg2.o
 OBJS-$(CONFIG_MPEG2_VDPAU_HWACCEL)+= vdpau_mpeg12.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index e213f3757c..e0adb71951 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -96,6 +96,7 @@ static void register_all(void)
 REGISTER_HWACCEL(MPEG2_D3D11VA2,mpeg2_d3d11va2);
 REGISTER_HWACCEL(MPEG2_DXVA2,   mpeg2_dxva2);
 REGISTER_HWACCEL(MPEG2_MMAL,mpeg2_mmal);
+REGISTER_HWACCEL(MPEG2_NVDEC,   mpeg2_nvdec);
 REGISTER_HWACCEL(MPEG2_QSV, mpeg2_qsv);
 REGISTER_HWACCEL(MPEG2_VAAPI,   mpeg2_vaapi);
 REGISTER_HWACCEL(MPEG2_VDPAU,   mpeg2_vdpau);
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index d5bc5f21b2..2b213eebcd 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1141,6 +1141,9 @@ static const enum AVPixelFormat 
mpeg1_hwaccel_pixfmt_list_420[] = {
 };
 
 static const enum AVPixelFormat mpeg2_hwaccel_pixfmt_list_420[] = {
+#if CONFIG_MPEG2_NVDEC_HWACCEL
+AV_PIX_FMT_CUDA,
+#endif
 #if CONFIG_MPEG2_XVMC_HWACCEL
 AV_PIX_FMT_XVMC,
 #endif
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 20d7c3db27..3d62840e9f 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -52,11 +52,12 @@ typedef struct NVDECFramePool {
 static int map_avcodec_id(enum AVCodecID id)
 {
 switch (id) {
-case AV_CODEC_ID_H264: return cudaVideoCodec_H264;
-case AV_CODEC_ID_HEVC: return cudaVideoCodec_HEVC;
-case AV_CODEC_ID_VC1:  return cudaVideoCodec_VC1;
-case AV_CODEC_ID_VP9:  return cudaVideoCodec_VP9;
-case AV_CODEC_ID_WMV3:  return cudaVideoCodec_VC1;
+case AV_CODEC_ID_H264:   return cudaVideoCodec_H264;
+case AV_CODEC_ID_HEVC:   return cudaVideoCodec_HEVC;
+case AV_CODEC_ID_MPEG2VIDEO: return cudaVideoCodec_MPEG2;
+case AV_CODEC_ID_VC1:return cudaVideoCodec_VC1;
+case AV_CODEC_ID_VP9:return cudaVideoCodec_VP9;
+case AV_CODEC_ID_WMV3:   return cudaVideoCodec_VC1;
 }
 return -1;
 }
diff --git a/libavcodec/nvdec_mpeg12.c b/libavcodec/nvdec_mpeg12.c
new file mode 100644
index 00..a03b51dd17
--- /dev/null
+++ b/libavcodec/nvdec_mpeg12.c
@@ -0,0 +1,153 @@
+/*
+ * MPEG-2 HW decode acceleration through NVDEC
+ *
+ * Copyright (c) 2017 Philip Langdale
+ *
+ * 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 

Re: [FFmpeg-devel] [PATCH] movenc: write clap tag

2017-11-16 Thread Dave Rice

> On Jul 9, 2017, at 7:26 PM, Dave Rice  wrote:
> 
> 
>> On Jul 7, 2017, at 7:06 PM, Derek Buitenhuis  
>> wrote:
>> 
>> On 7/7/2017 10:13 PM, James Almer wrote:
>>> Isn't this necessary only for files with raw video? As is, this box
>>> would be written on any mov file with a video stream.
>> 
>> This was addressed a previous email:
>> 
>>   http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213350.html
>> 
>> I guess the spec is up for interpretation.
> 
> The quicktime spec says "This is a mandatory extension for all uncompressed 
> Y´CbCr data formats”. It doesn’t clarify if the clap atom is recommended or 
> not in mov files that are not “uncompressed Y´CbCr”, though it would make 
> sense if the video container needs to store cropping data. I think 
> constraining the change for only  “uncompressed Y´CbCr” would be more 
> cautious though. I’ll revise my patch to include the condition and resubmit.
> 
> If the patch only impacts “uncompressed Y´CbCr” would any fate updates be 
> needed?
> Dave Rice

Here’s an update to only write the clap atom for the specific uncompressed 
encodings listed in TN2162.

From 37457c1ee135f39452b91b047af4adf1ec43464b Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Thu, 16 Nov 2017 11:29:06 -0500
Subject: [PATCH] avformat/movenc: write clap atom for uncompressed yuv in mov

fixes 6145
---
 libavformat/movenc.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cc3fc19d9b..18232e8ba3 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1686,6 +1686,21 @@ static int mov_write_sv3d_tag(AVFormatContext *s, 
AVIOContext *pb, AVSphericalMa
 return update_size(pb, sv3d_pos);
 }
 
+static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
+{
+avio_wb32(pb, 40);
+ffio_wfourcc(pb, "clap");
+avio_wb32(pb, track->par->width); /* apertureWidth_N */
+avio_wb32(pb, 1); /* apertureWidth_D (= 1) */
+avio_wb32(pb, track->height); /* apertureHeight_N */
+avio_wb32(pb, 1); /* apertureHeight_D (= 1) */
+avio_wb32(pb, 0); /* horizOff_N (= 0) */
+avio_wb32(pb, 1); /* horizOff_D (= 1) */
+avio_wb32(pb, 0); /* vertOff_N (= 0) */
+avio_wb32(pb, 1); /* vertOff_D (= 1) */
+return 40;
+}
+
 static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack *track)
 {
 AVRational sar;
@@ -1970,6 +1985,16 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 mov_write_pasp_tag(pb, track);
 }
 
+int uncompressed_ycbcr = ((track->par->codec_id == AV_CODEC_ID_RAWVIDEO && 
track->par->format == AV_PIX_FMT_UYVY422)
+   || (track->par->codec_id == AV_CODEC_ID_RAWVIDEO && 
track->par->format == AV_PIX_FMT_YUYV422)
+   ||  track->par->codec_id == AV_CODEC_ID_V308
+   ||  track->par->codec_id == AV_CODEC_ID_V408
+   ||  track->par->codec_id == AV_CODEC_ID_V410
+   ||  track->par->codec_id == AV_CODEC_ID_V210);  

+if (uncompressed_ycbcr){
+mov_write_clap_tag(pb, track);
+}
+
 if (mov->encryption_scheme != MOV_ENC_NONE) {
 ff_mov_cenc_write_sinf_tag(track, pb, mov->encryption_kid);
 }
-- 
2.15.0


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


[FFmpeg-devel] [PATCH 2/2] decklink: Add support for output of Active Format Description (AFD)

2017-11-16 Thread Devin Heitmueller
Implement support for including AFD in decklink output.  This
includes making sure the AFD data is preserved when going from
an AVFrame to a V210 packet (needed for 10-bit support).

Signed-off-by: Devin Heitmueller 
---
 libavcodec/avcodec.h |  6 ++
 libavcodec/v210enc.c | 11 +++
 libavdevice/decklink_enc.cpp | 41 +++--
 3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 442b558..6981f07 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1327,6 +1327,12 @@ enum AVPacketSideDataType {
 AV_PKT_DATA_A53_CC,
 
 /**
+ * Active Format Description data consisting of a single byte as specified
+ * in ETSI TS 101 154 using AVActiveFormatDescription enum.
+ */
+AV_PKT_DATA_AFD,
+
+/**
  * The number of side data elements (in fact a bit more than it).
  * This is not part of the public API/ABI in the sense that it may
  * change when new side data types are added.
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a825c03..c28f7b1 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -245,6 +245,17 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 }
 }
 
+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_AFD);
+if (side_data && side_data->size) {
+uint8_t* buf = av_packet_new_side_data(pkt, AV_PKT_DATA_AFD, 
side_data->size);
+if (buf) {
+memcpy(buf, side_data->data, side_data->size);
+} else {
+av_log(avctx, AV_LOG_ERROR, "Unable to allocate afd side data\n");
+return AVERROR(ENOMEM);
+}
+}
+
 pkt->flags |= AV_PKT_FLAG_KEY;
 *got_packet = 1;
 return 0;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 0dcbe79..070bfad 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -280,7 +280,8 @@ av_cold int ff_decklink_write_trailer(AVFormatContext 
*avctx)
 
 #if CONFIG_LIBKLVANC
 static int decklink_construct_vanc(AVFormatContext *avctx, struct decklink_ctx 
*ctx,
-   AVPacket *pkt, decklink_frame *frame)
+   AVPacket *pkt, decklink_frame *frame,
+   AVStream *st)
 {
 struct klvanc_line_set_s vanc_lines = { 0 };
 int ret, size;
@@ -334,6 +335,42 @@ static int decklink_construct_vanc(AVFormatContext *avctx, 
struct decklink_ctx *
 }
 }
 
+data = av_packet_get_side_data(pkt, AV_PKT_DATA_AFD, );
+if (data) {
+struct klvanc_packet_afd_s *pkt;
+uint16_t *afd;
+uint16_t len;
+
+ret = klvanc_create_AFD();
+if (ret != 0)
+return AVERROR(ENOMEM);
+
+ret = klvanc_set_AFD_val(pkt, data[0]);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid AFD value specified: %d\n",
+   data[0]);
+klvanc_destroy_AFD(pkt);
+return AVERROR(EINVAL);
+}
+
+/* FIXME: Should really rely on the coded_width but seems like that
+   is not accessible to libavdevice outputs */
+if ((st->codecpar->width == 1280 && st->codecpar->height == 720) ||
+(st->codecpar->width == 1920 && st->codecpar->height == 1080))
+pkt->aspectRatio = ASPECT_16x9;
+else
+pkt->aspectRatio = ASPECT_4x3;
+
+klvanc_convert_AFD_to_words(pkt, , );
+klvanc_destroy_AFD(pkt);
+
+ret = klvanc_line_insert(ctx->vanc_ctx, _lines, afd, len, 12, 0);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "VANC line insertion failed\n");
+return AVERROR(ENOMEM);
+}
+}
+
 IDeckLinkVideoFrameAncillary *vanc;
 int result = ctx->dlo->CreateAncillaryData(bmdFormat10BitYUV, );
 if (result != S_OK) {
@@ -429,7 +466,7 @@ static int decklink_write_video_packet(AVFormatContext 
*avctx, AVPacket *pkt)
 frame = new decklink_frame(ctx, avpacket, st->codecpar->codec_id, 
ctx->bmd_height, ctx->bmd_width);
 
 #if CONFIG_LIBKLVANC
-ret = decklink_construct_vanc(avctx, ctx, pkt, frame);
+ret = decklink_construct_vanc(avctx, ctx, pkt, frame, st);
 if (ret != 0) {
 av_log(avctx, AV_LOG_ERROR, "Failed to construct VANC\n");
 }
-- 
1.8.3.1

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


[FFmpeg-devel] [PATCH 1/2] libavdevice/decklink: Add support for EIA-708 output over SDI

2017-11-16 Thread Devin Heitmueller
Hook in libklvanc and use it for output of EIA-708 captions over
SDI.  The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.

Libklvanc can be found at: https://github.com/stoth68000/libklvanc

Updated to reflect feedback from Marton Balint 

Signed-off-by: Devin Heitmueller 
---
 configure   |   4 ++
 libavcodec/v210enc.c|  12 
 libavdevice/decklink_common.cpp |  17 +++--
 libavdevice/decklink_common.h   |  10 +++
 libavdevice/decklink_enc.cpp| 150 ++--
 5 files changed, 183 insertions(+), 10 deletions(-)

diff --git a/configure b/configure
index 934ac3a..d5e3dcc 100755
--- a/configure
+++ b/configure
@@ -238,6 +238,7 @@ External library support:
   --enable-libiec61883 enable iec61883 via libiec61883 [no]
   --enable-libilbc enable iLBC de/encoding via libilbc [no]
   --enable-libjack enable JACK audio sound server [no]
+  --enable-libklvanc   enable Kernel Labs VANC processing [no]
   --enable-libkvazaar  enable HEVC encoding via libkvazaar [no]
   --enable-libmodplug  enable ModPlug via libmodplug [no]
   --enable-libmp3lame  enable MP3 encoding via libmp3lame [no]
@@ -1602,6 +1603,7 @@ EXTERNAL_LIBRARY_LIST="
 libiec61883
 libilbc
 libjack
+libklvanc
 libkvazaar
 libmodplug
 libmp3lame
@@ -3076,6 +3078,7 @@ decklink_deps_any="libdl LoadLibrary"
 decklink_indev_deps="decklink threads"
 decklink_indev_extralibs="-lstdc++"
 decklink_outdev_deps="decklink threads"
+decklink_outdev_suggest="libklvanc"
 decklink_outdev_extralibs="-lstdc++"
 libndi_newtek_indev_deps="libndi_newtek"
 libndi_newtek_indev_extralibs="-lndi"
@@ -5847,6 +5850,7 @@ enabled libgsm&& { for gsm_hdr in "gsm.h" 
"gsm/gsm.h"; do
check_lib libgsm "${gsm_hdr}" gsm_create 
-lgsm && break;
done || die "ERROR: libgsm not found"; }
 enabled libilbc   && require libilbc ilbc.h WebRtcIlbcfix_InitDecode 
-lilbc $pthreads_extralibs
+enabled libklvanc && require libklvanc libklvanc/vanc.h 
klvanc_context_create -lklvanc
 enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 0.8.1" 
kvazaar.h kvz_api_get
 # While it may appear that require is being used as a pkg-config
 # fallback for libmfx, it is actually being used to detect a different
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a6afbbf..a825c03 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -123,6 +123,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 int aligned_width = ((avctx->width + 47) / 48) * 48;
 int stride = aligned_width * 8 / 3;
 int line_padding = stride - ((avctx->width * 8 + 11) / 12) * 4;
+AVFrameSideData *side_data;
 int h, w, ret;
 uint8_t *dst;
 
@@ -233,6 +234,17 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 }
 }
 
+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
+if (side_data && side_data->size) {
+uint8_t* buf = av_packet_new_side_data(pkt, AV_PKT_DATA_A53_CC, 
side_data->size);
+if (buf) {
+memcpy(buf, side_data->data, side_data->size);
+} else {
+av_log(avctx, AV_LOG_ERROR, "Unable to allocate side data\n");
+return AVERROR(ENOMEM);
+}
+}
+
 pkt->flags |= AV_PKT_FLAG_KEY;
 *got_packet = 1;
 return 0;
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 2bd63ac..c425f4a 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -247,10 +247,19 @@ int ff_decklink_set_format(AVFormatContext *avctx,
, NULL) != S_OK)
 return -1;
 } else {
-if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
-   bmdVideoOutputFlagDefault,
-   , NULL) != S_OK)
-return -1;
+ctx->supports_vanc = 1;
+if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, (BMDPixelFormat) 
ctx->raw_format,
+   bmdVideoOutputVANC,
+   , NULL) != S_OK) {
+/* Try again, but without VANC enabled */
+if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, (BMDPixelFormat) 
ctx->raw_format,
+   bmdVideoOutputFlagDefault,
+   , NULL) != S_OK) {
+return -1;
+}
+ctx->supports_vanc = 0;
+}
+
 }
 if (support == bmdDisplayModeSupported)
 return 0;
diff --git a/libavdevice/decklink_common.h 

[FFmpeg-devel] [PATCHv2 0/2] Add support for EIA-708/AFD on decklink output

2017-11-16 Thread Devin Heitmueller
This patch series hooks in the libklvanc library to provide support
of output for EIA-708 and AFD packets over SDI output.

Patch 1 reflects feedback from Marton Balint 

Devin Heitmueller (2):
  libavdevice/decklink: Add support for EIA-708 output over SDI
  decklink: Add support for output of Active Format Description (AFD)

 configure   |   4 +
 libavcodec/avcodec.h|   6 ++
 libavcodec/v210enc.c|  23 +
 libavdevice/decklink_common.cpp |  17 +++-
 libavdevice/decklink_common.h   |  10 +++
 libavdevice/decklink_enc.cpp| 187 ++--
 6 files changed, 237 insertions(+), 10 deletions(-)

-- 
1.8.3.1

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


Re: [FFmpeg-devel] [PATCH 09/11] avformat/swfenc: use FFABS to instead of abs

2017-11-16 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 03:45:03PM +0800, Steven Liu wrote:
> Signed-off-by: Steven Liu 
> ---
>  libavformat/swfenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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


Re: [FFmpeg-devel] [PATCH 05/11] avformat/mp3dec: use FFABS to instead of abs

2017-11-16 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 03:44:17PM +0800, Steven Liu wrote:
> Signed-off-by: Steven Liu 
> ---
>  libavformat/mp3dec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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


Re: [FFmpeg-devel] [PATCH 07/11] avformat/mxf: use FFABS to instead of abs

2017-11-16 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 03:44:39PM +0800, Steven Liu wrote:
> Signed-off-by: Steven Liu 
> ---
>  libavformat/mxf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 04/11] avformat/mov: use FFABS to instead of fabs

2017-11-16 Thread Michael Niedermayer
On Wed, Nov 15, 2017 at 03:44:11PM +0800, Steven Liu wrote:
> Signed-off-by: Steven Liu 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Iam not sure FFABS should be used with floats
the multiple evaluation in it can lead to interresting results
like FFABS() being slightly negative

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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


Re: [FFmpeg-devel] [PATCH]lavf/mxfenc: Support 60fps output

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 1:27 PM, Carl Eugen Hoyos wrote:
> This was successfully tested so I will push if there are no objections.

Seems harmless enough if it isn't violating some spec (it is MXF after all...)

If someone had objections, they would have responded by now, probably.

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


Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

2017-11-16 Thread Paul B Mahol
On 11/16/17, Carl Eugen Hoyos  wrote:
> 2017-11-16 13:47 GMT+01:00 Richard Ling :
>
>> I created a new patch based on the feedback from Nicolas, but I was
>> not able to get Gmail to send it back to me without mangling it.
>
>> According to the answer at the bottom of
>> https://stackoverflow.com/questions/6535761/how-to-email-patches-formatted-with-git-format-patch
>> it is not possible to send git patches with gmail due to their broken
>> mailer.
>
> It works fine here on an ancient browser.

So you are telling that you use ancient browser with all known
security flaws fixed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/mxfenc: Support 60fps output

2017-11-16 Thread Carl Eugen Hoyos
2017-10-31 0:22 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Kasper Folman has reported that FFmpeg does not write 60fps
> mxf output and has provided a 60fps mxf file on -users.
>
> Attached patch allows 60fps output.

This was successfully tested so I will push if there are no objections.

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: checking return value of avio_open_dyn_buf

2017-11-16 Thread Derek Buitenhuis
On 11/16/2017 2:53 AM, Steven Liu wrote:
> fix CID: 1421196
> 
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Should be OK if it passes valgrind.

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


Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

2017-11-16 Thread Martin Vignali
Hello,


> Maybe there's some other way to send a patch (base64, attached zip file,
> ???)
>
> 
>

https://ffmpeg.org/git-howto.html#Preparing-a-patchset

try git format-patch origin/master
and put in attach the file(s)

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


Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

2017-11-16 Thread Carl Eugen Hoyos
2017-11-16 13:47 GMT+01:00 Richard Ling :

> I created a new patch based on the feedback from Nicolas, but I was
> not able to get Gmail to send it back to me without mangling it.

> According to the answer at the bottom of
> https://stackoverflow.com/questions/6535761/how-to-email-patches-formatted-with-git-format-patch
> it is not possible to send git patches with gmail due to their broken
> mailer.

It works fine here on an ancient browser.

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


Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

2017-11-16 Thread Richard Ling
On 24 October 2017 at 07:26, Paul B Mahol  wrote:
> On 9/14/17, Richard Ling  wrote:
>> Hi,
>>
>> This patch adds a filter to normalize (contrast stretch) RGB video.
>> Comments welcome.
>>
>> R.
>
> What's status of this?

I created a new patch based on the feedback from Nicolas, but I was
not able to get Gmail to send it back to me without mangling it.
According to the answer at the bottom of
https://stackoverflow.com/questions/6535761/how-to-email-patches-formatted-with-git-format-patch
it is not possible to send git patches with gmail due to their broken
mailer.
So I just set it aside.

Maybe there's some other way to send a patch (base64, attached zip file, ???)

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


Re: [FFmpeg-devel] FFmpeg 3.4.1

2017-11-16 Thread Carl Eugen Hoyos
2017-11-16 13:44 GMT+01:00 Michael Niedermayer :
> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
>> > Hi all
>> >
>> > I intend to make 3.4.1 very soon
>>
>> Shouldn't we first decide on how to proceed with #6775?
>
> This would be ideal.
>
> IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04

This was confirmed by more than one developer, yes.

> I see a patch that is said to improve 6775, can that be applied and
> would that resolve this ?

Iiuc, it would not completely resolve the issue, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536

> If so why was it not applied yet ?

The patch did not get support here, see:
[FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
in compat_decode

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


Re: [FFmpeg-devel] FFmpeg 3.4.1

2017-11-16 Thread Michael Niedermayer
On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer :
> > Hi all
> >
> > I intend to make 3.4.1 very soon
> 
> Shouldn't we first decide on how to proceed with #6775?

This would be ideal.

IIUC this is a regression from bddb2343b6e594e312dadb5d21b408702929ae04

I see a patch that is said to improve 6775, can that be applied and
would that resolve this ?
If so why was it not applied yet ?


Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

2017-11-16 Thread Jeyapal, Karthick
>On 11/16/17, 4:43 PM, "Nicolas George"  wrote:

Thanks for the reply.

>I think that would work, thanks.
>
>But I see that in the other patches you call ffio_geturlcontext()
>without checking its return value. That is not good at all, and that
>would make Coverity squirm.
>
>If you are sure that you are always calling it with a real URLContext,
>then make the test an av_assert0(). I think it is the case. Otherwise,
>you need to check the return value.

I have done the change as suggested. Please find the new patch attached.

>Also, I see the other patch calling prot->url_write directly: I think it
>should call ffurl_write() instead.

I need to send ‘0’ byte http packet to indicate close.
But ffurl_write doesn’t call http_write for a 0 byte packet.
Hence, I am calling prot->url_write directly. 

>Regards,
>
>-- 
>  Nicolas George

Regards,
Karthick



0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
Description: 0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] fateserver/index: clean chars in sort parameter

2017-11-16 Thread Michael Niedermayer
On Mon, Oct 16, 2017 at 10:36:04PM +0200, Michael Niedermayer wrote:
> Prevents cross site scripting attack
> 
> Found-by: Pankaj Jadhav 
> Signed-off-by: Michael Niedermayer 
> ---
>  index.cgi | 2 ++
>  1 file changed, 2 insertions(+)

patch applied

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

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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


Re: [FFmpeg-devel] [PATCH] fateserver/log: clean chars in slot, time and log

2017-11-16 Thread Michael Niedermayer
On Tue, Oct 17, 2017 at 06:12:13PM +0200, Michael Niedermayer wrote:
> Fixes: Directory Traversal
> 
> Found-by: Pankaj Jadhav 
> Signed-off-by: Michael Niedermayer 
> ---
>  log.cgi | 4 
>  1 file changed, 4 insertions(+)

patch applied

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Ronald S. Bultje
Hi,

On Wed, Nov 15, 2017 at 10:15 PM, Carl Eugen Hoyos 
wrote:

> 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
>
> > So, commit it without the error message? I really don't see the issue.
>
> As explained, the issue is that without an error message, it
> is impossible to parse any related bug report.


We've been OK with that situation so far. Since it only happens for fuzzed
files, it's OK to continue going like that.

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


Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

2017-11-16 Thread Nicolas George
Le sextidi 26 brumaire, an CCXXVI, Jeyapal, Karthick a écrit :
> Thanks for the feedback. I have a relevant condition check so that
> only a real URLContext is returned.
> Please find the new patch attached.

I think that would work, thanks.

But I see that in the other patches you call ffio_geturlcontext()
without checking its return value. That is not good at all, and that
would make Coverity squirm.

If you are sure that you are always calling it with a real URLContext,
then make the test an av_assert0(). I think it is the case. Otherwise,
you need to check the return value.

Also, I see the other patch calling prot->url_write directly: I think it
should call ffurl_write() instead.

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 3/3] avformat/opensrt: add Haivision Open SRT protocol

2017-11-16 Thread Nicolas George
Le decadi 20 brumaire, an CCXXVI, nablet developer a écrit :
> the idea is to avoid code duplication as much as possible, and try to re-use
> existing, well-maintained and well-tested code.
> this time I've chosen tcp.c rather udp.c for two reasons:
> 1. SRT socket API actually resembles tcp, as it uses connection and related
> methods (connect/listen/accept)
> 2. tcp.c code is much more clean and straightforward rather udp.c
> the first thing which obviously differs between tcp and srt are socket api
> calls, but there is direct mapping for most of them, e.g.:
> socket -> srt_socket
> connect -> srt_connect
> listen -> srt_listen
> very few of srt socket calls are different, e.g. srt doesn't provide
> send/recv, but provides sendmsg/recvmsg, also it doesn't provide poll, but
> has epoll_wait.
> with simple wrappers, it allows to use existing logic of tcp.c and network.c
> without modifications.
> for calling back srt from tcp, that's the second difference - srt has lots
> of additional socket options,
> and some of these socket options has to be set prior to connection, others
> after connection (called pre and post options in srt).
> Haivision explicitly requested to add these options into ffmpeg component.
> so, there are two calls back in tcp_open - to set options just before
> connection, and to set options right after connections.
> if you have some advice on how it can be implemented better, I am open for
> suggestions and advises.

Thanks for explaining. I think it is not the best decision.

The reason the socket API resembles TCP is because all the sockets API
resemble each other, since they are based on the old BSD socket API. And
the protocol handlers of libavformat too.

Therefore, I think all the trampoline code to allow TCP to call back
another protocol plus all the boilerplate code that you need to make
opensrc callable from TCP amounts to worse than implementing a protocol
directly.

Furthermore, TCP is the most important network protocol for now, while
opensrt is still rather obscure, so tying one with the other is not a
good idea.

Also, implementing a real protocol from scratch would possibly allow you
to make use of extra features of the opensrt API: maybe they have a
read-with-timeout function, for example, or something like that.

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] avfilter/vf_cropdetect: change license to LGPL

2017-11-16 Thread Clément Bœsch
On Tue, Nov 14, 2017 at 02:35:39PM -0800, Aman Gupta wrote:
[...]
> The import into ffmpeg was done by Stefano Sabatini. It was then touched by 
> the following
> contributors, who specifically made changes to the filter. This does not 
> include
> commits which changed this file but were part of larger refactorings that 
> changed
> lavfi APIs and other LGPL filters as well. See
> https://github.com/FFmpeg/FFmpeg/commits/master/libavfilter/vf_cropdetect.c
> 
>   Stefano Sabatini
>   Michael Niedermayer
>   Anton Khirnov
>   Clément Bœsch
>   Paul B Mahol
>   Carl Eugen Hoyos
>   Vittorio Giovara
>   Ganesh Ajjanagadde
> 
> The people above are CC'd on this patch for their permission to relicense 
> vf_cropdetect as LGPL.

Sure, OK for me.

You need to update LICENSE.md btw.

-- 
Clément B.


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


Re: [FFmpeg-devel] [PATCH] configure: call flatten_extralibs in a subshell

2017-11-16 Thread Timo Rothenpieler

will push soon if nobody objects



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] vf_zscale: Add more supported input properties

2017-11-16 Thread Paul B Mahol
On 11/15/17, Carl Eugen Hoyos  wrote:
> 2017-11-15 17:26 GMT+01:00 Vittorio Giovara :
>
>> There is a stable release with this code, and it's a minor update,
>> not sure if it warrants a configure check, but I'll add it if requested.
>
> Does it compile without? Does configure succeed?
>
> The patch must not lead to a situation where configure
> passes but build fails.

Just raise accepted zimg version.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/snowdec: Check intra block dc differences.

2017-11-16 Thread Paul B Mahol
On 11/16/17, Carl Eugen Hoyos  wrote:
> 2017-11-16 4:06 GMT+01:00 Ronald S. Bultje :
>
>> So, commit it without the error message? I really don't see the issue.
>
> As explained, the issue is that without an error message, it
> is impossible to parse any related bug report.
>
> Carl Eugen

Like you will get any useful bug report for snow anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avfilter/vf_cropdetect: change license to LGPL

2017-11-16 Thread Paul B Mahol
On 11/15/17, Carl Eugen Hoyos  wrote:
> 2017-11-14 23:35 GMT+01:00 Aman Gupta :
>> From: Aman Gupta 
>>
>> This filter was imported from mplayer's libmpcodecs/vf_cropdetect.c, and
>> marked as GPL when originally copied over.
>>
>> On the mplayer side, it was authored originally by arpi and subsequently
>> touched by
>> the following contributors. See
>> https://github.com/pigoz/mplayer-svn/commits/master/libmpcodecs/vf_cropdetect.c
>>
>>   arpi
>>   albeu
>>   diego
>>   reimar
>>   michael
>>   reynaldo
>>   lucabe
>>   cehoyos
>
> This list looks incomplete;-(

You are living genius.

>
> 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] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-16 Thread 刘歧

> 在 2017年11月16日,17:28,Bang He  写道:
> 
> how to use the feature
1st, apply the patch into your ffmpeg project,
2nd, use the command looks like bellow:

./ffmpeg -f lavfi -i color=red -f lavfi –I anullsrc -g 25 -r 25 -b:v:0 1000k 
-b:v:1 256k -b:a:1 64k -b:a:1 32k  -map 0:v -map 1:a -map 0:v -map 1:a -f hls 
-var_stream_map "v:0,a:0  v:1,a:1" -master_pl_name  master.m3u8 -t 10 -hls_time 
2 output_sl.m3u8


> 
> On Thu, Nov 16, 2017 at 5:10 PM, 刘歧  wrote:
> 
>> 
>>> 在 2017年11月16日,17:01,Dixit, Vishwanath  写道:
>>> 
>>> 
>>> 
 On 11/16/17, 12:09 PM, "刘歧"  wrote:
 
 FATE test passed:  Ubuntu, OS X, qemu+MIPS Linux,  wine MingW,
>> qemu+ARM Linux, Thanks.
 
 +if (p) {
 +strcpy(extension, p);
 What about use av_strlcpy ?
 
 +while (q < varstr + strlen(varstr)) {
 +if (!strncmp(q, "a:", 2) || !strncmp(q, "v:", 2) ||
 +!strncmp(q, "s:", 2))
 What about use av_strcasecmp ?
 
 +} else {
 +av_log(s, AV_LOG_ERROR, "Invalid keyval %s\n",
>> keyval);
 +return -1;
 What about use return AVERROR(EINVAL)?
 
 +} else {
 +av_log(s, AV_LOG_ERROR, "Unable to map stream at
>> %s\n", keyval);
 +return -1;
 same as above.
 
 +strrchr(master_url, '\\');
 +if (p) {
 +base_len = abs(p - master_url);
 use FFABS
 
 +if (strncmp(master_url, media_url, base_len)) {
 use av_strcasecmp
>>> 
>>> I have made updates for all the review comments. Please find the updated
>> patch set in the attachment.
>>> 
>>> 
>>> <0001-avformat-hlsenc-creation-of-hls-variant-streams-in-a.patch><0002-
>> avformat-hlsenc-creation-of-hls-master-playlist-file.
>> patch><0003-tests-fate-addition-of-test-case-for-hls-
>> variant-str.patch>___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> Patchset LGTM, i will apply these patch after 24 hours if there have no
>> objections
>> 
>> Thanks
>> 
>> 
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-16 Thread Bang He
how to use the feature

On Thu, Nov 16, 2017 at 5:10 PM, 刘歧  wrote:

>
> > 在 2017年11月16日,17:01,Dixit, Vishwanath  写道:
> >
> >
> >
> >> On 11/16/17, 12:09 PM, "刘歧"  wrote:
> >>
> >>   FATE test passed:  Ubuntu, OS X, qemu+MIPS Linux,  wine MingW,
> qemu+ARM Linux, Thanks.
> >>
> >> +if (p) {
> >>   +strcpy(extension, p);
> >>   What about use av_strlcpy ?
> >>
> >> +while (q < varstr + strlen(varstr)) {
> >>  +if (!strncmp(q, "a:", 2) || !strncmp(q, "v:", 2) ||
> >>  +!strncmp(q, "s:", 2))
> >>  What about use av_strcasecmp ?
> >>
> >> +} else {
> >>   +av_log(s, AV_LOG_ERROR, "Invalid keyval %s\n",
> keyval);
> >>   +return -1;
> >>   What about use return AVERROR(EINVAL)?
> >>
> >> +} else {
> >>  +av_log(s, AV_LOG_ERROR, "Unable to map stream at
> %s\n", keyval);
> >>  +return -1;
> >>  same as above.
> >>
> >> +strrchr(master_url, '\\');
> >>   +if (p) {
> >>   +base_len = abs(p - master_url);
> >>   use FFABS
> >>
> >>  +if (strncmp(master_url, media_url, base_len)) {
> >>  use av_strcasecmp
> >
> > I have made updates for all the review comments. Please find the updated
> patch set in the attachment.
> >
> >
> > <0001-avformat-hlsenc-creation-of-hls-variant-streams-in-a.patch><0002-
> avformat-hlsenc-creation-of-hls-master-playlist-file.
> patch><0003-tests-fate-addition-of-test-case-for-hls-
> variant-str.patch>___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> Patchset LGTM, i will apply these patch after 24 hours if there have no
> objections
>
> Thanks
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-16 Thread 刘歧

> 在 2017年11月16日,17:15,Dixit, Vishwanath  写道:
> 
> 
>> On 11/16/17, 2:41 PM, "刘歧"  wrote:
>> 
>>   Patchset LGTM, i will apply these patch after 24 hours if there have no 
>> objections
> Thank you for the approval..
This is an awesome function, it is very useful :D
> 
> ___
> 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] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-16 Thread Dixit, Vishwanath

>On 11/16/17, 2:41 PM, "刘歧"  wrote:
>
>Patchset LGTM, i will apply these patch after 24 hours if there have no 
> objections
Thank you for the approval..

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

2017-11-16 Thread 刘歧

> 在 2017年11月16日,17:01,Dixit, Vishwanath  写道:
> 
> 
> 
>> On 11/16/17, 12:09 PM, "刘歧"  wrote:
>> 
>>   FATE test passed:  Ubuntu, OS X, qemu+MIPS Linux,  wine MingW, qemu+ARM 
>> Linux, Thanks.
>> 
>> +if (p) {
>>   +strcpy(extension, p);
>>   What about use av_strlcpy ?
>> 
>> +while (q < varstr + strlen(varstr)) {
>>  +if (!strncmp(q, "a:", 2) || !strncmp(q, "v:", 2) ||
>>  +!strncmp(q, "s:", 2))
>>  What about use av_strcasecmp ?
>> 
>> +} else {
>>   +av_log(s, AV_LOG_ERROR, "Invalid keyval %s\n", keyval);
>>   +return -1;
>>   What about use return AVERROR(EINVAL)?
>> 
>> +} else {
>>  +av_log(s, AV_LOG_ERROR, "Unable to map stream at %s\n", 
>> keyval);
>>  +return -1;
>>  same as above.
>> 
>> +strrchr(master_url, '\\');
>>   +if (p) {
>>   +base_len = abs(p - master_url);
>>   use FFABS
>> 
>>  +if (strncmp(master_url, media_url, base_len)) {
>>  use av_strcasecmp
> 
> I have made updates for all the review comments. Please find the updated 
> patch set in the attachment.
> 
> 
> <0001-avformat-hlsenc-creation-of-hls-variant-streams-in-a.patch><0002-avformat-hlsenc-creation-of-hls-master-playlist-file.patch><0003-tests-fate-addition-of-test-case-for-hls-variant-str.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Patchset LGTM, i will apply these patch after 24 hours if there have no 
objections

Thanks



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


Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

2017-11-16 Thread Jeyapal, Karthick
>On 11/16/17, 1:11 AM, "Marton Balint"  wrote:

Thanks for the reply.

>For the first patch, I think you forgot to call ff_decklink_set_configs in 
>decklink_enc.
ff_decklink_set_configs is not doing anything related to decklink_enc
In any case I have added the same and have attached the new patch

>For the second patch here are some comments:
I have done all suggested modifications and the new patch is attached.

>Regards,
>Marton

Regards,
Karthick



0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch
Description: 0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch


0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
Description: 0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add tune-content option

2017-11-16 Thread James Zern
On Nov 14, 2017 18:53, "James Zern"  wrote:

On Mon, Nov 13, 2017 at 6:05 PM, James Zern  wrote:
> On Mon, Nov 13, 2017 at 4:43 PM, James Almer  wrote:
>> On 11/13/2017 9:01 PM, James Zern wrote:
>>> Signed-off-by: James Zern 
>>> ---
>>>  doc/encoders.texi  |  2 ++
>>>  libavcodec/libvpxenc.c | 20 
>>>  2 files changed, 22 insertions(+)
>>>
>>> diff --git a/doc/encoders.texi b/doc/encoders.texi
>>> index 431777c457..23451b7b92 100644
>>> --- a/doc/encoders.texi
>>> +++ b/doc/encoders.texi
>>> @@ -1681,6 +1681,8 @@ colorspaces:
>>>  @end table
>>>  @item row-mt @var{boolean}
>>>  Enable row based multi-threading.
>>> +@item tune-content
>>
>> How about "tune" instead? That's what libx264 and libx265 use.
>>
>
> Unfortunately that exists too (psnr/ssim), this was forked for vp9 [1].
>

That one is mapped already too [2]. Recently we've been trying to
match the vpxenc options.


Any more comments on this one?


> [1] https://chromium.googlesource.com/webm/libvpx/+/v1.6.1/vpx/vp8cx.h#765
>

[2] https://github.com/FFmpeg/FFmpeg/blob/release/3.4/
libavcodec/libvpxenc.c#L1096

>> Also, it may be a good time to resurrect your patch to bump the minimum
>> required version to 1.4.0, to clean some of the oldest ifdeffery. Debian
>> stable ships 1.6.1 now.
>>
>
> I can bring up the minimum in a followup if it's a good time.
>
>>> +Set content type: default (0), screen (1), film (2).
>>>  @end table
>>>
>>>  @end table
>>> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
>>> index d720301cd1..fbb842499b 100644
>>> --- a/libavcodec/libvpxenc.c
>>> +++ b/libavcodec/libvpxenc.c
>>> @@ -109,6 +109,7 @@ typedef struct VPxEncoderContext {
>>>  int vpx_cs;
>>>  float level;
>>>  int row_mt;
>>> +int tune_content;
>>>  } VPxContext;
>>>
>>>  /** String mappings for enum vp8e_enc_control_id */
>>> @@ -143,6 +144,9 @@ static const char *const ctlidstr[] = {
>>>  #ifdef VPX_CTRL_VP9E_SET_ROW_MT
>>>  [VP9E_SET_ROW_MT]  = "VP9E_SET_ROW_MT",
>>>  #endif
>>> +#ifdef VPX_CTRL_VP9E_SET_TUNE_CONTENT
>>> +[VP9E_SET_TUNE_CONTENT]= "VP9E_SET_TUNE_CONTENT",
>>> +#endif
>>>  #endif
>>>  };
>>>
>>> @@ -709,6 +713,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>>  #ifdef VPX_CTRL_VP9E_SET_ROW_MT
>>>  if (ctx->row_mt >= 0)
>>>  codecctl_int(avctx, VP9E_SET_ROW_MT, ctx->row_mt);
>>> +#endif
>>> +#ifdef VPX_CTRL_VP9E_SET_TUNE_CONTENT
>>> +if (ctx->tune_content >= 0)
>>> +codecctl_int(avctx, VP9E_SET_TUNE_CONTENT,
ctx->tune_content);
>>>  #endif
>>>  }
>>>  #endif
>>> @@ -1139,6 +1147,18 @@ static const AVOption vp9_options[] = {
>>>  #endif
>>>  #ifdef VPX_CTRL_VP9E_SET_ROW_MT
>>>  {"row-mt", "Row based multi-threading", OFFSET(row_mt),
AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>>> +#endif
>>> +#ifdef VPX_CTRL_VP9E_SET_TUNE_CONTENT
>>> +#if VPX_ENCODER_ABI_VERSION >= 14
>>> +{ "tune-content","Tune content type", OFFSET(tune_content),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE, "tune_content" },
>>> +#else
>>> +{ "tune-content","Tune content type", OFFSET(tune_content),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE, "tune_content" },
>>> +#endif
>>> +{ "default", "Regular video content",  0,
AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 0, VE, "tune_content" },
>>> +{ "screen",  "Screen capture content", 0,
AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, VE, "tune_content" },
>>> +#if VPX_ENCODER_ABI_VERSION >= 14
>>> +{ "film","Film content; improves grain retention", 0,
AV_OPT_TYPE_CONST, {.i64 = 2}, 0, 0, VE, "tune_content" },
>>> +#endif
>>>  #endif
>>>  LEGACY_OPTIONS
>>>  { NULL }
>>>
>>
>> ___
>> 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]lavf/matroskaenc: Do not write 0 duration for subtitles

2017-11-16 Thread Jerome Martinez

On 12/11/2017 03:12, Carl Eugen Hoyos wrote:

The matroska spec says blockduration == 0 means the frame is not a
keyframe.  Since all subtitles are "keyframes", 0 blockduration should
not be written.


The issue is in the specifications:
https://github.com/Matroska-Org/matroska-specification/pull/207

The patch should not be integrated as the reason is no more valid.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel