Re: [FFmpeg-devel] TR-03 implementation

2016-11-12 Thread Carlos Fernandez Sanz 
On Sat, Nov 12, 2016 at 8:17 PM, Ali KIZIL  wrote:

> If someone wants to try, he can give a try, release a patch, it can be
> discussed in a discussion level. I really find saying such comments like "
> We don't need more broadcasting shit in ffmpeg." and "and it is why
> FFmpeg is full of broken things and has a bad name in the professional
> world." annoying. Frankly speaking, as my own, I start to think maybe some
> people try to give intentional directions to FFmpeg.
>
And rumor has it, want to the broadcasting industry to other products.

One of the reasons apparently for not merging the SCTE-35 patch;
better never include that in ffmpeg and have the professional use and
pay for other products even though an implementation that doesn't
break anything at that has been revised 14 times has been posted here.

Reason not to merge? None, that just it "doesn't belong to FFmpeg".
And trying to merge it is not mature.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

2016-11-12 Thread Ali KIZIL 
2016-11-11 0:24 GMT+03:00 Kieran Kunhya :

> >
> > sure, ffmpeg has support for many pixel formats and adding more
> > pixfmts is not a problem.
> >
> > my best answer would be to look at commits which add other pixel
> > formats and just follow how they were added to libswscale. make some
> > fate tests, and it should be done.
> >
> > hopefully you have test samples made of these pixfmts you want to add.
> > that makes testing for us easier, as we can test on multiple cpu
> > arch's to make sure the code is safe and works.
> >
>
> Sorry Compn, nothing personal here, but you are responding exactly in the
> way I thought you would and why I even wrote that certain people would
> encourage in spite of the technical issues.
>
> You don't understand the complexity of this problem either. The pixel
> formats are the least of his problems. Samples don't exist, it's not a file
> based format, it's a network stream etc. Please listen to what Ros and I
> said, we worked on this painfully for months.
>
> Regards,
> Kieran
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hi all,

I very rarely send patches to FFmpeg. Maybe I am the last one in the row to
say something about the topic, but I belive it is not good idea to break
motivation of contributors even the idea is good or bad or wrong.

If someone wants to try, he can give a try, release a patch, it can be
discussed in a discussion level. I really find saying such comments like "
We don't need more broadcasting shit in ffmpeg." and "and it is why
FFmpeg is full of broken things and has a bad name in the professional
world." annoying. Frankly speaking, as my own, I start to think maybe some
people try to give intentional directions to FFmpeg.

Belive me; Cisco, Ateme, Siemens etc. use FFmpeg in their products and
solutions. For me, FFmpeg is great as its contributors.

-

A part from the topic; there are several useful patches released but not
applied yet, such as:

https://trac.ffmpeg.org/attachment/ticket/4155/underflow_overflow_fix.diff
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/194856.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202587.html

I wanted to mention this under contributor's motivation sunbjec, maybe
https://patchwork.ffmpeg.org can be used to upload missed patches.

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

Re: [FFmpeg-devel] [Patch] hwaccel transocode broken

2016-11-12 Thread Ali KIZIL 
2016-11-11 14:47 GMT+03:00 Yogender Gupta :

> >>These are merges. Unless you volunteer to do the merges yourself (and
> properly please) you'll have to live with this.
>
> So were there merges that got left and broke the functionality. When do we
> get these merges in ? Please let me know if I can help get this up and
> fixed. There have been various people blocked on this, as  this is a
> functionality broken rather than being a simple bug.
>
> Thanks,
> Yogender
>
>
>
> 
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> 
> ---
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hi all,

I tested the patch, it fixes the broken. Maybe Timo can push the patch ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu: Add AVSphericalMapping type and frame side data

2016-11-12 Thread Vittorio Giovara 
On Sat, Nov 12, 2016 at 6:11 PM, Michael Niedermayer
 wrote:
> Hi
>
> On Sat, Nov 12, 2016 at 12:30:52PM -0500, Vittorio Giovara wrote:
>> On Sat, Nov 12, 2016 at 9:41 AM, James Almer  wrote:
>> > On 11/11/2016 10:39 PM, Michael Niedermayer wrote:
>> >> On Fri, Nov 11, 2016 at 05:49:00PM -0500, Vittorio Giovara wrote:
> [...]
>> >>
>> >>> +double yaw;   ///< Clockwise rotation around the up vector [-180, 
>> >>> 180].
>> >>> +double pitch; ///< Counter-clockwise rotation around the right 
>> >>> vector [-90, 90].
>> >>> +double roll;  ///< Counter-clockwise rotation around the forward 
>> >>> vector [-180, 180].
>> >>
>> >> please use intXY (64 or 32 as preferred) so there are no platform
>> >> rounding dependancies
>>
>> These are rotation angles which are inherently floating point, and
>
> Theres nothing inherently floating point on an angle.

Err not sure where you get that from, but it is very common for
rotation to be represented in floating point, whether you express it
in degrees (and thus real numbers, which include fractional values
such as 90.5º, expressed as floating point in computing) and in
radians where you literally use PI (which is an irrational numerical
constant, again expressed as floating point in computing).

>> consistent with what other rotation-related APIs export (eg.
>> av_display_matrix_rotation_get()).
>
>> Besides using intXX would lose
>> precision that the original specification offers.
>
> int64_t has about a thousand times higher precission than a double
> for storing general -180°..+180° angles. This is because doubles have
> 11 bits for a exponent which is exactly the same value for most of the
> angles

How much precision is too precision? double values are extremely well
suited for the kind of angles they have to represent: 11 bits are way
more than enough to express values between 180 and -180, and the rest
can be used for the mantissa (bearing a value between 0 and
0.99..) good enough.

So I really do not see a use case for using int64 here.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: add newline to avformat_write_header error message

2016-11-12 Thread Marton Balint 


On Sun, 13 Nov 2016, Michael Niedermayer wrote:


On Sat, Nov 12, 2016 at 02:23:29AM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


LGTM

thx



Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/fifo: fix undefined behaviour in deinit when destroying mutex

2016-11-12 Thread Marton Balint 


On Sat, 12 Nov 2016, Jan Sebechlebsky wrote:


On 11/12/2016 02:23 AM, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
  libavformat/fifo.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 15435fe..8f525e5 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -73,6 +73,7 @@ typedef struct FifoContext {
  int restart_with_keyframe;

  pthread_mutex_t overflow_flag_lock;
+int overflow_flag_lock_initialized;
  /* Value > 0 signals queue overflow */
  volatile uint8_t overflow_flag;

@@ -515,6 +516,7 @@ static int fifo_init(AVFormatContext *avf)
  ret = pthread_mutex_init(>overflow_flag_lock, NULL);
  if (ret < 0)
  return AVERROR(ret);
+fifo->overflow_flag_lock_initialized = 1;

  return 0;
  }
@@ -601,7 +603,8 @@ static void fifo_deinit(AVFormatContext *avf)
  av_dict_free(>format_options);
  avformat_free_context(fifo->avf);
  av_thread_message_queue_free(>queue);
-pthread_mutex_destroy(>overflow_flag_lock);
+if (fifo->overflow_flag_lock_initialized)
+pthread_mutex_destroy(>overflow_flag_lock);
  }

  #define OFFSET(x) offsetof(FifoContext, x)

LGTM, thanks! :)

Reviewed-by: jsebechlebsky



Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH] vp9_mc_template: disable assert for SCALED == 0

2016-11-12 Thread Ronald S. Bultje 
Hi Andreas,

On Nov 12, 2016 5:52 PM, "Andreas Cadhalpun" <
andreas.cadhal...@googlemail.com> wrote:
>
> The handling of the other block sizes was disabled for 'SCALED == 0' in
> commit dc96c0f9fc96bf4167633befc074394062793322, so this assert should
> be disabled, too, as it can now be triggered.
>
> Signed-off-by: Andreas Cadhalpun 
> ---
>
> At least that would be the easy fix, but I'd be glad if Ronald could
> comment on this.
>
> ---
>  libavcodec/vp9_mc_template.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/vp9_mc_template.c b/libavcodec/vp9_mc_template.c
> index 38d9a6d..e7f226c 100644
> --- a/libavcodec/vp9_mc_template.c
> +++ b/libavcodec/vp9_mc_template.c
> @@ -205,7 +205,9 @@ static void FN(inter_pred)(AVCodecContext *ctx)
>  } else
>  #endif
>  {
> +#if SCALED == 0
>  av_assert2(b->bs == BS_4x4);
> +#endif

I think you're right, thanks for finding this.

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

Re: [FFmpeg-devel] [PATCH] lavfi/ebur128: specify scaling_factor directly

2016-11-12 Thread Marton Balint 


On Sun, 13 Nov 2016, Michael Niedermayer wrote:


On Sun, Nov 13, 2016 at 02:43:39AM +0100, Marton Balint wrote:

This should fix build with Solaris CC.

Signed-off-by: Marton Balint 
---
 libavfilter/ebur128.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)


LGTM



Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH] lavfi/ebur128: specify scaling_factor directly

2016-11-12 Thread Michael Niedermayer 
On Sun, Nov 13, 2016 at 02:43:39AM +0100, Marton Balint wrote:
> This should fix build with Solaris CC.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavfilter/ebur128.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)

LGTM

thx

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

[FFmpeg-devel] [PATCH] lavfi/ebur128: specify scaling_factor directly

2016-11-12 Thread Marton Balint 
This should fix build with Solaris CC.

Signed-off-by: Marton Balint 
---
 libavfilter/ebur128.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavfilter/ebur128.c b/libavfilter/ebur128.c
index 8e216c4..a46692e 100644
--- a/libavfilter/ebur128.c
+++ b/libavfilter/ebur128.c
@@ -312,12 +312,10 @@ void ff_ebur128_destroy(FFEBUR128State ** st)
 *st = NULL;
 }
 
-#define EBUR128_FILTER(type, min_scale, max_scale) 
\
+#define EBUR128_FILTER(type, scaling_factor)   
\
 static void ebur128_filter_##type(FFEBUR128State* st, const type** srcs,   
\
   size_t src_index, size_t frames, 
\
   int stride) {
\
-static double scaling_factor = -((double) min_scale) > (double) max_scale 
?\
-   -((double) min_scale) : (double) max_scale; 
\
 double* audio_data = st->d->audio_data + st->d->audio_data_index;  
\
 size_t i, c;   
\

\
@@ -363,9 +361,10 @@ static void ebur128_filter_##type(FFEBUR128State* st, 
const type** srcs,
 st->d->v[ci][1] = fabs(st->d->v[ci][1]) < DBL_MIN ? 0.0 : 
st->d->v[ci][1]; \
 }  
\
 }
-EBUR128_FILTER(short, SHRT_MIN, SHRT_MAX)
-EBUR128_FILTER(int, INT_MIN, INT_MAX)
-EBUR128_FILTER(float, -1.0f, 1.0f) EBUR128_FILTER(double, -1.0, 1.0)
+EBUR128_FILTER(short, -((double)SHRT_MIN))
+EBUR128_FILTER(int, -((double)INT_MIN))
+EBUR128_FILTER(float,  1.0)
+EBUR128_FILTER(double, 1.0)
 
 static double ebur128_energy_to_loudness(double energy)
 {
-- 
2.6.6

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

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: add newline to avformat_write_header error message

2016-11-12 Thread Michael Niedermayer 
On Sat, Nov 12, 2016 at 02:23:29AM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  ffmpeg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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/mux: don't warn about missing timestamps on attached pictures

2016-11-12 Thread Michael Niedermayer 
On Sat, Nov 12, 2016 at 06:01:58PM -0600, Rodger Combs wrote:
> ---
>  libavformat/mux.c | 1 +
>  1 file changed, 1 insertion(+)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] configure: use check_lib2 for cuda and cuvid

2016-11-12 Thread Timo Rothenpieler 
Seems like I never tested on any 32bit platform.

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

[FFmpeg-devel] [PATCH] lavf/mux: don't warn about missing timestamps on attached pictures

2016-11-12 Thread Rodger Combs 
---
 libavformat/mux.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 77823a4..963d006 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -575,6 +575,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, 
AVStream *st, AVPacket *
 
 if (!s->internal->missing_ts_warning &&
 !(s->oformat->flags & AVFMT_NOTIMESTAMPS) &&
+(!(st->disposition & AV_DISPOSITION_ATTACHED_PIC) || (st->disposition 
& AV_DISPOSITION_TIMED_THUMBNAILS)) &&
 (pkt->pts == AV_NOPTS_VALUE || pkt->dts == AV_NOPTS_VALUE)) {
 av_log(s, AV_LOG_WARNING,
"Timestamps are unset in a packet for stream %d. "
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: zero initialize codec_name in mov_parse_stsd_video()

2016-11-12 Thread James Almer 
On 10/20/2016 3:25 PM, Andreas Cadhalpun wrote:
> On 20.10.2016 03:25, Michael Niedermayer wrote:
>> On Wed, Oct 19, 2016 at 07:30:29PM +0200, Andreas Cadhalpun wrote:
>>> On 19.10.2016 04:15, James Almer wrote:
 On 10/17/2016 9:57 PM, Michael Niedermayer wrote:
> On Sun, Oct 16, 2016 at 09:34:50PM -0300, James Almer wrote:
>> Fixes valgrind warning about "Conditional jump or move depends on 
>> uninitialised value(s)"
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/mov.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> This should be suppressable by adding it to
> tests/fate-valgrind.supp

 I'll leave that to someone else. No idea how to add stuff to that file.

 Should i drop this patch? Zero initializing a buffer in stack wouldn't
 hurt IMO.
>>>
>>> I prefer fixing such things in the code if it's reasonable possible, which
>>> is the case here. In other words, the patch looks good to me.
>>
>> I think the bug is that valgrind misinterprets highly optimized libc/gcc
>> code, i might be wrong though as i didnt disassemble and analyze this,
>> that was just my feeling ...
>> But if true a change to ffmpeg can only workaround but not fix this
> 
> Yes, this seems to be a false positive. But working around it is good, because
> it increases the signal to noise ratio of valgrind.
> This is similar to false positive compiler warnings: Not working around them
> has high chances of wasting the time of the next one to look into it.
> 
> Best regards,
> Andreas

Pushed. Three tests were failing now because of this, up from one when i
first submitted this patch, so even as a workaround it still gets rid of
the noise and will make new actual leaks or overreads easily noticeable.

Anyone wanting to fix this by adding a suppression or by fixing Valgrind
is welcome.

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

Re: [FFmpeg-devel] [PATCH 1/3] lavu: Add AVSphericalMapping type and frame side data

2016-11-12 Thread Michael Niedermayer 
Hi

On Sat, Nov 12, 2016 at 12:30:52PM -0500, Vittorio Giovara wrote:
> On Sat, Nov 12, 2016 at 9:41 AM, James Almer  wrote:
> > On 11/11/2016 10:39 PM, Michael Niedermayer wrote:
> >> On Fri, Nov 11, 2016 at 05:49:00PM -0500, Vittorio Giovara wrote:
[...]
> >>
> >>> +double yaw;   ///< Clockwise rotation around the up vector [-180, 
> >>> 180].
> >>> +double pitch; ///< Counter-clockwise rotation around the right 
> >>> vector [-90, 90].
> >>> +double roll;  ///< Counter-clockwise rotation around the forward 
> >>> vector [-180, 180].
> >>
> >> please use intXY (64 or 32 as preferred) so there are no platform
> >> rounding dependancies
> 
> These are rotation angles which are inherently floating point, and

Theres nothing inherently floating point on an angle.


> consistent with what other rotation-related APIs export (eg.
> av_display_matrix_rotation_get()).

> Besides using intXX would lose
> precision that the original specification offers.

int64_t has about a thousand times higher precission than a double
for storing general -180°..+180° angles. This is because doubles have
11 bits for a exponent which is exactly the same value for most of the
angles

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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

[FFmpeg-devel] [PATCH] vp9_mc_template: disable assert for SCALED == 0

2016-11-12 Thread Andreas Cadhalpun 
The handling of the other block sizes was disabled for 'SCALED == 0' in
commit dc96c0f9fc96bf4167633befc074394062793322, so this assert should
be disabled, too, as it can now be triggered.

Signed-off-by: Andreas Cadhalpun 
---

At least that would be the easy fix, but I'd be glad if Ronald could
comment on this.

---
 libavcodec/vp9_mc_template.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/vp9_mc_template.c b/libavcodec/vp9_mc_template.c
index 38d9a6d..e7f226c 100644
--- a/libavcodec/vp9_mc_template.c
+++ b/libavcodec/vp9_mc_template.c
@@ -205,7 +205,9 @@ static void FN(inter_pred)(AVCodecContext *ctx)
 } else
 #endif
 {
+#if SCALED == 0
 av_assert2(b->bs == BS_4x4);
+#endif
 
 // FIXME if two horizontally adjacent blocks have the same MV,
 // do a w8 instead of a w4 call
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] libavformat/tee: Add fifo support for tee

2016-11-12 Thread Jan Sebechlebsky 

On 10/31/2016 04:56 PM, Nicolas George wrote:


+if (av_match_name(use_fifo, "true,y,yes,enable,enabled,on,1")) {
+tee_slave->use_fifo = 1;
+} else if (av_match_name(use_fifo, 
"false,n,no,disable,disabled,off,0")) {

I am not happy about the duplication of the tests from
set_string_bool(), but it cannot be avoided for now without more
unrelated work.

(I really with each option type came with the corresponding silent and
verbose parsing and dump functions. Unfortunately, this discipline was
not kept in the past.)
It may be worth refactoring just these tests setting variable to 0/1/-1 
based on boolean/"auto" string to separate function. If you agree I can 
do this in next patch

+ret = avformat_alloc_output_context2(, NULL, "fifo", filename);
+} else {
+ret = avformat_alloc_output_context2(, NULL, format, filename);

You could probably factor these two lines with
"use_fifo ? "fifo" : format".

Thanks, looks nicer that way, I've modified it.

+}
  if (ret < 0)
  goto end;
  tee_slave->avf = avf2;
@@ -394,6 +467,12 @@ static int tee_write_header(AVFormatContext *avf)
  filename++;
  }
  
+if (tee->fifo_options_str) {

+ret = av_dict_parse_string(>fifo_options, tee->fifo_options_str, "=", 
":", 0);
+if (ret < 0)
+goto fail;
+}
+
  if (!(tee->slaves = av_mallocz_array(nb_slaves, sizeof(*tee->slaves {
  ret = AVERROR(ENOMEM);
  goto fail;
@@ -401,6 +480,12 @@ static int tee_write_header(AVFormatContext *avf)
  tee->nb_slaves = tee->nb_alive = nb_slaves;
  
  for (i = 0; i < nb_slaves; i++) {

+
+tee->slaves[i].use_fifo = tee->use_fifo;
+ret = av_dict_copy(>slaves[i].fifo_options, tee->fifo_options, 0);

Unless I am mistaken, if there are keys present in both dicts, the
entries in tee->fifo_options will overwrite the ones in
slave[i].fifo_options: in other words, global overrides local. Usually,
people want it the other way around.

This is executed before open_slave() function is run for that slave. So 
the options "inherited" from global tee->fifo_options will be 
overwritten by per-slave options in open_slave(). I think this is OK.

+if (ret < 0)
+goto fail;
+
  if ((ret = open_slave(avf, slaves[i], >slaves[i])) < 0) {
  ret = tee_process_slave_failure(avf, i, ret);
  if (ret < 0)

In short, there are a few points that could be IMHO slightly better, but
I think the patch can go in as is if you want to move forward, possibly
with a few /* TODO */ (but no need to send the patch again if you add
them).

Hum. Now I realize I have some doubts about the way the options work.
But with the current state of the options parsing, I am not sure we can
do much better.

Maybe a small suggestion: instead of stealing the fifo_options option,
steal all options starting with "fifo." (av_dict_get() can do that).
That would avoid one level of escaping. But it can also be added later
if you prefer.
I like this idea and have implemented it, now I am wondering if I should 
keep both possibilities of how to pass options to fifo muxer... What do 
you think?


Also, I am sorry for such late response to your review...

Thank you,

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/fifo: fix undefined behaviour in deinit when destroying mutex

2016-11-12 Thread Jan Sebechlebsky 

On 11/12/2016 02:23 AM, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
  libavformat/fifo.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 15435fe..8f525e5 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -73,6 +73,7 @@ typedef struct FifoContext {
  int restart_with_keyframe;
  
  pthread_mutex_t overflow_flag_lock;

+int overflow_flag_lock_initialized;
  /* Value > 0 signals queue overflow */
  volatile uint8_t overflow_flag;
  
@@ -515,6 +516,7 @@ static int fifo_init(AVFormatContext *avf)

  ret = pthread_mutex_init(>overflow_flag_lock, NULL);
  if (ret < 0)
  return AVERROR(ret);
+fifo->overflow_flag_lock_initialized = 1;
  
  return 0;

  }
@@ -601,7 +603,8 @@ static void fifo_deinit(AVFormatContext *avf)
  av_dict_free(>format_options);
  avformat_free_context(fifo->avf);
  av_thread_message_queue_free(>queue);
-pthread_mutex_destroy(>overflow_flag_lock);
+if (fifo->overflow_flag_lock_initialized)
+pthread_mutex_destroy(>overflow_flag_lock);
  }
  
  #define OFFSET(x) offsetof(FifoContext, x)

LGTM, thanks! :)

Reviewed-by: jsebechlebsky

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

Re: [FFmpeg-devel] [PATCH 1/3] lavu: Add AVSphericalMapping type and frame side data

2016-11-12 Thread Vittorio Giovara 
On Sat, Nov 12, 2016 at 9:41 AM, James Almer  wrote:
> On 11/11/2016 10:39 PM, Michael Niedermayer wrote:
>> On Fri, Nov 11, 2016 at 05:49:00PM -0500, Vittorio Giovara wrote:
>> [...]
>>> +/**
>>> + * This structure describes how to handle spherical videos, outlining
>>> + * information about projection, initial layout, and any other view 
>>> modifier.
>>> + *
>>> + * @note The struct must be allocated with av_spherical_alloc() and
>>> + *   its size is not a part of the public ABI.
>>> + */
>>> +typedef struct AVSphericalMapping {
>>> +/**
>>> + * Projection type.
>>> + */
>>> +enum AVSphericalProjection projection;
>>> +
>>> +/**
>>> + * @name Initial orientation
>>> + * @{
>>> + * These fields represent the pose values that measure the rotation
>>> + * transformation (in degrees) to be applied to the projection.
>>> + * See this equirectangular projection as example:
>>> + *
>>> + * @code{.unparsed}
>>> + *   Yaw
>>> + * -180   0   180
>>> + *   90 +-+-+  180
>>> + *  | | |
>>> + * P| |  o> |
>>> + * i| ^ |
>>> + * t  0 +-X-+0 Roll
>>> + * c| | |
>>> + * h| | |
>>> + *  | | |
>>> + *  -90 +-+-+ -180
>>> + *
>>> + * X - the default camera center
>>> + * ^ - the default up vector
>>> + * > - the up vector for a rotation of 90 degrees
>>> + * o - the image center for yaw = 90, pitch = 45, roll = 0
>>> + * @endcode
>>> + *
>>> + * The order of transformation is always yaw, followed by pitch, and
>>> + * finally by roll.
>>> + */
>>
>>> +double yaw;   ///< Clockwise rotation around the up vector [-180, 180].
>>> +double pitch; ///< Counter-clockwise rotation around the right vector 
>>> [-90, 90].
>>> +double roll;  ///< Counter-clockwise rotation around the forward 
>>> vector [-180, 180].
>>
>> please use intXY (64 or 32 as preferred) so there are no platform
>> rounding dependancies

These are rotation angles which are inherently floating point, and
consistent with what other rotation-related APIs export (eg.
av_display_matrix_rotation_get()). Besides using intXX would lose
precision that the original specification offers.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] mov: Export spherical information

2016-11-12 Thread Vittorio Giovara 
On Fri, Nov 11, 2016 at 6:23 PM, James Almer  wrote:
> On 11/11/2016 7:49 PM, Vittorio Giovara wrote:
>> This implements Spherical Video V1 and V2, as described in the
>> spatial-media collection by Google.
>>
>> Signed-off-by: Vittorio Giovara 
>> ---
>> Please CC.
>> Vittorio
>>
>>  libavformat/isom.h |   7 ++
>>  libavformat/mov.c  | 281 
>> -
>>  2 files changed, 287 insertions(+), 1 deletion(-)
>
> [...]
>
>> @@ -5682,6 +5927,40 @@ static int mov_read_header(AVFormatContext *s)
>>  sd->data = (uint8_t*)sc->display_matrix;
>>  sc->display_matrix = NULL;
>>  }
>> +if (sc->stereo3d) {
>> +AVPacketSideData *sd, *tmp;
>> +
>> +tmp = av_realloc_array(st->side_data,
>> +   st->nb_side_data + 1, sizeof(*tmp));
>> +if (!tmp)
>> +return AVERROR(ENOMEM);
>> +
>> +st->side_data = tmp;
>> +st->nb_side_data++;
>> +
>> +sd = >side_data[st->nb_side_data - 1];
>> +sd->type = AV_PKT_DATA_STEREO3D;
>> +sd->size = sizeof(*sc->stereo3d);
>> +sd->data = (uint8_t *)sc->stereo3d;
>> +sc->stereo3d = NULL;
>> +}
>> +if (sc->spherical) {
>> +AVPacketSideData *sd, *tmp;
>> +
>> +tmp = av_realloc_array(st->side_data,
>> +   st->nb_side_data + 1, sizeof(*tmp));
>> +if (!tmp)
>> +return AVERROR(ENOMEM);
>> +
>> +st->side_data = tmp;
>> +st->nb_side_data++;
>> +
>> +sd = >side_data[st->nb_side_data - 1];
>> +sd->type = AV_PKT_DATA_SPHERICAL;
>> +sd->size = sc->spherical_size;
>> +sd->data = (uint8_t *)sc->spherical;
>> +sc->spherical = NULL;
>> +}
>
> Why isn't this using av_stream_new_side_data()?

I didn't want to mix refactors and new code in a single patch,
coalescing that portion of code may be done later.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] feature: xcbgrab single window

2016-11-12 Thread Ing . Radomír Polách 
2016-11-11 11:35 GMT+01:00 Nicolas George :

> Thanks for the patch. See comments below.
>
> > Subject: Re: [FFmpeg-devel] [PATCH] feature: xcbgrab single window
>
> The recommended syntax would be "lavd/xcbgrab: add single window mode".
>

Ok.


>
> > Allows to grab only a single window by using syntax:
> > ffmpeg -f x11grab -r 15 -i ":0/0x0580001b/parent2" ...
>
> > The syntax for input is "display/grab_window_id/focus_window_id".
>
> I am not sure the "file name" is the best place for that, since it
> requires parsing. An option would be easier and probably more
> convenient, especially for focus_window_id.
>

I am not sure either, but I think it is better this way, because you can
easily use it to pass result from a search script:
./ffmpeg -i $(./findmypaint.sh) ...
Search script is a simple script which finds for you screen, focus window
and grab window of some program.
For example findmypaint.sh here finds this information about MyPaint. The
search script just needs to produce output like this:
:0/0x0580001b/parent2
It is very flexible this way.


> > If focus_window_id is omitted it is set as grab_window_id.
> > There are special constants for focus_window_id:
> > - this: grab_window_id
> > - parent: parent window id of grab_window,
> > - parent2: grand parent window id of grab_window,
> > - parent3: great grand parent window id of grab_window.
>
> This should go in the documentation.


Ok.


>


> > Has a single command line option repeat_frame which controls
> > out of focus streaming. Turned on in default for repeating
> > the last frame. If turned off sends empty (zero length) packet
> > to the ffmpeg backend.
>
> I think the focus feature should go in a separate patch. You will find
> easier to get several smaller patches accepted.
>
> Actually, I think there are three separate features here: (1) following
> a window, (2) disabling the capture according to focus and (3)
> duplicating the frame when the capture is disabled or not possible.
>
> I am not entirely sure about the usefulness of duplicating the frame.
> The framerate controls later in the system would do the job nicely.
>

I tought so too, but I tested it with RTMP streaming and players
disconnects without repeat_frame. I am not sure where the problem is.
Didn't know about existence of boolean there. Should I also take care of
draw_mouse and follow_mouse in a separate patch?


>
> >  { "draw_mouse", "Draw the mouse pointer.", OFFSET(draw_mouse),
> AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, D },
> >  { "follow_mouse", "Move the grabbing region when the mouse pointer
> reaches within specified amount of pixels to the edge of region.",
> >OFFSET(follow_mouse), AV_OPT_TYPE_INT, { .i64 = 0 },
> FOLLOW_CENTER, INT_MAX, D, "follow_mouse" },
> > @@ -156,9 +169,13 @@ static int xcbgrab_frame(AVFormatContext *s,
> AVPacket *pkt)
> >  uint8_t *data;
> >  int length, ret;
> >
>
> > -iq  = xcb_get_image(c->conn, XCB_IMAGE_FORMAT_Z_PIXMAP, drawable,
> > -c->x, c->y, c->width, c->height, ~0);
> > -
> > +if (c->focus_name) {
> > +iq  = xcb_get_image(c->conn, XCB_IMAGE_FORMAT_Z_PIXMAP,
> c->grab_window,
> > +0, 0, c->width, c->height, ~0);
> > +} else {
> > +iq  = xcb_get_image(c->conn, XCB_IMAGE_FORMAT_Z_PIXMAP,
> drawable,
> > +c->x, c->y, c->width, c->height, ~0);
> > +}
>
> It would be better to avoid duplicating the function call and instead
> make sure drawable, c->x and c->y have the correct value. Your patch
> does not seem to make use of c->x and c->y: capturing only part of a
> window would be useful too.
>

Good idea about capturing part of a window and single call. Will redo this.


>
> >  img = xcb_get_image_reply(c->conn, iq, );
> >
> >  if (e) {
> > @@ -261,9 +278,16 @@ static int xcbgrab_frame_shm(AVFormatContext *s,
> AVPacket *pkt)
> >  if (ret < 0)
> >  return ret;
> >
>
> > -iq = xcb_shm_get_image(c->conn, drawable,
> > -   c->x, c->y, c->width, c->height, ~0,
> > -   XCB_IMAGE_FORMAT_Z_PIXMAP, c->segment, 0);
> > +if (c->focus_name) {
> > +iq = xcb_shm_get_image(c->conn, c->grab_window,
> > +   0, 0, c->width, c->height, ~0,
> > +   XCB_IMAGE_FORMAT_Z_PIXMAP, c->segment,
> 0);
> > +} else {
> > +iq = xcb_shm_get_image(c->conn, drawable,
> > +   c->x, c->y, c->width, c->height, ~0,
> > +   XCB_IMAGE_FORMAT_Z_PIXMAP, c->segment,
> 0);
> > +}
>
> Same remark as above.
>
>
Ok.


> > +
>
> Stray empty line.
>
>
Ok.
Will improve this.


> > +
> > +w = r->focus;
> > +free(r);
> > +return w;
> > +}
> > +
> > +static xcb_window_t get_window_parent(AVFormatContext *s, xcb_window_t
> w)
> > +{
> > +XCBGrabContext *ctx = s->priv_data;
> > +xcb_query_tree_cookie_t c;
> >

Re: [FFmpeg-devel] [PATCH] lavc/vaapi: Add VP8 decode hwaccel

2016-11-12 Thread Mark Thompson 
On 12/11/16 13:57, Mark Thompson wrote:
> On 11/11/16 07:57, Jun Zhao wrote:
>> @@ -2800,14 +2849,18 @@ static int 
>> vp8_decode_update_thread_context(AVCodecContext *dst,
>>  s->mb_width  = s_src->mb_width;
>>  s->mb_height = s_src->mb_height;
>>  }
>> -
>>  s->prob[0]  = s_src->prob[!s_src->update_probabilities];
>>  s->segmentation = s_src->segmentation;
>>  s->lf_delta = s_src->lf_delta;
>> +s->pix_fmt = s_src->pix_fmt;
>> +s->mbskip_enabled = s_src->mbskip_enabled;
>> +s->filter = s_src->filter;
>>  memcpy(s->sign_bias, s_src->sign_bias, sizeof(s->sign_bias));
>> +s->num_coeff_partitions = s_src->num_coeff_partitions;
>> +s->header_partition_size = s_src->header_partition_size;
>>
>>  for (i = 0; i < FF_ARRAY_ELEMS(s_src->frames); i++) {
>> -if (s_src->frames[i].tf.f->data[0]) {
>> +if (s_src->frames[i].tf.f->buf[0]) {
>>  int ret = vp8_ref_frame(s, >frames[i], _src->frames[i]);
>>  if (ret < 0)
>>  return ret;
> 
> This is fixing decode with frame threads?  I admit I don't think I ever 
> tested with frame threading enabled, indeed it dies horribly in libav.
> 
> Does fate-vp8 using the hwaccel and threads pass in ffmpeg with this?  It 
> fails in libav, but the setup might be different because of changes you've 
> made.

Right, only pix_fmt and the references should be copied here (the other parts 
are always overwritten from the frame header).

More synchronisation is required to make it actually work - see 
.  
Assuming other people agree with the approach there, it should probably be 
merged at the same time as 4e528206bc4d968706401206cf54471739250ec7.

Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH 1/3] lavu: Add AVSphericalMapping type and frame side data

2016-11-12 Thread James Almer 
On 11/11/2016 10:39 PM, Michael Niedermayer wrote:
> On Fri, Nov 11, 2016 at 05:49:00PM -0500, Vittorio Giovara wrote:
> [...]
>> +/**
>> + * This structure describes how to handle spherical videos, outlining
>> + * information about projection, initial layout, and any other view 
>> modifier.
>> + *
>> + * @note The struct must be allocated with av_spherical_alloc() and
>> + *   its size is not a part of the public ABI.
>> + */
>> +typedef struct AVSphericalMapping {
>> +/**
>> + * Projection type.
>> + */
>> +enum AVSphericalProjection projection;
>> +
>> +/**
>> + * @name Initial orientation
>> + * @{
>> + * These fields represent the pose values that measure the rotation
>> + * transformation (in degrees) to be applied to the projection.
>> + * See this equirectangular projection as example:
>> + *
>> + * @code{.unparsed}
>> + *   Yaw
>> + * -180   0   180
>> + *   90 +-+-+  180
>> + *  | | |
>> + * P| |  o> |
>> + * i| ^ |
>> + * t  0 +-X-+0 Roll
>> + * c| | |
>> + * h| | |
>> + *  | | |
>> + *  -90 +-+-+ -180
>> + *
>> + * X - the default camera center
>> + * ^ - the default up vector
>> + * > - the up vector for a rotation of 90 degrees
>> + * o - the image center for yaw = 90, pitch = 45, roll = 0
>> + * @endcode
>> + *
>> + * The order of transformation is always yaw, followed by pitch, and
>> + * finally by roll.
>> + */
> 
>> +double yaw;   ///< Clockwise rotation around the up vector [-180, 180].
>> +double pitch; ///< Counter-clockwise rotation around the right vector 
>> [-90, 90].
>> +double roll;  ///< Counter-clockwise rotation around the forward vector 
>> [-180, 180].
> 
> please use intXY (64 or 32 as preferred) so there are no platform
> rounding dependancies
> 

CCing Vittorio so he can see this.

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: fix poc incorrect issue after meeting idr frame.

2016-11-12 Thread Mark Thompson 
On 11/11/16 07:02, Jun Zhao wrote:
> From 25a5cc94fba53405acd53f9613fa5d206ce748f0 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 11 Nov 2016 14:53:49 +0800
> Subject: [PATCH] lavc/vaapi_encode_h264: fix poc incorrect issue after meeting
>  idr frame.
>
> when meeting IDR frame, vaapi_encode_h264 poc sometime is wrong, now fix
> this issue based on h264 spec.
>
> Reviewed-by: Jun Zhao 
> Signed-off-by: Wang, Yi A 
>
> ase enter the commit message for your changes. Lines starting
> ---
>  libavcodec/vaapi_encode_h264.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)

This is correct.  Can you modify the commit message to actually explain the 
problem more fully?  It took me a while to work out exactly what you were 
getting at, especially because the reference decoder does not care about it.


> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 5bed4e4..9e526c8 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -148,6 +148,8 @@ typedef struct VAAPIEncodeH264Context {
>
>  // Rate control configuration.
>  int send_timing_sei;
> +
> +int64_t last_idr_frame;

It's not a rate control parameter.  Move it to immediately after 
next_frame_num, maybe?


>  struct {
>  VAEncMiscParameterBuffer misc;
>  VAEncMiscParameterRateControl rc;
> @@ -947,6 +949,7 @@ static int 
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>  vpic->frame_num = 0;
>  priv->next_frame_num = 1;
>  priv->cpb_delay = 0;
> +priv->last_idr_frame = pic->display_order;
>  } else {
>  vpic->frame_num = priv->next_frame_num;
>  if (pic->type != PICTURE_TYPE_B) {
> @@ -963,8 +966,8 @@ static int 
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>  vpic->CurrPic.picture_id  = pic->recon_surface;
>  vpic->CurrPic.frame_idx   = vpic->frame_num;
>  vpic->CurrPic.flags   = 0;
> -vpic->CurrPic.TopFieldOrderCnt= pic->display_order;
> -vpic->CurrPic.BottomFieldOrderCnt = pic->display_order;
> +vpic->CurrPic.TopFieldOrderCnt= pic->display_order - 
> priv->last_idr_frame;
> +vpic->CurrPic.BottomFieldOrderCnt = pic->display_order - 
> priv->last_idr_frame;
>
>  for (i = 0; i < pic->nb_refs; i++) {
>  VAAPIEncodePicture *ref = pic->refs[i];
> @@ -972,8 +975,8 @@ static int 
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>  vpic->ReferenceFrames[i].picture_id = ref->recon_surface;
>  vpic->ReferenceFrames[i].frame_idx  = ref->encode_order;
>  vpic->ReferenceFrames[i].flags = 
> VA_PICTURE_H264_SHORT_TERM_REFERENCE;
> -vpic->ReferenceFrames[i].TopFieldOrderCnt= ref->display_order;
> -vpic->ReferenceFrames[i].BottomFieldOrderCnt = ref->display_order;
> +vpic->ReferenceFrames[i].TopFieldOrderCnt= ref->display_order - 
> priv->last_idr_frame;
> +vpic->ReferenceFrames[i].BottomFieldOrderCnt = ref->display_order - 
> priv->last_idr_frame;
>  }
>  for (; i < FF_ARRAY_ELEMS(vpic->ReferenceFrames); i++) {
>  vpic->ReferenceFrames[i].picture_id = VA_INVALID_ID;
> @@ -1044,7 +1047,7 @@ static int 
> vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
>  vslice->pic_parameter_set_id = vpic->pic_parameter_set_id;
>  vslice->idr_pic_id = priv->idr_pic_count++;
>
> -vslice->pic_order_cnt_lsb = pic->display_order &
> +vslice->pic_order_cnt_lsb = (pic->display_order - priv->last_idr_frame) &
>  ((1 << (4 + 
> vseq->seq_fields.bits.log2_max_pic_order_cnt_lsb_minus4)) - 1);
>
>  for (i = 0; i < FF_ARRAY_ELEMS(vslice->RefPicList0); i++) {
> --
> 1.8.3.1
>

Actual code LGTM.


Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi: Add VP8 decode hwaccel

2016-11-12 Thread Mark Thompson 
On 11/11/16 07:57, Jun Zhao wrote:
> From 4635e7e4a0ea24f77e71ffc9a9074e75c61bfe44 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 11 Nov 2016 15:51:01 +0800
> Subject: [PATCH] lavc/vaapi: Add VP8 decode hwaccel
>
> Add VP8 decode hwaccel based on the libav:
> commit a9fb134730da1f9642eb5a2baa50943b8a4aa245
> lavc/vaapi: Add VP8 decode hwaccel
> commit 75d642a944d5579e4ef20ff3701422a64692afcf
> vaapi_vp8: Explicitly include libva vp8 decode header
>
> Reviewed-by: Jun Zhao 
> Signed-off-by: Wang, Yi A 
>
> ase enter the commit message for your changes. Lines starting
> ---
>  configure   |   3 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/vaapi.c  |  15 -
>  libavcodec/vaapi.h  |   9 +++
>  libavcodec/vaapi_internal.h |   3 +
>  libavcodec/vp8.c| 149 
> ++--
>  libavcodec/vp8.h|  29 -
>  8 files changed, 159 insertions(+), 51 deletions(-)

(You've omitted the file vaapi_vp8.c, so the patch isn't currently usable.)

The patches implementing this are already in the merge queue.  Other than the 
part noted below and the backport, is there any difference to the functionality?

I would generally prefer to preserve synchronisation with libav - the normal 
merge will also get the original dependencies rather than backporting to the 
pre-hwcontext infrastructure.


> @@ -2800,14 +2849,18 @@ static int 
> vp8_decode_update_thread_context(AVCodecContext *dst,
>  s->mb_width  = s_src->mb_width;
>  s->mb_height = s_src->mb_height;
>  }
> -
>  s->prob[0]  = s_src->prob[!s_src->update_probabilities];
>  s->segmentation = s_src->segmentation;
>  s->lf_delta = s_src->lf_delta;
> +s->pix_fmt = s_src->pix_fmt;
> +s->mbskip_enabled = s_src->mbskip_enabled;
> +s->filter = s_src->filter;
>  memcpy(s->sign_bias, s_src->sign_bias, sizeof(s->sign_bias));
> +s->num_coeff_partitions = s_src->num_coeff_partitions;
> +s->header_partition_size = s_src->header_partition_size;
>
>  for (i = 0; i < FF_ARRAY_ELEMS(s_src->frames); i++) {
> -if (s_src->frames[i].tf.f->data[0]) {
> +if (s_src->frames[i].tf.f->buf[0]) {
>  int ret = vp8_ref_frame(s, >frames[i], _src->frames[i]);
>  if (ret < 0)
>  return ret;

This is fixing decode with frame threads?  I admit I don't think I ever tested 
with frame threading enabled, indeed it dies horribly in libav.

Does fate-vp8 using the hwaccel and threads pass in ffmpeg with this?  It fails 
in libav, but the setup might be different because of changes you've made.


Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: fix the hevc vaapi encoder output shaking issue.

2016-11-12 Thread Mark Thompson 
On 11/11/16 02:24, Jun Zhao wrote:
> From 5db0b2cd0930ed88d853114f13b69a80a44d9c4c Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 11 Nov 2016 10:04:53 +0800
> Subject: [PATCH] lavc/vaapi_encode_h265: fix the hevc vaapi encoder output
>  shaking issue.
>
> the max_num_reorder_pics/max_dec_pic_buffering_minus in vps/sps are incorrect.
>
> merge libav commit 314b421dd8910ebed7a8d419a0dbea239a00044e
> vaapi_encode: Decide on GOP setup before initialising sequence 
> parameters
>
> merge libav commit b8cac1e83066aa87e8402c146c81b77a11b5eec3
> vaapi_h265: Fix buffering parameters
>
> Merged-by: Wang, Yi A 
> Merged-by: Jun Zhao 
> ---
>  libavcodec/vaapi_encode.c  | 13 ++---
>  libavcodec/vaapi_encode_h265.c |  8 
>  2 files changed, 10 insertions(+), 11 deletions(-)

As with the other patch, this is already in the merge queue and I would prefer 
to use it from there.

Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Workaround interlaced mpeg4 edge MC bug

2016-11-12 Thread Moritz Barsnick 
On Sat, Nov 12, 2016 at 13:34:02 +0100, Carl Eugen Hoyos wrote:
> > +if ((ctx->lavc_build&0xFF) >= 100) {
> (Do we guarantee that MICRO <= 255?)

Most of the version macros in libavutil/version.h will not behave as
expected if not, as they assume 8 bits. So, yes, that's an implicit
requirement.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Workaround interlaced mpeg4 edge MC bug

2016-11-12 Thread Carl Eugen Hoyos 
2016-11-12 12:31 GMT+01:00 Michael Niedermayer :

> +if ((ctx->lavc_build&0xFF) >= 100) {

(Do we guarantee that MICRO <= 255?)

> +if (ctx->lavc_build > 3621476 && ctx->lavc_build < 3752550)

Sorry, I meant this patch, not 1/2:
Please mention the relevant change (60ab6e24?) in the commit message.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpegvideo: Fix edge emu buffer overlap with interlaced mpeg4

2016-11-12 Thread Carl Eugen Hoyos 
2016-11-12 12:31 GMT+01:00 Michael Niedermayer :
> Fixes Ticket5936

Please also mention the relevant original commit.
Was it 60ab6e24574a984655800d1f7ce16c05f4e9b28c?

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

[FFmpeg-devel] [PATCH 1/2] avcodec/mpegvideo: Fix edge emu buffer overlap with interlaced mpeg4

2016-11-12 Thread Michael Niedermayer 
Fixes Ticket5936

Signed-off-by: Michael Niedermayer 
---
 libavcodec/mpegpicture.c  | 2 +-
 libavcodec/mpegvideo.c| 2 +-
 libavcodec/mpegvideo_enc.c| 2 +-
 libavcodec/mpegvideo_motion.c | 4 ++--
 libavcodec/version.h  | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 6748fc2..302f9d2 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -76,7 +76,7 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 // at uvlinesize. It supports only YUV420 so 24x24 is enough
 // linesize * interlaced * MBsize
 // we also use this buffer for encoding in encode_mb_internal() needig an 
additional 32 lines
-FF_ALLOCZ_ARRAY_OR_GOTO(avctx, sc->edge_emu_buffer, alloc_size, 4 * 68,
+FF_ALLOCZ_ARRAY_OR_GOTO(avctx, sc->edge_emu_buffer, alloc_size, 4 * 70,
   fail);
 
 FF_ALLOCZ_ARRAY_OR_GOTO(avctx, me->scratchpad, alloc_size, 4 * 16 * 2,
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 9a17a6e..59be078 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -2116,7 +2116,7 @@ static av_always_inline void 
mpeg_motion_lowres(MpegEncContext *s,
 ptr_y = s->sc.edge_emu_buffer;
 if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY)) {
 uint8_t *ubuf = s->sc.edge_emu_buffer + 18 * s->linesize;
-uint8_t *vbuf =ubuf + 9 * s->uvlinesize;
+uint8_t *vbuf =ubuf + 10 * s->uvlinesize;
 s->vdsp.emulated_edge_mc(ubuf,  ptr_cb,
  uvlinesize >> field_based, uvlinesize >> 
field_based,
  9, 9 + field_based,
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 1540e5c..10b4c5b 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -2276,7 +2276,7 @@ static av_always_inline void 
encode_mb_internal(MpegEncContext *s,
  (mb_y * mb_block_height * wrap_c) + mb_x * mb_block_width;
 
 if((mb_x * 16 + 16 > s->width || mb_y * 16 + 16 > s->height) && 
s->codec_id != AV_CODEC_ID_AMV){
-uint8_t *ebuf = s->sc.edge_emu_buffer + 36 * wrap_y;
+uint8_t *ebuf = s->sc.edge_emu_buffer + 38 * wrap_y;
 int cw = (s->width  + s->chroma_x_shift) >> s->chroma_x_shift;
 int ch = (s->height + s->chroma_y_shift) >> s->chroma_y_shift;
 s->vdsp.emulated_edge_mc(ebuf, ptr_y,
diff --git a/libavcodec/mpegvideo_motion.c b/libavcodec/mpegvideo_motion.c
index c29810f..b97a6cb 100644
--- a/libavcodec/mpegvideo_motion.c
+++ b/libavcodec/mpegvideo_motion.c
@@ -326,7 +326,7 @@ void mpeg_motion_internal(MpegEncContext *s,
 ptr_y = s->sc.edge_emu_buffer;
 if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY)) {
 uint8_t *ubuf = s->sc.edge_emu_buffer + 18 * s->linesize;
-uint8_t *vbuf = ubuf + 9 * s->uvlinesize;
+uint8_t *vbuf = ubuf + 10 * s->uvlinesize;
 uvsrc_y = (unsigned)uvsrc_y << field_based;
 s->vdsp.emulated_edge_mc(ubuf, ptr_cb,
  s->uvlinesize, s->uvlinesize,
@@ -549,7 +549,7 @@ static inline void qpel_motion(MpegEncContext *s,
 ptr_y = s->sc.edge_emu_buffer;
 if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY)) {
 uint8_t *ubuf = s->sc.edge_emu_buffer + 18 * s->linesize;
-uint8_t *vbuf = ubuf + 9 * s->uvlinesize;
+uint8_t *vbuf = ubuf + 10 * s->uvlinesize;
 s->vdsp.emulated_edge_mc(ubuf, ptr_cb,
  s->uvlinesize, s->uvlinesize,
  9, 9 + field_based,
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 9799cfe..e05c310 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  57
 #define LIBAVCODEC_VERSION_MINOR  66
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MICRO 102
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Workaround interlaced mpeg4 edge MC bug

2016-11-12 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/avcodec.h  | 1 +
 libavcodec/mpeg4videodec.c| 5 +
 libavcodec/mpegvideo.c| 2 ++
 libavcodec/mpegvideo_motion.c | 4 
 libavcodec/options_table.h| 1 +
 5 files changed, 13 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 22f..e5e7f42 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2878,6 +2878,7 @@ typedef struct AVCodecContext {
 #define FF_BUG_DC_CLIP  4096
 #define FF_BUG_MS   8192 ///< Work around various bugs in 
Microsoft's broken decoders.
 #define FF_BUG_TRUNCATED   16384
+#define FF_BUG_IEDGE   32768
 
 /**
  * strictly follow the standard (MPEG-4, ...).
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 3adf28d..cdd0dd4 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2195,6 +2195,11 @@ int ff_mpeg4_workaround_bugs(AVCodecContext *avctx)
 if (ctx->lavc_build <= 4712U)
 s->workaround_bugs |= FF_BUG_DC_CLIP;
 
+if ((ctx->lavc_build&0xFF) >= 100) {
+if (ctx->lavc_build > 3621476 && ctx->lavc_build < 3752550)
+s->workaround_bugs |= FF_BUG_IEDGE;
+}
+
 if (ctx->divx_version >= 0)
 s->workaround_bugs |= FF_BUG_DIRECT_BLOCKSIZE;
 if (ctx->divx_version == 501 && ctx->divx_build == 20020416)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 59be078..e5424cb 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -2117,6 +2117,8 @@ static av_always_inline void 
mpeg_motion_lowres(MpegEncContext *s,
 if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY)) {
 uint8_t *ubuf = s->sc.edge_emu_buffer + 18 * s->linesize;
 uint8_t *vbuf =ubuf + 10 * s->uvlinesize;
+if (s->workaround_bugs & FF_BUG_IEDGE)
+vbuf -= s->uvlinesize;
 s->vdsp.emulated_edge_mc(ubuf,  ptr_cb,
  uvlinesize >> field_based, uvlinesize >> 
field_based,
  9, 9 + field_based,
diff --git a/libavcodec/mpegvideo_motion.c b/libavcodec/mpegvideo_motion.c
index b97a6cb..a310bd4 100644
--- a/libavcodec/mpegvideo_motion.c
+++ b/libavcodec/mpegvideo_motion.c
@@ -327,6 +327,8 @@ void mpeg_motion_internal(MpegEncContext *s,
 if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY)) {
 uint8_t *ubuf = s->sc.edge_emu_buffer + 18 * s->linesize;
 uint8_t *vbuf = ubuf + 10 * s->uvlinesize;
+if (s->workaround_bugs & FF_BUG_IEDGE)
+vbuf -= s->uvlinesize;
 uvsrc_y = (unsigned)uvsrc_y << field_based;
 s->vdsp.emulated_edge_mc(ubuf, ptr_cb,
  s->uvlinesize, s->uvlinesize,
@@ -550,6 +552,8 @@ static inline void qpel_motion(MpegEncContext *s,
 if (!CONFIG_GRAY || !(s->avctx->flags & AV_CODEC_FLAG_GRAY)) {
 uint8_t *ubuf = s->sc.edge_emu_buffer + 18 * s->linesize;
 uint8_t *vbuf = ubuf + 10 * s->uvlinesize;
+if (s->workaround_bugs & FF_BUG_IEDGE)
+vbuf -= s->uvlinesize;
 s->vdsp.emulated_edge_mc(ubuf, ptr_cb,
  s->uvlinesize, s->uvlinesize,
  9, 9 + field_based,
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 4323ae9..b65acea 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -163,6 +163,7 @@ static const AVOption avcodec_options[] = {
 {"dc_clip", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_BUG_DC_CLIP }, INT_MIN, 
INT_MAX, V|D, "bug"},
 {"ms", "work around various bugs in Microsoft's broken decoders", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_BUG_MS }, INT_MIN, INT_MAX, V|D, "bug"},
 {"trunc", "truncated frames", 0, AV_OPT_TYPE_CONST, {.i64 = FF_BUG_TRUNCATED}, 
INT_MIN, INT_MAX, V|D, "bug"},
+{"iedge", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_BUG_IEDGE }, INT_MIN, 
INT_MAX, V|D, "bug"},
 {"strict", "how strictly to follow the standards", 
OFFSET(strict_std_compliance), AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, 
INT_MAX, A|V|D|E, "strict"},
 {"very", "strictly conform to a older more strict version of the spec or 
reference software", 0, AV_OPT_TYPE_CONST, {.i64 = FF_COMPLIANCE_VERY_STRICT }, 
INT_MIN, INT_MAX, A|V|D|E, "strict"},
 {"strict", "strictly conform to all the things in the spec no matter what the 
consequences", 0, AV_OPT_TYPE_CONST, {.i64 = FF_COMPLIANCE_STRICT }, INT_MIN, 
INT_MAX, A|V|D|E, "strict"},
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH] configure: use check_lib2 for cuda and cuvid

2016-11-12 Thread Hendrik Leppkes 
On Sat, Nov 12, 2016 at 1:44 AM, Hendrik Leppkes  wrote:
> Fixes building on Windows with MSVC using the link libraries distributed with 
> the CUDA SDK.
>
> check_lib2 is required here because it includes the header to get the full 
> signature of the
> function, including the stdcall calling convention and all of its arguments, 
> which enabled
> the linker to determine the fully qualified object name and resolve it 
> through the import
> library, since the CUDA SDK libraries do not include un-qualified aliases.

Something the  message didn't say, this only applies to x86 where
stdcall is used, x64 uses only one calling convention for everything,
and this problem does not occur.

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

Re: [FFmpeg-devel] [PATCH] increment initial_prog_date_time when removing old segments

2016-11-12 Thread Steven Liu 
2016-11-12 0:53 GMT+08:00 Michael Niedermayer :

> On Fri, Nov 11, 2016 at 09:59:16PM +0800, Steven Liu wrote:
> > 2016-11-11 21:58 GMT+08:00 Steven Liu :
> >
> > >
> > >
> > > 2016-11-11 21:40 GMT+08:00 Michael Niedermayer  >:
> > >
> > >> On Fri, Nov 11, 2016 at 10:13:43AM +0100, Robert Nagy wrote:
> > >> > Fixes https://trac.ffmpeg.org/ticket/5940#ticket
> > >> >
> > >> > ---
> > >> >  libavformat/hlsenc.c | 1 +
> > >> >  1 file changed, 1 insertion(+)
> > >> >
> > >> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > >> > index 9ca2df7..80a598a 100644
> > >> > --- a/libavformat/hlsenc.c
> > >> > +++ b/libavformat/hlsenc.c
> > >> > @@ -183,6 +183,7 @@ static int hls_delete_old_segments(HLSContext
> > >> *hls) {
> > >> >  segment = hls->old_segments;
> > >> >  while (segment) {
> > >> >  playlist_duration -= segment->duration;
> > >> > +initial_prog_date_time += segment->duration;
> > >>
> > >> src/libavformat/hlsenc.c: In function ‘hls_delete_old_segments’:
> > >> src/libavformat/hlsenc.c:186:9: error: ‘initial_prog_date_time’
> > >> undeclared (first use in this function)
> > >> src/libavformat/hlsenc.c:186:9: note: each undeclared identifier is
> > >> reported only once for each function it appears in
> > >>
> > >>
> > >> [...]
> > >>
> > >> --
> > >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >>
> > >> Those who would give up essential Liberty, to purchase a little
> > >> temporary Safety, deserve neither Liberty nor Safety -- Benjamin
> Franklin
> > >>
> > >> ___
> > >> ffmpeg-devel mailing list
> > >> ffmpeg-devel@ffmpeg.org
> > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>
> > >>
> > > From 4cb283e3796b53c93cfded381c4606304a6ec706 Mon Sep 17 00:00:00 2001
> > > From: Robert Nagy 
> > > Date: Fri, 11 Nov 2016 21:56:00 +0800
> > > Subject: [PATCH] increment initial_prog_date_time when removing old
> > > segments
> > >
> > > Fixes https://trac.ffmpeg.org/ticket/5940#ticket
> > >
> > > Reviewed-by: Michael Niedermayer <>
> > > Signed-off-by: Robert Nagy 
> > > Signed-off-by: Steven Liu 
> > > ---
> > >  libavformat/hlsenc.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > > index 9ca2df7..e16fb0c 100644
> > > --- a/libavformat/hlsenc.c
> > > +++ b/libavformat/hlsenc.c
> > > @@ -183,6 +183,7 @@ static int hls_delete_old_segments(HLSContext
> *hls) {
> > >  segment = hls->old_segments;
> > >  while (segment) {
> > >  playlist_duration -= segment->duration;
> > > +hls->initial_prog_date_time += segment->duration;
> > >  previous_segment = segment;
> > >  segment = previous_segment->next;
> > >  if (playlist_duration <= -previous_segment->duration) {
> > > --
> > > 2.9.3 (Apple Git-75)
> > >
> > >
>
> >  hlsenc.c |1 +
> >  1 file changed, 1 insertion(+)
> > e3727b4f357c8277b28056aec982e89e85efb4a3  0001-increment-initial_prog_
> date_time-when-removing-old-s.patch
> > From 4cb283e3796b53c93cfded381c4606304a6ec706 Mon Sep 17 00:00:00 2001
> > From: Robert Nagy 
> > Date: Fri, 11 Nov 2016 21:56:00 +0800
> > Subject: [PATCH] increment initial_prog_date_time when removing old
> segments
> >
> > Fixes https://trac.ffmpeg.org/ticket/5940#ticket
> >
> > Reviewed-by: Michael Niedermayer <>
> > Signed-off-by: Robert Nagy 
> > Signed-off-by: Steven Liu 
> > ---
> >  libavformat/hlsenc.c | 1 +
> >  1 file changed, 1 insertion(+)
>
> LGTM
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Into a blind darkness they enter who follow after the Ignorance,
> they as if into a greater darkness enter who devote themselves
> to the Knowledge alone. -- Isha Upanishad
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Applied!


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

[FFmpeg-devel] DNXHD timecode for muxing

2016-11-12 Thread Robert Nagy 
I would like to try and add timecode support into the dnxhd enc/dec.

The DNXHD part is pretty simple. However, I'm a little unsure how to make
sure the timecode is read and used during transcoding.

Basically I would like to be able to do:

ffmpeg -i input -timecode:v x -c:v dnxhd - | ffmpeg -i - c:v copy output.mov

Where the timecode from the first process is extracted and used in the mov
container.

Would appreciate any suggestions or guidance on how to achieve this and
whether anyone would like to help out.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel