Re: [FFmpeg-devel] [PATCH] tests/fate/dnxhd: add dnxhr mov tests

[Michael Niedermayer]

On Wed, Aug 03, 2016 at 02:06:21PM -0700, Mark Reid wrote:
> ---
>  tests/fate/vcodec.mak| 18 +-
>  tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov |  4 
>  tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov |  4 
>  tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov |  4 
>  tests/ref/vsynth/vsynth1-dnxhd-uhd-hr-mov|  4 
>  tests/ref/vsynth/vsynth2-dnxhd-hr-hq-mov |  4 
>  tests/ref/vsynth/vsynth2-dnxhd-hr-lb-mov |  4 
>  tests/ref/vsynth/vsynth2-dnxhd-hr-sq-mov |  4 
>  tests/ref/vsynth/vsynth3-dnxhd-hr-hq-mov |  4 
>  tests/ref/vsynth/vsynth3-dnxhd-hr-lb-mov |  4 
>  tests/ref/vsynth/vsynth3-dnxhd-hr-sq-mov |  4 
>  tests/ref/vsynth/vsynth_lena-dnxhd-hr-hq-mov |  4 
>  tests/ref/vsynth/vsynth_lena-dnxhd-hr-lb-mov |  4 
>  tests/ref/vsynth/vsynth_lena-dnxhd-hr-sq-mov |  4 
>  14 files changed, 69 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov
>  create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov
>  create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov
>  create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-uhd-hr-mov
>  create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-hr-hq-mov
>  create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-hr-lb-mov
>  create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-hr-sq-mov
>  create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-hr-hq-mov
>  create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-hr-lb-mov
>  create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-hr-sq-mov
>  create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-hr-hq-mov
>  create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-hr-lb-mov
>  create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-hr-sq-mov

fails on qemu-mips

--- ffmpeg/tests/ref/vsynth/vsynth_lena-dnxhd-hr-hq-mov2016-08-04 
02:58:10.906274759 +0200
+++ tests/data/fate/vsynth_lena-dnxhd-hr-hq-mov 2016-08-04 03:19:26.514301634 
+0200
@@ -1,4 +1,4 @@
-7ffe504b76eaab61aa7c9e7c489493c2 
*tests/data/fate/vsynth_lena-dnxhd-hr-hq-mov.mov
+1437990f6eee843f61ddfb7742f4db67 
*tests/data/fate/vsynth_lena-dnxhd-hr-hq-mov.mov
 4772599 tests/data/fate/vsynth_lena-dnxhd-hr-hq-mov.mov
-0668971f3a93f5886c9b3c1db0b29307 
*tests/data/fate/vsynth_lena-dnxhd-hr-hq-mov.out.rawvideo
+9afce75639422dfe1c61aee09a9f2a1e 
*tests/data/fate/vsynth_lena-dnxhd-hr-hq-mov.out.rawvideo
 stddev:1.34 PSNR: 45.54 MAXDIFF:   23 bytes:  7603200/   760320
Test vsynth_lena-dnxhd-hr-hq-mov failed. Look at 
tests/data/fate/vsynth_lena-dnxhd-hr-hq-mov.err for details.
make: *** [fate-vsynth_lena-dnxhd-hr-hq-mov] Error 1
make: *** Waiting for unfinished jobs
--- ffmpeg/tests/ref/vsynth/vsynth2-dnxhd-hr-hq-mov2016-08-04 
02:58:10.906274759 +0200
+++ tests/data/fate/vsynth2-dnxhd-hr-hq-mov 2016-08-04 03:19:26.574301637 
+0200
@@ -1,4 +1,4 @@
-81b386d921f20e396cf430e003d992a0 *tests/data/fate/vsynth2-dnxhd-hr-hq-mov.mov
+73319ca2930ab36e170a676c18007b10 *tests/data/fate/vsynth2-dnxhd-hr-hq-mov.mov
 4772599 tests/data/fate/vsynth2-dnxhd-hr-hq-mov.mov
-1ddcf688a127b07b5f22caf2d107e112 
*tests/data/fate/vsynth2-dnxhd-hr-hq-mov.out.rawvideo
+e077ac606b3f0bc6346991513e6f5fa4 
*tests/data/fate/vsynth2-dnxhd-hr-hq-mov.out.rawvideo
 stddev:1.56 PSNR: 44.25 MAXDIFF:   33 bytes:  7603200/   760320
Test vsynth2-dnxhd-hr-hq-mov failed. Look at 
tests/data/fate/vsynth2-dnxhd-hr-hq-mov.err for details.
make: *** [fate-vsynth2-dnxhd-hr-hq-mov] Error 1
--- ffmpeg/tests/ref/vsynth/vsynth3-dnxhd-hr-hq-mov2016-08-04 
02:58:10.906274759 +0200
+++ tests/data/fate/vsynth3-dnxhd-hr-hq-mov 2016-08-04 03:19:26.758301641 
+0200
@@ -1,4 +1,4 @@
-52090473216007402c79ec55020eb4d1 *tests/data/fate/vsynth3-dnxhd-hr-hq-mov.mov
+1f7ada7b9a6d5d065fe19d046bd9687e *tests/data/fate/vsynth3-dnxhd-hr-hq-mov.mov
 4772599 tests/data/fate/vsynth3-dnxhd-hr-hq-mov.mov
-aa2e6c13a1e7760a22fccfca9faacdf3 
*tests/data/fate/vsynth3-dnxhd-hr-hq-mov.out.rawvideo
+72dbb9f8058537f7f2f7c78e01d3de62 
*tests/data/fate/vsynth3-dnxhd-hr-hq-mov.out.rawvideo
 stddev:6.92 PSNR: 31.32 MAXDIFF:   50 bytes:86700/ 8670
Test vsynth3-dnxhd-hr-hq-mov failed. Look at 
tests/data/fate/vsynth3-dnxhd-hr-hq-mov.err for details.
make: *** [fate-vsynth3-dnxhd-hr-hq-mov] Error 1
--- ffmpeg/tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov2016-08-04 
02:58:10.906274759 +0200
+++ tests/data/fate/vsynth1-dnxhd-hr-hq-mov 2016-08-04 03:19:27.074301647 
+0200
@@ -1,4 +1,4 @@
-c3d235535a67f8716c867a26ea2e6973 *tests/data/fate/vsynth1-dnxhd-hr-hq-mov.mov
+5abb6bfecd8c285248ea0638d0c40376 *tests/data/fate/vsynth1-dnxhd-hr-hq-mov.mov
 4772599 tests/data/fate/vsynth1-dnxhd-hr-hq-mov.mov
-e09ffa29e069e4dac0b8ce9692f9cccb 
*tests/data/fate/vsynth1-dnxhd-hr-hq-mov.out.rawvideo
+07a48aed8f020e68391b63a400516e7f 
*tests/data/fate/vsynth1-dnxhd-hr-hq-mov.out.rawvideo
 stddev:5.73 PSNR: 32.96 MAXDIFF:   56 bytes:  7603200/   760320
Test vsynth1-dnxhd-hr-hq-mov failed. Look at 

Re: [FFmpeg-devel] [PATCH] avcodec: don't include vdpau_compat.h when vdpau is not enabled

[James Almer]

On 8/3/2016 8:35 PM, James Almer wrote:
> On 8/3/2016 7:59 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> 2016-08-04 0:33 GMT+02:00 James Almer :
>>> This removes unnecessary header dependencies.
>>
>> Why is this an advantage?
> 
> h263, vc1 and mpeg decoder were pointlessly pulling the entire set
> of h264 headers because of it.
> 
>>
>>>  5 files changed, 25 insertions(+), 20 deletions(-)
>>
>> This doesn't imply a simplification...

Is this one better?

>From bb2ccb375ad7edc4fd7fbb8d6d4a2d36e15d0b5c Mon Sep 17 00:00:00 2001
From: James Almer 
Date: Wed, 3 Aug 2016 21:32:20 -0300
Subject: [PATCH] avcodec/vdpau_compat: Include headers as needed

Signed-off-by: James Almer 
---
 libavcodec/h263dec.c  |  4 ++--
 libavcodec/h264_picture.c | 10 --
 libavcodec/h264dec.c  | 11 +--
 libavcodec/mpeg12dec.c|  5 ++---
 libavcodec/vc1dec.c   |  5 ++---
 libavcodec/vdpau_compat.h |  3 +++
 6 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index d0da1d3..f412961 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -603,8 +603,8 @@ retry:
 if (!s->divx_packed && !avctx->hwaccel)
 ff_thread_finish_setup(avctx);
 
-#if FF_API_CAP_VDPAU
-if (CONFIG_MPEG4_VDPAU_DECODER && (s->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)) {
+#if FF_API_CAP_VDPAU && CONFIG_MPEG4_VDPAU_DECODER
+if (s->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU) {
 ff_vdpau_mpeg4_decode_picture(avctx->priv_data, s->gb.buffer, s->gb.buffer_end - s->gb.buffer);
 goto frame_end;
 }
diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
index f634d2a..7060dbc 100644
--- a/libavcodec/h264_picture.c
+++ b/libavcodec/h264_picture.c
@@ -156,9 +156,8 @@ int ff_h264_field_end(H264Context *h, H264SliceContext *sl, int in_setup)
 int err = 0;
 h->mb_y = 0;
 
-#if FF_API_CAP_VDPAU
-if (CONFIG_H264_VDPAU_DECODER &&
-h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+if (h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
 ff_vdpau_h264_set_reference_frames(h);
 #endif
 
@@ -179,9 +178,8 @@ int ff_h264_field_end(H264Context *h, H264SliceContext *sl, int in_setup)
"hardware accelerator failed to decode picture\n");
 }
 
-#if FF_API_CAP_VDPAU
-if (CONFIG_H264_VDPAU_DECODER &&
-h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+if (h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
 ff_vdpau_h264_picture_complete(h);
 #endif
 
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 323639d..f9188c3 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -50,6 +50,7 @@
 #include "mathops.h"
 #include "me_cmp.h"
 #include "mpegutils.h"
+#include "mpegvideo.h"
 #include "profiles.h"
 #include "rectangle.h"
 #include "thread.h"
@@ -844,9 +845,8 @@ again:
 if (h->avctx->hwaccel &&
 (ret = h->avctx->hwaccel->start_frame(h->avctx, buf, buf_size)) < 0)
 goto end;
-#if FF_API_CAP_VDPAU
-if (CONFIG_H264_VDPAU_DECODER &&
-h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+if (h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
 ff_vdpau_h264_picture_start(h);
 #endif
 }
@@ -858,9 +858,8 @@ again:
nal->raw_size);
 if (ret < 0)
 goto end;
-#if FF_API_CAP_VDPAU
-} else if (CONFIG_H264_VDPAU_DECODER &&
-   h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU) {
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+} else if (h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU) {
 ff_vdpau_add_data_chunk(h->cur_pic_ptr->f->data[0],
 start_code,
 sizeof(start_code));
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 204a578..f779a3d 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2433,9 +2433,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame *picture,
 s2->er.error_count += s2->thread_context[i]->er.error_count;
 }
 
-#if FF_API_VDPAU
-if ((CONFIG_MPEG_VDPAU_DECODER || CONFIG_MPEG1_VDPAU_DECODER)
-&& uses_vdpau(avctx))
+#if FF_API_VDPAU && (CONFIG_MPEG_VDPAU_DECODER || CONFIG_MPEG1_VDPAU_DECODER)
+if (uses_vdpau(avctx))
 ff_vdpau_mpeg_picture_complete(s2, buf, buf_size, s->slice_count);
 #endif
 
diff 

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Ronald S. Bultje]

Hi,

On Wed, Aug 3, 2016 at 7:48 PM, Ronald S. Bultje  wrote:

> Hi,
>
> On Wed, Aug 3, 2016 at 1:57 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> Hi all
>>
>> Sun, Jul 31, 2016 at 10:01:00PM +0200, Michael Niedermayer wrote:
>> > Hi all
>> >
>> > you have a great idea for a Outreachy task or a GSoC task ?
>> > Or something you always wanted to do but never had the time and
>> > it would fit in the time for GSoC/Outreachy ?
>> > Or some feature you always wanted which would fit as a task?
>> > Also keep in mind Outreachy is more flexible and not limited to
>> > coding tasks !
>> > reply and dump it here below:
>>
>> ping ?
>>
>> also cc-ing ffmpeg-user
>>
>> or are all feature requests on trac fake and noone has anything they
>> think should be implemented ?
>>
>> we need ideas for Outreachy, the page is EMPTY:
>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12
>
>
> I have some ideas. Most are TODOs / extensions to stuff I wrote that I
> never ended up doing myself. Some might be hard.
>
> vp9:
> - avx2 loopfilter functions. Qualification task: explain to me without any
> guidance why it's an issue for AVX2 (or SSE2) that the loopfilter in vp9.c
> works on 8px blocks, and explain how I solved that to work on 16px blocks
> to use SSE2 instructions, and likewise explain how you would extend that to
> work on 32px blocks.
> - coefficient reading optimizations or arithmetic symbol reading
> optimizations. I think this is too hard but it would be an amazing speed
> optimization in vp9 decoding, since this is where pretty much all runtime
> is spent after other optimizations.
> - tile threading. This may actually be a nice qual task for the next block
> since this is quite easy.
>
> frame/slice-mt:
> - implement a mode that allows combining those. Qual task could be to
> implement vp9 tile threading or something like that. Final deliverable
> would implement this for at least vpN codec and one h.26x codec.
>
> I'll think about others. I'm willing to mentor the above maybe.
>

Another one, also for vp8/9:
- alpha plane support for native decoders. (Thanks to James for remembering
about this, I had forgotten.)

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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Ronald S. Bultje]

Hi,

On Wed, Aug 3, 2016 at 7:48 PM, Ronald S. Bultje  wrote:

> Hi,
>
> On Wed, Aug 3, 2016 at 1:57 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> Hi all
>>
>> Sun, Jul 31, 2016 at 10:01:00PM +0200, Michael Niedermayer wrote:
>> > Hi all
>> >
>> > you have a great idea for a Outreachy task or a GSoC task ?
>> > Or something you always wanted to do but never had the time and
>> > it would fit in the time for GSoC/Outreachy ?
>> > Or some feature you always wanted which would fit as a task?
>> > Also keep in mind Outreachy is more flexible and not limited to
>> > coding tasks !
>> > reply and dump it here below:
>>
>> ping ?
>>
>> also cc-ing ffmpeg-user
>>
>> or are all feature requests on trac fake and noone has anything they
>> think should be implemented ?
>>
>> we need ideas for Outreachy, the page is EMPTY:
>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12
>
>
> I have some ideas. Most are TODOs / extensions to stuff I wrote that I
> never ended up doing myself. Some might be hard.
>
> vp9:
> - avx2 loopfilter functions. Qualification task: explain to me without any
> guidance why it's an issue for AVX2 (or SSE2) that the loopfilter in vp9.c
> works on 8px blocks, and explain how I solved that to work on 16px blocks
> to use SSE2 instructions, and likewise explain how you would extend that to
> work on 32px blocks.
> - coefficient reading optimizations or arithmetic symbol reading
> optimizations. I think this is too hard but it would be an amazing speed
> optimization in vp9 decoding, since this is where pretty much all runtime
> is spent after other optimizations.
> - tile threading. This may actually be a nice qual task for the next block
> since this is quite easy.
>
> frame/slice-mt:
> - implement a mode that allows combining those. Qual task could be to
> implement vp9 tile threading or something like that. Final deliverable
> would implement this for at least vpN codec and one h.26x codec.
>
> I'll think about others. I'm willing to mentor the above maybe.
>

Thinking more about frame/slice-mt combination, I'd also like someone to
implement WPP threading (in addition to tile/frame) for HEVC, and again a
mode to combine WPP/tile + frame. The term "slice-mt" also becomes
questionable and might need renaming to something broader.

But then again, I also feel that for outreachy, these tasks might be hard
and "vp9 tile" or "hevc wpp" might be a full outreachy task on their own,
and "*-mt combining" might just be too hard for a "new" student. Comments?
I also don't want to mentor everything myself so I'd probably want someone
else to mentor hevc bits so I can remain more narrowly focussed on vp9 for
now.

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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Ronald S. Bultje]

Hi,

On Wed, Aug 3, 2016 at 1:57 PM, Michael Niedermayer 
wrote:

> Hi all
>
> Sun, Jul 31, 2016 at 10:01:00PM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > you have a great idea for a Outreachy task or a GSoC task ?
> > Or something you always wanted to do but never had the time and
> > it would fit in the time for GSoC/Outreachy ?
> > Or some feature you always wanted which would fit as a task?
> > Also keep in mind Outreachy is more flexible and not limited to
> > coding tasks !
> > reply and dump it here below:
>
> ping ?
>
> also cc-ing ffmpeg-user
>
> or are all feature requests on trac fake and noone has anything they
> think should be implemented ?
>
> we need ideas for Outreachy, the page is EMPTY:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12


I have some ideas. Most are TODOs / extensions to stuff I wrote that I
never ended up doing myself. Some might be hard.

vp9:
- avx2 loopfilter functions. Qualification task: explain to me without any
guidance why it's an issue for AVX2 (or SSE2) that the loopfilter in vp9.c
works on 8px blocks, and explain how I solved that to work on 16px blocks
to use SSE2 instructions, and likewise explain how you would extend that to
work on 32px blocks.
- coefficient reading optimizations or arithmetic symbol reading
optimizations. I think this is too hard but it would be an amazing speed
optimization in vp9 decoding, since this is where pretty much all runtime
is spent after other optimizations.
- tile threading. This may actually be a nice qual task for the next block
since this is quite easy.

frame/slice-mt:
- implement a mode that allows combining those. Qual task could be to
implement vp9 tile threading or something like that. Final deliverable
would implement this for at least vpN codec and one h.26x codec.

I'll think about others. I'm willing to mentor the above maybe.

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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Michael Niedermayer]

On Wed, Aug 03, 2016 at 07:46:26PM +, Timothy Gu wrote:
> On Wed, Aug 3, 2016 at 12:36 PM Michael Niedermayer 
> wrote:
> 
> > what about writing guides/howtos about how to build/replace FFmpeg
> > on all kinds of hw
> >
> 
> That's the responsibility of the HW vendor.
> 
> 
> > i mean everything these days uses FFmpeg below one or more layers
> > and users should have the right to replace their products FFmpeg
> > maybe with one that has more features enabled or a newer version
> > but in practice for how many products that contain FFmpeg can
> > the user actually do this easily? ...
> >
> 
> Practically none, an amount easily matched by the number of users who are
> interested in doing that.

I am interrested in modifying stuff, and i think some developers
i know are too, so is probably the hacking and "power user" community
around whatever specific device one considers
A sizeable portion of the whole user base that is not but an important
portion.
If you provide a guide that allows people to replace the installed
FFmpeg binary on some hw, that hw might gain support for formats
providing better quality per bitrate or are more free, or ones that
where disabled due whatever marketing or legal reasons

Having guides like this can get users interrested in hacking and
modifying stuff, does it help us, no probably not but to me
getting more people interrested in any kind of hacking, programming,
science or engeneering sounds like a win.

Most users dont even know what is used to decode multimedia

Maybe this suggestion doesnt fit FFmpeg Outreachy, i dont know, it
was just a suggestion ...


[...]
-- 
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] avcodec: don't include vdpau_compat.h when vdpau is not enabled

[Carl Eugen Hoyos]

Hi!

2016-08-04 0:33 GMT+02:00 James Almer :
> This removes unnecessary header dependencies.

Why is this an advantage?

>  5 files changed, 25 insertions(+), 20 deletions(-)

This doesn't imply a simplification...

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

Re: [FFmpeg-devel] [PATCH 1/2] v3 - SCTE extraction from mpegts

[Carl Eugen Hoyos]

2016-08-03 21:36 GMT+02:00 Carlos Fernandez Sanz :
> From: Carlos 
> -
> -} else {

> +} else if (tss->type == MPEGTS_PES) {
>  int ret;
>  // Note: The position here points actually behind the current packet.
> -if (tss->type == MPEGTS_PES) {
> -if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
> +if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
>  pos - ts->raw_packet_size)) 
> < 0)
> -return ret;
> -}
> +return ret;

This looks lilke an unrelated change to me.

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

[FFmpeg-devel] [PATCH] avcodec: don't include vdpau_compat.h when vdpau is not enabled

[James Almer]

This removes unnecessary header dependencies.

Signed-off-by: James Almer 
---
 libavcodec/h263dec.c  |  6 --
 libavcodec/h264_picture.c | 12 ++--
 libavcodec/h264dec.c  | 13 +++--
 libavcodec/mpeg12dec.c|  7 ---
 libavcodec/vc1dec.c   |  7 ---
 5 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index d0da1d3..953bbc5 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -41,7 +41,9 @@
 #include "mpegvideo.h"
 #include "msmpeg4.h"
 #include "qpeldsp.h"
+#if FF_API_CAP_VDPAU && CONFIG_MPEG4_VDPAU_DECODER
 #include "vdpau_compat.h"
+#endif
 #include "thread.h"
 #include "wmv2.h"
 
@@ -603,8 +605,8 @@ retry:
 if (!s->divx_packed && !avctx->hwaccel)
 ff_thread_finish_setup(avctx);
 
-#if FF_API_CAP_VDPAU
-if (CONFIG_MPEG4_VDPAU_DECODER && (s->avctx->codec->capabilities & 
AV_CODEC_CAP_HWACCEL_VDPAU)) {
+#if FF_API_CAP_VDPAU && CONFIG_MPEG4_VDPAU_DECODER
+if (s->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU) {
 ff_vdpau_mpeg4_decode_picture(avctx->priv_data, s->gb.buffer, 
s->gb.buffer_end - s->gb.buffer);
 goto frame_end;
 }
diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
index f634d2a..a721b8d 100644
--- a/libavcodec/h264_picture.c
+++ b/libavcodec/h264_picture.c
@@ -41,7 +41,9 @@
 #include "mpegutils.h"
 #include "rectangle.h"
 #include "thread.h"
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
 #include "vdpau_compat.h"
+#endif
 
 void ff_h264_unref_picture(H264Context *h, H264Picture *pic)
 {
@@ -156,9 +158,8 @@ int ff_h264_field_end(H264Context *h, H264SliceContext *sl, 
int in_setup)
 int err = 0;
 h->mb_y = 0;
 
-#if FF_API_CAP_VDPAU
-if (CONFIG_H264_VDPAU_DECODER &&
-h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+if (h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
 ff_vdpau_h264_set_reference_frames(h);
 #endif
 
@@ -179,9 +180,8 @@ int ff_h264_field_end(H264Context *h, H264SliceContext *sl, 
int in_setup)
"hardware accelerator failed to decode picture\n");
 }
 
-#if FF_API_CAP_VDPAU
-if (CONFIG_H264_VDPAU_DECODER &&
-h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+if (h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
 ff_vdpau_h264_picture_complete(h);
 #endif
 
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 323639d..35df360 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -50,10 +50,13 @@
 #include "mathops.h"
 #include "me_cmp.h"
 #include "mpegutils.h"
+#include "mpegvideo.h"
 #include "profiles.h"
 #include "rectangle.h"
 #include "thread.h"
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
 #include "vdpau_compat.h"
+#endif
 
 static int h264_decode_end(AVCodecContext *avctx);
 
@@ -844,9 +847,8 @@ again:
 if (h->avctx->hwaccel &&
 (ret = h->avctx->hwaccel->start_frame(h->avctx, buf, 
buf_size)) < 0)
 goto end;
-#if FF_API_CAP_VDPAU
-if (CONFIG_H264_VDPAU_DECODER &&
-h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+if (h->avctx->codec->capabilities & AV_CODEC_CAP_HWACCEL_VDPAU)
 ff_vdpau_h264_picture_start(h);
 #endif
 }
@@ -858,9 +860,8 @@ again:
nal->raw_size);
 if (ret < 0)
 goto end;
-#if FF_API_CAP_VDPAU
-} else if (CONFIG_H264_VDPAU_DECODER &&
-   h->avctx->codec->capabilities & 
AV_CODEC_CAP_HWACCEL_VDPAU) {
+#if FF_API_CAP_VDPAU && CONFIG_H264_VDPAU_DECODER
+} else if (h->avctx->codec->capabilities & 
AV_CODEC_CAP_HWACCEL_VDPAU) {
 ff_vdpau_add_data_chunk(h->cur_pic_ptr->f->data[0],
 start_code,
 sizeof(start_code));
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 204a578..9f3daa3 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -47,7 +47,9 @@
 #include "profiles.h"
 #include "thread.h"
 #include "version.h"
+#if FF_API_VDPAU && (CONFIG_MPEG_VDPAU_DECODER || CONFIG_MPEG1_VDPAU_DECODER)
 #include "vdpau_compat.h"
+#endif
 #include "xvmc_internal.h"
 
 typedef struct Mpeg1Context {
@@ -2433,9 +2435,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
 s2->er.error_count += 
s2->thread_context[i]->er.error_count;
 }
 
-#if FF_API_VDPAU
-if ((CONFIG_MPEG_VDPAU_DECODER || CONFIG_MPEG1_VDPAU_DECODER)
-&& uses_vdpau(avctx))
+#if FF_API_VDPAU && 

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Kieran O Leary]

Hi

On 3 Aug 2016 6:58 p.m., "Michael Niedermayer" 
wrote:
>
> Hi all

>
> we need ideas for Outreachy, the page is EMPTY:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12
>

How about EBU-STL subtitle decoding? It's currently unsupported. It's a non
text based  subtitle format that is used in a broadcast environment. I'm
not sure if that is too specific to be of interest.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/dnxhdenc: remove setting the codec_tag

[Mark Reid]

setting the codec_tag no longer needed by movenc
it uses the dnxhr profile instead
---
 libavcodec/dnxhdenc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index b0ee8a2..cbf4cd5 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -341,9 +341,6 @@ static av_cold int dnxhd_encode_init(AVCodecContext *avctx)
 }
 av_log(avctx, AV_LOG_DEBUG, "cid %d\n", ctx->cid);
 
-if (ctx->cid >= 1270 && ctx->cid <= 1274)
-avctx->codec_tag = MKTAG('A','V','d','h');
-
 if (avctx->width < 256 || avctx->height < 120) {
 av_log(avctx, AV_LOG_ERROR,
"Input dimensions too small, input must be at least 256x120\n");
-- 
2.9.2

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

Re: [FFmpeg-devel] [PATCH] fate: add DNxHR 12-bit example.

[Mark Reid]

On Tue, Aug 2, 2016 at 11:51 PM, Steven Robertson  wrote:
> Test file available at http://tinyurl.com/fate-dnxhd-12bit .
>
> Signed-off-by: Steven Robertson 
> ---
>  tests/fate/dnxhd.mak   | 2 ++
>  tests/ref/fate/dnxhr-12bit | 6 ++
>  2 files changed, 8 insertions(+)
>  create mode 100644 tests/ref/fate/dnxhr-12bit
>
> diff --git a/tests/fate/dnxhd.mak b/tests/fate/dnxhd.mak
> index 4008e6c..672290f 100644
> --- a/tests/fate/dnxhd.mak
> +++ b/tests/fate/dnxhd.mak
> @@ -1,5 +1,6 @@
>  FATE_DNXHD = fate-dnxhd-mbaff \
>   fate-dnxhr-444   \
> + fate-dnxhr-12bit \
>   fate-dnxhr-parse \
>   fate-dnxhr-prefix1   \
>   fate-dnxhr-prefix2   \
> @@ -12,6 +13,7 @@ fate-dnxhd: $(FATE_DNXHD) $(FATE_VCODEC_DNXHD)
>
>  fate-dnxhd-mbaff: CMD = framecrc -flags +bitexact -idct simple -i 
> $(TARGET_SAMPLES)/dnxhd/dnxhd100_cid1260.mov -pix_fmt yuv422p10le
>  fate-dnxhr-444:   CMD = framecrc -flags +bitexact -idct simple -i 
> $(TARGET_SAMPLES)/dnxhd/dnxhr444_cid1270.mov -pix_fmt yuv444p10le
> +fate-dnxhr-12bit: CMD = framecrc -flags +bitexact -idct simple -i 
> $(TARGET_SAMPLES)/dnxhd/dnxhr_cid1271_12bit.mov -pix_fmt yuv444p12le

shouldn't the pix fmt be yuv422p12le for hqx?

>  fate-dnxhr-parse: CMD = framecrc -flags +bitexact -idct simple -i 
> $(TARGET_SAMPLES)/dnxhd/dnxhr_cid1274.dnxhr -pix_fmt yuv422p
>  fate-dnxhr-prefix1: CMD = framecrc -flags +bitexact -idct simple -i 
> $(TARGET_SAMPLES)/dnxhd/prefix-256x1536.dnxhr -pix_fmt yuv422p
>  fate-dnxhr-prefix2: CMD = framecrc -flags +bitexact -idct simple -i 
> $(TARGET_SAMPLES)/dnxhd/prefix-256x1716.dnxhr -pix_fmt yuv422p
> diff --git a/tests/ref/fate/dnxhr-12bit b/tests/ref/fate/dnxhr-12bit
> new file mode 100644
> index 000..11bcb9a
> --- /dev/null
> +++ b/tests/ref/fate/dnxhr-12bit
> @@ -0,0 +1,6 @@
> +#tb 0: 1/24
> +#media_type 0: video
> +#codec_id 0: rawvideo
> +#dimensions 0: 1920x1080
> +#sar 0: 1/1
> +0,  0,  0,1, 12441600, 0xe3585eed
> --
> 2.8.0.rc2
>
> ___
> 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] tests/fate/dnxhd: add dnxhr mov tests

[Mark Reid]

---
 tests/fate/vcodec.mak| 18 +-
 tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov |  4 
 tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov |  4 
 tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov |  4 
 tests/ref/vsynth/vsynth1-dnxhd-uhd-hr-mov|  4 
 tests/ref/vsynth/vsynth2-dnxhd-hr-hq-mov |  4 
 tests/ref/vsynth/vsynth2-dnxhd-hr-lb-mov |  4 
 tests/ref/vsynth/vsynth2-dnxhd-hr-sq-mov |  4 
 tests/ref/vsynth/vsynth3-dnxhd-hr-hq-mov |  4 
 tests/ref/vsynth/vsynth3-dnxhd-hr-lb-mov |  4 
 tests/ref/vsynth/vsynth3-dnxhd-hr-sq-mov |  4 
 tests/ref/vsynth/vsynth_lena-dnxhd-hr-hq-mov |  4 
 tests/ref/vsynth/vsynth_lena-dnxhd-hr-lb-mov |  4 
 tests/ref/vsynth/vsynth_lena-dnxhd-hr-sq-mov |  4 
 14 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov
 create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov
 create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov
 create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-uhd-hr-mov
 create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-hr-hq-mov
 create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-hr-lb-mov
 create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-hr-sq-mov
 create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-hr-hq-mov
 create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-hr-lb-mov
 create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-hr-sq-mov
 create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-hr-hq-mov
 create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-hr-lb-mov
 create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-hr-sq-mov

diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index c62abe4..94ec04f 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.mak
@@ -78,7 +78,8 @@ fate-vsynth%-dnxhd-2k-hr-hq:  ENCOPTS= -s 2k -profile:v 
dnxhr_hq \
 fate-vsynth%-dnxhd-2k-hr-hq:  DECOPTS= -sws_flags 
area+accurate_rnd+bitexact
 fate-vsynth%-dnxhd-2k-hr-hq:  FMT= dnxhd
 
-FATE_VCODEC-$(call ENCDEC, DNXHD, MOV)  += dnxhd-1080i dnxhd-1080i-10bit 
dnxhd-1080i-colr
+FATE_VCODEC-$(call ENCDEC, DNXHD, MOV)  += dnxhd-1080i dnxhd-1080i-10bit 
dnxhd-1080i-colr \
+   dnxhd-hr-lb-mov dnxhd-hr-sq-mov 
dnxhd-hr-hq-mov
 fate-vsynth%-dnxhd-1080i:ENCOPTS = -s hd1080 -b 120M -flags +ildct \
-pix_fmt yuv422p -frames 5 -qmax 8
 fate-vsynth%-dnxhd-1080i:FMT = mov
@@ -93,6 +94,21 @@ fate-vsynth%-dnxhd-1080i-colr:   ENCOPTS = -s hd1080 -b 120M 
-flags +ildct -movf
 fate-vsynth%-dnxhd-1080i-colr:   DECOPTS = -sws_flags 
area+accurate_rnd+bitexact
 fate-vsynth%-dnxhd-1080i-colr:   FMT = mov
 
+fate-vsynth%-dnxhd-hr-lb-mov:   ENCOPTS = -s uhd2160 -profile:v dnxhr_lb \
+   -pix_fmt yuv422p -frames 5
+fate-vsynth%-dnxhd-hr-lb-mov:   DECOPTS = -sws_flags area+accurate_rnd+bitexact
+fate-vsynth%-dnxhd-hr-lb-mov:   FMT = mov
+
+fate-vsynth%-dnxhd-hr-sq-mov:   ENCOPTS = -s 2kscope -profile:v dnxhr_sq \
+   -pix_fmt yuv422p -frames 5
+fate-vsynth%-dnxhd-hr-sq-mov:   DECOPTS = -sws_flags area+accurate_rnd+bitexact
+fate-vsynth%-dnxhd-hr-sq-mov:   FMT = mov
+
+fate-vsynth%-dnxhd-hr-hq-mov:   ENCOPTS = -s 2kflat -profile:v dnxhr_hq \
+   -pix_fmt yuv422p -frames 5
+fate-vsynth%-dnxhd-hr-hq-mov:   DECOPTS = -sws_flags area+accurate_rnd+bitexact
+fate-vsynth%-dnxhd-hr-hq-mov:   FMT = mov
+
 FATE_VCODEC-$(call ENCDEC, DVVIDEO, DV) += dv dv-411 dv-50
 fate-vsynth%-dv: CODEC   = dvvideo
 fate-vsynth%-dv: ENCOPTS = -dct int -s pal
diff --git a/tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov 
b/tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov
new file mode 100644
index 000..f6eaf66
--- /dev/null
+++ b/tests/ref/vsynth/vsynth1-dnxhd-hr-hq-mov
@@ -0,0 +1,4 @@
+c3d235535a67f8716c867a26ea2e6973 *tests/data/fate/vsynth1-dnxhd-hr-hq-mov.mov
+4772599 tests/data/fate/vsynth1-dnxhd-hr-hq-mov.mov
+e09ffa29e069e4dac0b8ce9692f9cccb 
*tests/data/fate/vsynth1-dnxhd-hr-hq-mov.out.rawvideo
+stddev:5.73 PSNR: 32.96 MAXDIFF:   56 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov 
b/tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov
new file mode 100644
index 000..2e2b4a3
--- /dev/null
+++ b/tests/ref/vsynth/vsynth1-dnxhd-hr-lb-mov
@@ -0,0 +1,4 @@
+254aa3f0be811882ff351172fd391492 *tests/data/fate/vsynth1-dnxhd-hr-lb-mov.mov
+3748599 tests/data/fate/vsynth1-dnxhd-hr-lb-mov.mov
+21c68252f500bada13ccce232e1ecfca 
*tests/data/fate/vsynth1-dnxhd-hr-lb-mov.out.rawvideo
+stddev:5.59 PSNR: 33.17 MAXDIFF:   55 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov 
b/tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov
new file mode 100644
index 000..d9b3afd
--- /dev/null
+++ b/tests/ref/vsynth/vsynth1-dnxhd-hr-sq-mov
@@ -0,0 +1,4 @@

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Timothy Gu]

On Wed, Aug 3, 2016 at 11:57 AM James Almer  wrote:

> On 7/31/2016 5:01 PM, Michael Niedermayer wrote:
> > Hi all
> >
> > you have a great idea for a Outreachy task or a GSoC task ?
> > Or something you always wanted to do but never had the time and
> > it would fit in the time for GSoC/Outreachy ?
> > Or some feature you always wanted which would fit as a task?
> > Also keep in mind Outreachy is more flexible and not limited to
> > coding tasks !
> > reply and dump it here below:
>
> Writing new examples or porting decoding_encoding.c and
> demuxing_decoding.c to use codecpar and send/receive packet/frame.
>

+1

Maye also adding or extending doxy on public and private header,
> sort of like what Timothy did the last couple days, but as Paul
> said, coding related there's probably not a whole lot left that
> can be easily done by students.
>

+1 too.

Also fixing up some parts of FATE I don't have time to fix, and adapting
Doxygen output style to the website. Web development sounds like a buzzword
these days.

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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Timothy Gu]

On Wed, Aug 3, 2016 at 12:36 PM Michael Niedermayer 
wrote:

> what about writing guides/howtos about how to build/replace FFmpeg
> on all kinds of hw
>

That's the responsibility of the HW vendor.


> i mean everything these days uses FFmpeg below one or more layers
> and users should have the right to replace their products FFmpeg
> maybe with one that has more features enabled or a newer version
> but in practice for how many products that contain FFmpeg can
> the user actually do this easily? ...
>

Practically none, an amount easily matched by the number of users who are
interested in doing that.

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

[FFmpeg-devel] [PATCH 2/2] v3 - SCTE-35 support in hlsenc

[Carlos Fernandez Sanz]

From: carlos 

Signed-off-by: carlos 
---
 libavformat/Makefile  |   2 +-
 libavformat/hlsenc.c  | 110 +---
 libavformat/scte_35.c | 482 ++
 libavformat/scte_35.h |  76 
 4 files changed, 646 insertions(+), 24 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index e2cb474..7da9e67 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -204,7 +204,7 @@ OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
 OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
 OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
 OBJS-$(CONFIG_HLS_DEMUXER)   += hls.o
-OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o
+OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o scte_35.o
 OBJS-$(CONFIG_HNM_DEMUXER)   += hnm.o
 OBJS-$(CONFIG_ICO_DEMUXER)   += icodec.o
 OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5dc518d..94e058e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -38,6 +38,7 @@
 #include "avio_internal.h"
 #include "internal.h"
 #include "os_support.h"
+#include "scte_35.h"
 
 #define KEYSIZE 16
 #define LINE_BUFFER_SIZE 1024
@@ -48,6 +49,10 @@ typedef struct HLSSegment {
 double duration; /* in seconds */
 int64_t pos;
 int64_t size;
+struct scte_35_event *event;
+int out;
+int adv_count;
+int64_t start_pts;
 
 char key_uri[LINE_BUFFER_SIZE + 1];
 char iv_string[KEYSIZE*2 + 1];
@@ -89,6 +94,8 @@ typedef struct HLSContext {
 uint32_t flags;// enum HLSFlags
 uint32_t pl_type;  // enum PlaylistType
 char *segment_filename;
+char *adv_filename;
+char *adv_subfilename;
 
 int use_localtime;  ///< flag to expand filename with localtime
 int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
@@ -104,6 +111,7 @@ typedef struct HLSContext {
 int nb_entries;
 int discontinuity_set;
 
+struct scte_35_interface *scte_iface;
 HLSSegment *segments;
 HLSSegment *last_segment;
 HLSSegment *old_segments;
@@ -203,6 +211,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
 av_freep();
 previous_segment = segment;
 segment = previous_segment->next;
+if (hls->scte_iface)
+hls->scte_iface->unref_scte35_event(_segment->event);
 av_free(previous_segment);
 }
 
@@ -314,8 +324,8 @@ static int hls_mux_init(AVFormatContext *s)
 }
 
 /* Create a new segment and append it to the segment list */
-static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, 
double duration,
-  int64_t pos, int64_t size)
+static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, 
double duration, int64_t pos,
+  int64_t start_pts, struct scte_35_event *event, 
int64_t size)
 {
 HLSSegment *en = av_malloc(sizeof(*en));
 char *tmp, *p;
@@ -349,11 +359,25 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 else
 en->sub_filename[0] = '\0';
 
-en->duration = duration;
-en->pos  = pos;
-en->size = size;
+en->duration   = duration;
+en->pos= pos;
+en->event  = event;
+en->size   = size;
+en->start_pts  = start_pts;
 en->next = NULL;
 
+if (hls->scte_iface) {
+if (hls->scte_iface->event_out == EVENT_OUT_CONT) {
+en->adv_count = hls->scte_iface->adv_count;
+hls->scte_iface->adv_count++;
+en->out = hls->scte_iface->event_out;
+} else {
+hls->scte_iface->adv_count = 0;
+en->out = hls->scte_iface->event_out;
+}
+}
+
+
 if (hls->key_info_file) {
 av_strlcpy(en->key_uri, hls->key_uri, sizeof(en->key_uri));
 av_strlcpy(en->iv_string, hls->iv_string, sizeof(en->iv_string));
@@ -475,9 +499,23 @@ static int hls_window(AVFormatContext *s, int last)
 if (hls->flags & HLS_SINGLE_FILE)
  avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
  en->size, en->pos);
-if (hls->baseurl)
-avio_printf(out, "%s", hls->baseurl);
-avio_printf(out, "%s\n", en->filename);
+if (hls->scte_iface && (en->event || en->out) ) {
+char *str;
+char fname[1024] = "";
+if (hls->adv_filename) {
+str = hls->scte_iface->get_hls_string(hls->scte_iface, 
en->event, hls->adv_filename, en->out, en->adv_count, en->start_pts);
+} else {
+if (hls->baseurl)
+strncat(fname, hls->baseurl, 1024);
+strncat(fname, en->filename, 1024);
+str = 

[FFmpeg-devel] [PATCH 1/2] v3 - SCTE extraction from mpegts

[Carlos Fernandez Sanz]

From: Carlos 

Signed-off-by: carlos 
---
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  6 ++
 libavformat/mpegts.c| 51 +++--
 3 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3b21537..601ee5c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -630,6 +630,7 @@ enum AVCodecID {
 /* other specific kind of codecs (generally used for attachments) */
 AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID pointing at 
the start of various fake codecs.
 AV_CODEC_ID_TTF = 0x18000,
+AV_CODEC_ID_SCTE_35,
 
 AV_CODEC_ID_BINTEXT= 0x18800,
 AV_CODEC_ID_XBIN,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index dea17c9..5c00be0 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2950,6 +2950,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("binary data"),
 .mime_types= MT("application/octet-stream"),
 },
+{
+.id= AV_CODEC_ID_SCTE_35,
+.type  = AVMEDIA_TYPE_DATA,
+.name  = "scte_35",
+.long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
+},
 
 /* deprecated codec ids */
 };
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b31d233..3c2e448 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -57,6 +57,7 @@ enum MpegTSFilterType {
 MPEGTS_PES,
 MPEGTS_SECTION,
 MPEGTS_PCR,
+MPEGTS_DATA,
 };
 
 typedef struct MpegTSFilter MpegTSFilter;
@@ -510,6 +511,11 @@ static MpegTSFilter *mpegts_open_pcr_filter(MpegTSContext 
*ts, unsigned int pid)
 return mpegts_open_filter(ts, pid, MPEGTS_PCR);
 }
 
+static MpegTSFilter *mpegts_open_data_filter(MpegTSContext *ts, unsigned int 
pid)
+{
+return mpegts_open_filter(ts, pid, MPEGTS_DATA);
+}
+
 static void mpegts_close_filter(MpegTSContext *ts, MpegTSFilter *filter)
 {
 int pid;
@@ -725,6 +731,12 @@ static const StreamType HDMV_types[] = {
 { 0 },
 };
 
+/* SCTE types */
+static const StreamType SCTE_types[] = {
+{ 0x86, AVMEDIA_TYPE_DATA,  AV_CODEC_ID_SCTE_35},
+{ 0 },
+};
+
 /* ATSC ? */
 static const StreamType MISC_types[] = {
 { 0x81, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AC3 },
@@ -872,6 +884,13 @@ static void reset_pes_packet_state(PESContext *pes)
 av_buffer_unref(>buffer);
 }
 
+static void new_data_packet(const uint8_t *buffer, int len, AVPacket *pkt)
+{
+av_init_packet(pkt);
+pkt->data = buffer;
+pkt->size = len;
+}
+
 static int new_pes_packet(PESContext *pes, AVPacket *pkt)
 {
 char *sd;
@@ -1975,6 +1994,19 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 pes->st->id = pes->pid;
 }
 st = pes->st;
+} else if (stream_type == 0x86 && prog_reg_desc ==  AV_RL32("CUEI")) {
+int idx = ff_find_stream_index(ts->stream, pid);
+if (idx >= 0) {
+st = ts->stream->streams[idx];
+} else {
+st = avformat_new_stream(ts->stream, NULL);
+if (!st)
+goto out;
+st->id = pid;
+st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
+mpegts_find_stream_type(st, stream_type, SCTE_types);
+mpegts_open_data_filter(ts, pid);
+}
 } else if (stream_type != 0x13) {
 if (ts->pids[pid])
 mpegts_close_filter(ts, ts->pids[pid]); // wrongly added sdt 
filter probably
@@ -2317,15 +2349,20 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 }
 }
 }
-
-} else {
+} else if (tss->type == MPEGTS_DATA) {
+int idx = ff_find_stream_index(ts->stream, pid);
+p++;
+new_data_packet(p,p_end - p, ts->pkt);
+if (idx >= 0) {
+ts->pkt->stream_index = idx;
+}
+ts->stop_parse = 1;
+} else if (tss->type == MPEGTS_PES) {
 int ret;
 // Note: The position here points actually behind the current packet.
-if (tss->type == MPEGTS_PES) {
-if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
+if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
 pos - ts->raw_packet_size)) < 
0)
-return ret;
-}
+return ret;
 }
 
 return 0;
@@ -2730,6 +2767,8 @@ static int mpegts_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 ret = 0;
 break;
 }
+} else if (ts->pids[i] && ts->pids[i]->type == MPEGTS_DATA) {
+return ret;
 }
 }
 
-- 
2.7.4

___
ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH 0/2] v3 - SCTE 35 work

[Carlos Fernandez Sanz]

- Corrected last reported issue about a sample file missing audio after these
patches were applied.
- Created new streamtype with SCTE

Carlos (1):
  SCTE extraction from mpegts

carlos (1):
  SCTE-35 support in hlsenc

 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   6 +
 libavformat/Makefile|   2 +-
 libavformat/hlsenc.c| 110 ---
 libavformat/mpegts.c|  51 -
 libavformat/scte_35.c   | 482 
 libavformat/scte_35.h   |  76 
 7 files changed, 698 insertions(+), 30 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

-- 
2.7.4

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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Michael Niedermayer]

On Wed, Aug 03, 2016 at 03:55:08PM -0300, James Almer wrote:
> On 7/31/2016 5:01 PM, Michael Niedermayer wrote:
> > Hi all
> > 
> > you have a great idea for a Outreachy task or a GSoC task ?
> > Or something you always wanted to do but never had the time and
> > it would fit in the time for GSoC/Outreachy ?
> > Or some feature you always wanted which would fit as a task?
> > Also keep in mind Outreachy is more flexible and not limited to
> > coding tasks !
> > reply and dump it here below:
> 
> Writing new examples or porting decoding_encoding.c and
> demuxing_decoding.c to use codecpar and send/receive packet/frame.
> Writing documentation with steps to migrate applications using
> old APIs to new ones like the above, so we don't have to deal
> with tons of projects sticking to deprecated APIs two years from
> now and blocking or complicating their scheduled removal.
> 
> Maye also adding or extending doxy on public and private header,
> sort of like what Timothy did the last couple days, but as Paul
> said, coding related there's probably not a whole lot left that
> can be easily done by students.

what about writing guides/howtos about how to build/replace FFmpeg
on all kinds of hw

i mean everything these days uses FFmpeg below one or more layers
and users should have the right to replace their products FFmpeg
maybe with one that has more features enabled or a newer version
but in practice for how many products that contain FFmpeg can
the user actually do this easily? ...

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] [PATCH] Fix audio clipping problem in dynaudnorm

[andyndeanna]

This has been fixed by MuldeR.

Thanks,
Andy

On Fri, Jul 29, 2016 at 8:03 AM, Paul B Mahol  wrote:

> On 7/27/16, andyndeanna  wrote:
> > Hello,
> >
> > See attached patch to fix a clipping problem with dynaudnorm when the
> first
> > frame contains silence.  I implemented the fix by adding a boundary mode.
> > It could also be done by changing how b=1 works.
> >
> > Thanks,
> > Andy
> >
>
> Have you considered sending this directly to creator of this code?
> ___
> 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 3/3] avformat/img2enc: Use AV_FRAME_FILENAME_FLAGS_MULTIPLE, support tee:

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/img2enc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 32c68e4..1297b1a 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -97,7 +97,9 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 av_log(s, AV_LOG_ERROR, "Could not get frame filename with 
strftime\n");
 return AVERROR(EINVAL);
 }
-} else if (av_get_frame_filename(filename, sizeof(filename), 
img->path, img->img_number) < 0 &&
+} else if (av_get_frame_filename2(filename, sizeof(filename), 
img->path,
+  img->img_number,
+  AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 
0 &&
img->img_number > 1) {
 av_log(s, AV_LOG_ERROR,
"Could not get frame filename number %d from pattern '%s' 
(either set updatefirst or use a pattern like %%03d within the filename 
pattern)\n",
-- 
2.9.2

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

[FFmpeg-devel] [PATCH 2/3] avformat/hlsenc: Use AV_FRAME_FILENAME_FLAGS_MULTIPLE, support tee:

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/hlsenc.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5dc518d..9f076ba 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -561,14 +561,16 @@ static int hls_start(AVFormatContext *s)
 }
 av_free(fn_copy);
 }
-} else if (av_get_frame_filename(oc->filename, sizeof(oc->filename),
-  c->basename, c->wrap ? c->sequence % c->wrap 
: c->sequence) < 0) {
+} else if (av_get_frame_filename2(oc->filename, sizeof(oc->filename),
+  c->basename, c->wrap ? c->sequence % c->wrap 
: c->sequence,
+  AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0) {
 av_log(oc, AV_LOG_ERROR, "Invalid segment filename template '%s' 
you can try use -use_localtime 1 with it\n", c->basename);
 return AVERROR(EINVAL);
 }
 if( c->vtt_basename) {
-if (av_get_frame_filename(vtt_oc->filename, 
sizeof(vtt_oc->filename),
-  c->vtt_basename, c->wrap ? c->sequence % c->wrap 
: c->sequence) < 0) {
+if (av_get_frame_filename2(vtt_oc->filename, 
sizeof(vtt_oc->filename),
+  c->vtt_basename, c->wrap ? c->sequence % c->wrap 
: c->sequence,
+  AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0) {
 av_log(vtt_oc, AV_LOG_ERROR, "Invalid segment filename 
template '%s'\n", c->vtt_basename);
 return AVERROR(EINVAL);
 }
-- 
2.9.2

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

[FFmpeg-devel] [PATCH 1/3] avformat: Add av_get_frame_filename2() and AV_FRAME_FILENAME_FLAGS_MULTIPLE

[Michael Niedermayer]

This will be used to allow writing file sequences using the tee output onto
multiple places in parallel

Signed-off-by: Michael Niedermayer 
---
 libavformat/avformat.h | 7 +++
 libavformat/utils.c| 9 +++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index b9fbb06..d8a6cf3 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2720,6 +2720,9 @@ void av_dump_format(AVFormatContext *ic,
 const char *url,
 int is_output);
 
+
+#define AV_FRAME_FILENAME_FLAGS_MULTIPLE 1 ///< Allow multiple %d
+
 /**
  * Return in 'buf' the path with '%d' replaced by a number.
  *
@@ -2730,8 +2733,12 @@ void av_dump_format(AVFormatContext *ic,
  * @param buf_size destination buffer size
  * @param path numbered sequence string
  * @param number frame number
+ * @param flags AV_FRAME_FILENAME_FLAGS_*
  * @return 0 if OK, -1 on format error
  */
+int av_get_frame_filename2(char *buf, int buf_size,
+  const char *path, int number, int flags);
+
 int av_get_frame_filename(char *buf, int buf_size,
   const char *path, int number);
 
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 5a902ea..6b7609e 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4315,7 +4315,7 @@ uint64_t ff_ntp_time(void)
 return (av_gettime() / 1000) * 1000 + NTP_OFFSET_US;
 }
 
-int av_get_frame_filename(char *buf, int buf_size, const char *path, int 
number)
+int av_get_frame_filename2(char *buf, int buf_size, const char *path, int 
number, int flags)
 {
 const char *p;
 char *q, buf1[20], c;
@@ -4340,7 +4340,7 @@ int av_get_frame_filename(char *buf, int buf_size, const 
char *path, int number)
 case '%':
 goto addchar;
 case 'd':
-if (percentd_found)
+if (!(flags & AV_FRAME_FILENAME_FLAGS_MULTIPLE) && 
percentd_found)
 goto fail;
 percentd_found = 1;
 if (number < 0)
@@ -4370,6 +4370,11 @@ fail:
 return -1;
 }
 
+int av_get_frame_filename(char *buf, int buf_size, const char *path, int 
number)
+{
+return av_get_frame_filename2(buf, buf_size, path, number, 0);
+}
+
 void av_url_split(char *proto, int proto_size,
   char *authorization, int authorization_size,
   char *hostname, int hostname_size,
-- 
2.9.2

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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[James Almer]

On 7/31/2016 5:01 PM, Michael Niedermayer wrote:
> Hi all
> 
> you have a great idea for a Outreachy task or a GSoC task ?
> Or something you always wanted to do but never had the time and
> it would fit in the time for GSoC/Outreachy ?
> Or some feature you always wanted which would fit as a task?
> Also keep in mind Outreachy is more flexible and not limited to
> coding tasks !
> reply and dump it here below:

Writing new examples or porting decoding_encoding.c and
demuxing_decoding.c to use codecpar and send/receive packet/frame.
Writing documentation with steps to migrate applications using
old APIs to new ones like the above, so we don't have to deal
with tons of projects sticking to deprecated APIs two years from
now and blocking or complicating their scheduled removal.

Maye also adding or extending doxy on public and private header,
sort of like what Timothy did the last couple days, but as Paul
said, coding related there's probably not a whole lot left that
can be easily done by students.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Paul B Mahol]

On 8/3/16, Michael Niedermayer  wrote:
> Hi all
>
> Sun, Jul 31, 2016 at 10:01:00PM +0200, Michael Niedermayer wrote:
>> Hi all
>>
>> you have a great idea for a Outreachy task or a GSoC task ?
>> Or something you always wanted to do but never had the time and
>> it would fit in the time for GSoC/Outreachy ?
>> Or some feature you always wanted which would fit as a task?
>> Also keep in mind Outreachy is more flexible and not limited to
>> coding tasks !
>> reply and dump it here below:
>
> ping ?
>
> also cc-ing ffmpeg-user
>
> or are all feature requests on trac fake and noone has anything they
> think should be implemented ?
>
> we need ideas for Outreachy, the page is EMPTY:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12

Hard stuff only left.

>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add interlaced_frame and format struct to AVFrame for deinterlacing]

[Jens Ziller]

Am Sonntag, den 31.07.2016, 18:36 +0100 schrieb Mark Thompson:
> On 31/07/16 18:09, Jens Ziller wrote:
> > 
> > Am Sonntag, den 31.07.2016, 16:33 +0100 schrieb Mark Thompson:
> > > 
> > > Try the test stream h264/reinit-large_420_8-to-small_420_8.h264
> > > in
> > > FATE?
> > I don't test it. I tested with MPEG2 and H264 DVB-S streams. Where
> > can
> > I find this test stream?
>  small_420_8.h264>

If wight/height change the application must close the decoder and start
again with new wight/height. There is no influence to my patch.

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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Michael Niedermayer]

Hi all

Sun, Jul 31, 2016 at 10:01:00PM +0200, Michael Niedermayer wrote:
> Hi all
> 
> you have a great idea for a Outreachy task or a GSoC task ?
> Or something you always wanted to do but never had the time and
> it would fit in the time for GSoC/Outreachy ?
> Or some feature you always wanted which would fit as a task?
> Also keep in mind Outreachy is more flexible and not limited to
> coding tasks !
> reply and dump it here below:

ping ?

also cc-ing ffmpeg-user

or are all feature requests on trac fake and noone has anything they
think should be implemented ?

we need ideas for Outreachy, the page is EMPTY:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/teeproto: Support parsing protocol options

[Michael Niedermayer]

On Mon, Aug 01, 2016 at 02:51:57AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/Makefile   |2 +-
>  libavformat/teeproto.c |   19 ++-
>  2 files changed, 15 insertions(+), 6 deletions(-)

applied

[...]
-- 
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] Avoid sending packets to network when multicast ttl is 0 in udp

[Michael Niedermayer]

On Wed, Aug 03, 2016 at 12:29:17PM +0430, Omid Ghaffarinia wrote:
> Does it still fail?

no failure

i would prefer if the code move would be in a seperate
patch though. Its harder to review for developers as is

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH]lavf(webm_chunk: Print an error if no header filename was provided.

[Carl Eugen Hoyos]

Hi!

Attached patch gives users (and testers) a chance to know why webm_chunk 
muxing fails.

Please comment, Carl Eugen
From 675562a4d2215af36f512d3d2c608ec8dc16a73c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 3 Aug 2016 18:40:03 +0200
Subject: [PATCH] lavf/webm_chunk: Print an error if no header filename was
 provided.

---
 libavformat/webm_chunk.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
index 9db4fab..e75f929 100644
--- a/libavformat/webm_chunk.c
+++ b/libavformat/webm_chunk.c
@@ -92,6 +92,7 @@ static int get_chunk_filename(AVFormatContext *s, int 
is_header, char *filename)
 }
 if (is_header) {
 if (!wc->header_filename) {
+av_log(oc, AV_LOG_ERROR, "No header filename provided\n");
 return AVERROR(EINVAL);
 }
 av_strlcpy(filename, wc->header_filename, strlen(wc->header_filename) 
+ 1);
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH] avfilter: add sadrc filter

[Paul B Mahol]

Hi,

patch attached.


0001-avfilter-add-simple-audio-dynamic-range-compressor.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 10/11] avformat/fifo: Add AVFMT_FLAG_NONBLOCK support

[Michael Niedermayer]

On Wed, Aug 03, 2016 at 03:41:14PM +0200, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> > From: Jan Sebechlebsky 
[...]
> > +ret = pthread_tryjoin_np( fifo->writer_thread, NULL);
> 
> This function is a GNU extension (np means nonportable), this is the reason
> for the build failure reported by Michael; I am rather surprised you did not
> get it too since the build options should hide nonportable functions.

drifting a little off topic but

without knowing, the reason why it passed for jan and
likely also for me on x86_64 is i have more stuff instelled and
enabled for x86_64 build than 32bit
And some of the pkgconfig files add very inappropriate flags like
GNU_SOURCE IIRC
Maybe we should actually try to filter that out ...

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- 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] web/security: Add links to GPG keys, for people who want to send encrypted mail

[Michael Niedermayer]

On Wed, Aug 03, 2016 at 03:02:38PM +0200, Carl Eugen Hoyos wrote:
> 2016-08-03 14:58 GMT+02:00 Moritz Barsnick :
> > On Wed, Aug 03, 2016 at 14:17:21 +0200, Michael Niedermayer wrote:
> >> +If you wish to use PGP/GnuPG you can use.
> >
> > This sounds slightly strange.
> > ->
> > "If you wish to use PGP/GnuPG please do so."
> >
> > (Is this preferred by the list? Then that should be expressed.)
> 
> It is about emails sent to ffmpeg-security.if the reporter needs it.

yep and i dont think everyone on security@ has a gpg key fingerprint
in MAINTAINERs so using gpg has ATM a disadvantage of limiting
recipients

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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 10/11] avformat/fifo: Add AVFMT_FLAG_NONBLOCK support

[Nicolas George]

Le sextidi 16 thermidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> From: Jan Sebechlebsky 
> 
> Add support for nonblocking calls.
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  libavformat/fifo.c | 70 
> +-
>  1 file changed, 59 insertions(+), 11 deletions(-)
> 
> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> index bc8c973..efd91e3 100644
> --- a/libavformat/fifo.c
> +++ b/libavformat/fifo.c
> @@ -25,6 +25,7 @@
>  #include "avformat.h"
>  #include "internal.h"
>  #include "pthread.h"
> +#include "url.h"
>  
>  #define FIFO_DEFAULT_QUEUE_SIZE  60
>  #define FIFO_DEFAULT_MAX_RECOVERY_ATTEMPTS   16
> @@ -77,6 +78,13 @@ typedef struct FifoContext {
>   * from failure or queue overflow */
>  uint8_t restart_with_keyframe;
>  
> +/* Whether termination was requested by invoking deinit
> + * before the thread was finished. Used only in non-blocking
> + * mode - when AVFMT_FLAG_NONBLOCK is set. */
> +volatile uint8_t termination_requested;
> +
> +/* Original interrupt callback of the underlying muxer. */
> +AVIOInterruptCB orig_interrupt_callback;
>  } FifoContext;
>  
>  typedef struct FifoThreadContext {
> @@ -110,6 +118,16 @@ typedef struct FifoMessage {
>  AVPacket pkt;
>  } FifoMessage;
>  
> +static int fifo_interrupt_callback_wrapper(void *arg)
> +{
> +FifoContext *ctx = arg;
> +

> +if (ctx->termination_requested)
> +return 1;

This is a common misconception: volatile is not enough for thread
communication. IIUC, volatile forces the compiler to issue actual store and
fetch operations to memory, but not a memory barrier. That means it can be
used for communication with a signal handler (provided the object is small
enough so that operations are atomic, cf. sig_atomic_t) or a hardware
device. But for inter-thread communication on SMP systems, the lack of
memory barrier means that the change may be limited to the processor's cache
and only reach the central shared memory and the other core's cache at some
indeterminate point later.

For inter-thread communication, you either need a mutex or a special atomic
and synchronized operation. The second solution is more efficient, but
currently less portable. You can have a look at libavutil/atomic.h, and also
at Anton's efforts to replace it with a more standard and modern API, it
happened just last week on the fork's mailing-list.

> +
> +return ff_check_interrupt(>orig_interrupt_callback);

I am not sure if this part is worth your efforts: if the application wants
to cancel a write, it uses the FIFO muxer APIs, it does not need to set up
an interrupt callback. Do you see a case where it would be useful?

> +}
> +
>  static int fifo_thread_write_header(FifoThreadContext *ctx)
>  {
>  AVFormatContext *avf = ctx->avf;
> @@ -448,6 +466,8 @@ static void *fifo_consumer_thread(void *data)
>  static int fifo_mux_init(AVFormatContext *avf)
>  {
>  FifoContext *fifo = avf->priv_data;
> +AVIOInterruptCB interrupt_cb = {.callback = 
> fifo_interrupt_callback_wrapper,
> +.opaque = fifo};
>  AVFormatContext *avf2;
>  int ret = 0, i;
>  
> @@ -458,7 +478,8 @@ static int fifo_mux_init(AVFormatContext *avf)
>  
>  fifo->avf = avf2;
>  
> -avf2->interrupt_callback = avf->interrupt_callback;
> +fifo->orig_interrupt_callback = avf->interrupt_callback;
> +avf2->interrupt_callback = interrupt_cb;
>  avf2->max_delay = avf->max_delay;
>  ret = av_dict_copy(>metadata, avf->metadata, 0);
>  if (ret < 0)
> @@ -543,7 +564,7 @@ static int fifo_write_packet(AVFormatContext *avf, 
> AVPacket *pkt)
>  {
>  FifoContext *fifo = avf->priv_data;
>  FifoMessage msg = {.type = pkt ? FIFO_WRITE_PACKET : FIFO_FLUSH_OUTPUT};
> -int ret;
> +int ret, queue_flags = 0;
>  
>  if (pkt) {
>  av_init_packet();
> @@ -552,15 +573,21 @@ static int fifo_write_packet(AVFormatContext *avf, 
> AVPacket *pkt)
>  return ret;
>  }
>  
> -ret = av_thread_message_queue_send(fifo->queue, ,
> -   fifo->drop_pkts_on_overflow ?
> -   AV_THREAD_MESSAGE_NONBLOCK : 0);
> +if (fifo->drop_pkts_on_overflow || (avf->flags & AVFMT_FLAG_NONBLOCK))
> +queue_flags |= AVFMT_FLAG_NONBLOCK;
> +
> +ret = av_thread_message_queue_send(fifo->queue, , queue_flags);
> +
>  if (ret == AVERROR(EAGAIN)) {
> -uint8_t overflow_set = 0;
> +uint8_t overflow_set;
> +
> +if (avf->flags & AVFMT_FLAG_NONBLOCK)
> +return ret;
>  
>  /* Queue is full, set fifo->overflow_flag to 1
>   * to let consumer thread know the queue should
>   * be flushed. */
> +overflow_set = 0;
>  pthread_mutex_lock(>overflow_flag_lock);
>  if (!fifo->overflow_flag)
>  

Re: [FFmpeg-devel] [PATCH 06/11] avformat: add av_abort_output() function

[Nicolas George]

Le sextidi 16 thermidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> From: Jan Sebechlebsky 
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  libavformat/avformat.h | 14 ++
>  libavformat/mux.c  | 16 
>  2 files changed, 30 insertions(+)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 9191c69..9173908 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -2510,6 +2510,8 @@ int av_write_uncoded_frame_query(AVFormatContext *s, 
> int stream_index);
>   *
>   * If AVFMT_FLAG_NONBLOCK is set, this call may return AVERROR(EAGAIN)
>   * meaning the operation is pending and the call should be repeated.
> + * If caller decides to abort operation (after too many calls have returned
> + * AVERROR(EAGAIN)), it can be done by calling @ref av_abort_output().
>   *
>   * @param s media file handle
>   * @return 0 if OK, AVERROR(EAGAIN) in case call should be repeated,
> @@ -2518,6 +2520,18 @@ int av_write_uncoded_frame_query(AVFormatContext *s, 
> int stream_index);
>  int av_write_trailer(AVFormatContext *s);
>  
>  /**
> + * Abort non-blocking muxer operation and free private data.
> + *
> + * May only be called after a successful call to avformat_write_header,
> + * and used only with muxer operating in non-blocking mode 
> (AVFMT_FLAG_NONBLOCK)
> + * must be set.
> + *
> + * @param s media file handle
> + * return >= 0 on success, negative AVERROR on error
> + */

> +int av_abort_output(AVFormatContext *s);

The other functions are called av_write_something() or
avformat_write_something(): maybe avformat_write_abort()?

Also, it could call avformat_free_context() and set s to NULL, unless there
is some use in reusing the context?

> +
> +/**
>   * Return the output format in the list of registered output formats
>   * which best matches the provided parameters, or return NULL if
>   * there is no match.
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index bc9c98f..888a9f1 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -1267,6 +1267,22 @@ fail:
>  return ret;
>  }
>  
> +int av_abort_output(AVFormatContext *s)
> +{
> +int ret;
> +

> +if (!(s->flags & AVFMT_FLAG_NONBLOCK))
> +return AVERROR(EINVAL);

Since the application should be able to know whether the muxer is in
blocking mode, it could be an assert.

But is it really necessary? Applications in blocking mode may want to exit
immediately too.

Anyway, any of these changes would allow to make the function void.

> +
> +ret = av_write_trailer(s);
> +if (ret == AVERROR(EAGAIN)) {

Is it useful? The application could try and write the trailer itself,
possibly allowing a little more time to finish. And only call
av_abort_output() when it really wants to stop now.

> +deinit_muxer(s);

There is a subtle pitfall here: if the muxer does not have a deinit function
and av_write_trailer() returned EAGAIN (or was not called like I suggest),
then the resources leak.

Fortunately, we currently do not have any muxer that both supports
non-blocking mode and has a potentially blocking write_trailer(). We can
decide that any future muxer that would must have a deinit() function. In
that case, we can get away with the following steps:

  1. If the muxer has a deinit() method, just call deinit_muxer().

  2. Else, sabotage the context's AVIO stream so that it returns an error
 for all operations and call av_write_trailer().

The "sabotage" part of 2 is not very robust, but I think it is fine enough
for our use case. In fact, I would not object if that detail was left as a
TODO comment.

> +ret = 0;
> +}
> +
> +return ret;
> +}
> +
>  int av_get_output_timestamp(struct AVFormatContext *s, int stream,
>  int64_t *dts, int64_t *wall)
>  {

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] web/security: Add links to GPG keys, for people who want to send encrypted mail

[Carl Eugen Hoyos]

2016-08-03 14:58 GMT+02:00 Moritz Barsnick :
> On Wed, Aug 03, 2016 at 14:17:21 +0200, Michael Niedermayer wrote:
>> +If you wish to use PGP/GnuPG you can use.
>
> This sounds slightly strange.
> ->
> "If you wish to use PGP/GnuPG please do so."
>
> (Is this preferred by the list? Then that should be expressed.)

It is about emails sent to ffmpeg-security.if the reporter needs it.

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

Re: [FFmpeg-devel] [PATCH] web/security: Add links to GPG keys, for people who want to send encrypted mail

[Moritz Barsnick]

On Wed, Aug 03, 2016 at 14:17:21 +0200, Michael Niedermayer wrote:
> +If you wish to use PGP/GnuPG you can use.

This sounds slightly strange.
->
"If you wish to use PGP/GnuPG please do so."

(Is this preferred by the list? Then that should be expressed.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] web/security: Add links to GPG keys, for people who want to send encrypted mail

[Michael Niedermayer]

---
 src/security | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/security b/src/security
index ae89f9b..20c4d5d 100644
--- a/src/security
+++ b/src/security
@@ -1,4 +1,11 @@
-Please report vulnerabilities to mailto:ffmpeg-secur...@ffmpeg.org;>ffmpeg-secur...@ffmpeg.org
+Please report vulnerabilities to mailto:ffmpeg-secur...@ffmpeg.org;>ffmpeg-secur...@ffmpeg.org.
+If you wish to use PGP/GnuPG you can use.
+https://pgp.mit.edu/pks/lookup?search=0x9FF2128B147EF6730BADF133611EC787040B0FAB=get;>key1,
+https://pgp.mit.edu/pks/lookup?search=0x52D03A82D445F194DB8B2B1687EE2CB8F4B8FCF9=get;>key2
 and
+https://pgp.mit.edu/pks/lookup?search=0xC61D16E59E2CD10C895838A40899A2B906D4D9C7=get;>key3.
+Please use all keys if you encrypt.
+PGP key fingerprints are also in the https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/MAINTAINERS;>MAINTAINERS
 file.
+
 
 FFmpeg 2.8
 
-- 
2.9.2

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

Re: [FFmpeg-devel] [PATCH] - libavdevices/decklink_*.cpp: formatting change to remove uneeded spaces in initializers

[Felt, Patrick]

Sadly the server I’m deving on doesn’t have availability through an mta.  I 
generated the email by using [devuser@tst009 ~]$ git format-patch HEAD^ 
--stdout > /tmp/cosmetic2.txtand then manually creating a new email of 
similar format in my mua.  I had to attach the diff on that last cosmetic fix I 
did so I tried that here.  Is there some step I missed to where I can use this 
method?  If not, I can try running git off my laptop and then copy the diff and 
apply locally then commit off my laptop instead.



From: ffmpeg-devel  on behalf of Timothy Gu 

Reply-To: FFmpeg development discussions and patches 
Date: Tuesday, August 2, 2016 at 11:49 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH] - libavdevices/decklink_*.cpp: formatting 
change to remove uneeded spaces in initializers

On Tue, Aug 2, 2016 at 10:17 PM Felt, Patrick 
>
wrote:

---
libavdevice/decklink_common.cpp | 10 +-
libavdevice/decklink_dec.cpp| 18 +-
libavdevice/decklink_enc.cpp| 26 +-
3 files changed, 27 insertions(+), 27 deletions(-)


Pushed. If you could use git send-email to send patches, or at least send a
git formatted patch with a commit message and an author, that would be the
best.

Thanks,

Timothy
___
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] Avoid sending packets to network when multicast ttl is 0 in udp

[Omid Ghaffarinia]

Does it still fail?

Thanks in advance.

On Sat, Jul 23, 2016 at 10:36 AM, Omid Ghaffarinia
 wrote:
> I'm sorry for that, it failed because it was prepared for release/2.8,
> this one should work on master.
>
>
> On Thu, Jul 21, 2016 at 3:48 AM, Michael Niedermayer
>  wrote:
>> On Wed, Jul 20, 2016 at 05:38:10PM +0430, Omid Ghaffarinia wrote:
>>> Thanks for testing in mingw
>>> New patch attached, which should work now.
>>
>> still fails, even on ubuntu:
>> libavformat/udp.c: In function ‘udp_set_multicast_ttl’:
>> libavformat/udp.c:367:13: warning: passing argument 1 of ‘udp_set_url’ from 
>> incompatible pointer type [enabled by default]
>> libavformat/udp.c:328:12: note: expected ‘struct URLContext *’ but argument 
>> is of type ‘struct sockaddr_storage *’
>> libavformat/udp.c:367:13: warning: passing argument 2 of ‘udp_set_url’ from 
>> incompatible pointer type [enabled by default]
>> libavformat/udp.c:328:12: note: expected ‘struct sockaddr_storage *’ but 
>> argument is of type ‘const char *’
>> libavformat/udp.c:367:13: error: too few arguments to function ‘udp_set_url’
>> libavformat/udp.c:328:12: note: declared here
>> libavformat/udp.c:376:13: warning: passing argument 1 of ‘udp_set_url’ from 
>> incompatible pointer type [enabled by default]
>> libavformat/udp.c:328:12: note: expected ‘struct URLContext *’ but argument 
>> is of type ‘struct sockaddr_storage *’
>> libavformat/udp.c:376:13: warning: passing argument 2 of ‘udp_set_url’ from 
>> incompatible pointer type [enabled by default]
>> libavformat/udp.c:328:12: note: expected ‘struct sockaddr_storage *’ but 
>> argument is of type ‘const char *’
>> libavformat/udp.c:376:13: error: too few arguments to function ‘udp_set_url’
>> libavformat/udp.c:328:12: note: declared here
>> libavformat/udp.c: In function ‘udp_open’:
>> libavformat/udp.c:907:17: warning: passing argument 1 of ‘udp_set_url’ from 
>> incompatible pointer type [enabled by default]
>> libavformat/udp.c:328:12: note: expected ‘struct URLContext *’ but argument 
>> is of type ‘struct sockaddr_storage *’
>> libavformat/udp.c:907:17: warning: passing argument 2 of ‘udp_set_url’ from 
>> incompatible pointer type [enabled by default]
>> libavformat/udp.c:328:12: note: expected ‘struct sockaddr_storage *’ but 
>> argument is of type ‘const char *’
>> libavformat/udp.c:907:17: error: too few arguments to function ‘udp_set_url’
>> libavformat/udp.c:328:12: note: declared here
>>
>>
>> on mingw64:
>> CC  libavformat/udp.o
>> src/libavformat/udp.c: In function ‘udp_set_multicast_ttl’:
>> src/libavformat/udp.c:367:13: warning: passing argument 1 of ‘udp_set_url’ 
>> from incompatible pointer type [enabled by default]
>> src/libavformat/udp.c:328:12: note: expected ‘struct URLContext *’ but 
>> argument is of type ‘struct sockaddr_storage *’
>> src/libavformat/udp.c:367:13: warning: passing argument 2 of ‘udp_set_url’ 
>> from incompatible pointer type [enabled by default]
>> src/libavformat/udp.c:328:12: note: expected ‘struct sockaddr_storage *’ but 
>> argument is of type ‘const char *’
>> src/libavformat/udp.c:367:13: error: too few arguments to function 
>> ‘udp_set_url’
>> src/libavformat/udp.c:328:12: note: declared here
>> src/libavformat/udp.c:376:13: warning: passing argument 1 of ‘udp_set_url’ 
>> from incompatible pointer type [enabled by default]
>> src/libavformat/udp.c:328:12: note: expected ‘struct URLContext *’ but 
>> argument is of type ‘struct sockaddr_storage *’
>> src/libavformat/udp.c:376:13: warning: passing argument 2 of ‘udp_set_url’ 
>> from incompatible pointer type [enabled by default]
>> src/libavformat/udp.c:328:12: note: expected ‘struct sockaddr_storage *’ but 
>> argument is of type ‘const char *’
>> src/libavformat/udp.c:376:13: error: too few arguments to function 
>> ‘udp_set_url’
>> src/libavformat/udp.c:328:12: note: declared here
>> src/libavformat/udp.c: In function ‘udp_open’:
>> src/libavformat/udp.c:907:17: warning: passing argument 1 of ‘udp_set_url’ 
>> from incompatible pointer type [enabled by default]
>> src/libavformat/udp.c:328:12: note: expected ‘struct URLContext *’ but 
>> argument is of type ‘struct sockaddr_storage *’
>> src/libavformat/udp.c:907:17: warning: passing argument 2 of ‘udp_set_url’ 
>> from incompatible pointer type [enabled by default]
>> src/libavformat/udp.c:328:12: note: expected ‘struct sockaddr_storage *’ but 
>> argument is of type ‘const char *’
>> src/libavformat/udp.c:907:17: error: too few arguments to function 
>> ‘udp_set_url’
>> src/libavformat/udp.c:328:12: note: declared here
>> make: *** [libavformat/udp.o] Error 1
>> make: Target `all' not remade because of errors.
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> When the tyrant has disposed of foreign enemies by conquest or treaty, and
>> there is nothing more to fear from them, then he is always stirring up
>> some war or other, in order that 

[FFmpeg-devel] fate: add DNxHR 12-bit example.

[Steven Robertson]

Test file available at http://tinyurl.com/fate-dnxhd-12bit .

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

[FFmpeg-devel] [PATCH] fate: add DNxHR 12-bit example.

[Steven Robertson]

Test file available at http://tinyurl.com/fate-dnxhd-12bit .

Signed-off-by: Steven Robertson 
---
 tests/fate/dnxhd.mak   | 2 ++
 tests/ref/fate/dnxhr-12bit | 6 ++
 2 files changed, 8 insertions(+)
 create mode 100644 tests/ref/fate/dnxhr-12bit

diff --git a/tests/fate/dnxhd.mak b/tests/fate/dnxhd.mak
index 4008e6c..672290f 100644
--- a/tests/fate/dnxhd.mak
+++ b/tests/fate/dnxhd.mak
@@ -1,5 +1,6 @@
 FATE_DNXHD = fate-dnxhd-mbaff \
  fate-dnxhr-444   \
+ fate-dnxhr-12bit \
  fate-dnxhr-parse \
  fate-dnxhr-prefix1   \
  fate-dnxhr-prefix2   \
@@ -12,6 +13,7 @@ fate-dnxhd: $(FATE_DNXHD) $(FATE_VCODEC_DNXHD)
 
 fate-dnxhd-mbaff: CMD = framecrc -flags +bitexact -idct simple -i 
$(TARGET_SAMPLES)/dnxhd/dnxhd100_cid1260.mov -pix_fmt yuv422p10le
 fate-dnxhr-444:   CMD = framecrc -flags +bitexact -idct simple -i 
$(TARGET_SAMPLES)/dnxhd/dnxhr444_cid1270.mov -pix_fmt yuv444p10le
+fate-dnxhr-12bit: CMD = framecrc -flags +bitexact -idct simple -i 
$(TARGET_SAMPLES)/dnxhd/dnxhr_cid1271_12bit.mov -pix_fmt yuv444p12le
 fate-dnxhr-parse: CMD = framecrc -flags +bitexact -idct simple -i 
$(TARGET_SAMPLES)/dnxhd/dnxhr_cid1274.dnxhr -pix_fmt yuv422p
 fate-dnxhr-prefix1: CMD = framecrc -flags +bitexact -idct simple -i 
$(TARGET_SAMPLES)/dnxhd/prefix-256x1536.dnxhr -pix_fmt yuv422p
 fate-dnxhr-prefix2: CMD = framecrc -flags +bitexact -idct simple -i 
$(TARGET_SAMPLES)/dnxhd/prefix-256x1716.dnxhr -pix_fmt yuv422p
diff --git a/tests/ref/fate/dnxhr-12bit b/tests/ref/fate/dnxhr-12bit
new file mode 100644
index 000..11bcb9a
--- /dev/null
+++ b/tests/ref/fate/dnxhr-12bit
@@ -0,0 +1,6 @@
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1920x1080
+#sar 0: 1/1
+0,  0,  0,1, 12441600, 0xe3585eed
-- 
2.8.0.rc2

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