Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 10:14, Chao Liu wrote:
> > On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> >>> On 15 Aug, Hendrik Leppkes wrote :
> > On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
> >> wrote:
> >>> add libyami decoder/encoder/vpp in ffmpeg, about build step,
> >>> please refer to the link: https://github.com/01org/
> >> ffmpeg_libyami/wiki/Build
> >>>
> >
> > We've had patches for yami before, and they were not applied because
> > many developers did not agree with adding more wrappers for the same
> > hardware decoders which we already support.
> > Please refer to the discussion in this thread:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >
> > The concerns and reasons brought up there should not really have
> >> changed.
> >>> I still object very strongly against yami.
> >>>
> >>> It is a library that does not bring much that we could not do
> ourselves,
> >>> it duplicates a lot of our code, it is the wrong level of abstraction
> >>> for libavcodec, it is using a bad license and there is no guarantee of
> >>> maintainership in the future.
> >>
> >> I know the worry after read the above thread.For Intel GPU HW accelerate
> >> decode/encode,
> >> now have 3 options in ffmpeg:
> >>
> >> 1. ffmpeg and QSV (Media SDK)
> >> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> >> 3. ffmpeg and libyami
> >>
> > Sorry for this little diversion: what are the differences between QSV and
> > vaapi?
> > My understanding is that QSV has better performance, while vaapi supports
> > more decoders / encoders. Is that correct?
> > It would be nice if there are some data showing the speed of these HW
> > accelerated decoders / encoders.
>
> QSV has better performance is right, but libyami have more
> decoders/encoders than
> vaapi hw accel decoder/encoder. :)
>
> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
> native
> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> vaapi encoder
>
> >
> >>
> >> And I know the guys prefer option 2 than 3, but I have a little
> question,
> >> what's the
> >> difference about ffmpeg/libyami and the other external codec library(e,g
> >> openh264,
> >> videotoolbox...)?
> >>
> > Is 2 available in ffmpeg today or is it sth. planned?
> >
>
> Option 2 is available today :), I think the wiki page (
> https://wiki.libav.org/Hardware/vaapi)
> is good refer to for option 2, if you want to try. :)

Thanks. But that's for libav. These decoders and encoders are not available
for ffmpeg.

>


> >>
> >> As I know Intel have 3 full time Libyami developers, so no guarantee
> maybe
> >> is wrong.:)
> >>
> >> Tks.
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao  wrote:

>
>
> On 2016/8/16 11:07, Timothy Gu wrote:
> > Hi
> >
> > On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 10:14, Chao Liu wrote:
> >>> Sorry for this little diversion: what are the differences between QSV
> and
> >>> vaapi?
> >>> My understanding is that QSV has better performance, while vaapi
> supports
> >>> more decoders / encoders. Is that correct?
> >>> It would be nice if there are some data showing the speed of these HW
> >>> accelerated decoders / encoders.
> >>
> >> QSV has better performance is right, but libyami have more
> >> decoders/encoders than
> >> vaapi hw accel decoder/encoder. :)
> >>
> >
> > I am not sure where you got this information.
> >
> > On Intel platforms they all use the same chip. Because VAAPI supports
> more
> > than just Intel platforms, VAAPI supports all codecs libyami and QSV
> > support, if not more.
> >
> > QSV works on both Windows and Linux, although it is a pain to set up a
> > Linux QSV environment (you have to have the right distro, right kernel,
> > etc.).
> >
> >
>
> I means ffmpeg_VAAPI hw accel decoder/native VAAPI encoder, not the VAAPI
> as
> interface.
>
> >>
> >> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and
> >> native
> >> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> >> native
> >> vaapi encoder
> >>
> >
> > You didn't mention _how_ you profiled things, and for HW encoding
> different
> > ways of profiling can cause wildly different results. If for example you
> > are not doing zero-copy VAAPI operations, you are inherently giving the
> > other two methods an edge.
> >
>
> I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode
> transcode with default setting as profile case.
>
Perhaps you could share your test environment settings and the results, so
others could repro and confirm what you said, which could make this patch
more appealing.
IIUC, there is no hardware accelerated encoder for VP8 in ffmpeg yet.
That's another value of this patch..

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

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

[Paul B Mahol]

On 8/14/16, Paul B Mahol  wrote:
> Hi,
>
> patch attached.
>

Updated patch attached.


0001-avfilter-add-bitplanenoise-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Jun Zhao]

On 2016/8/16 15:37, Chao Liu wrote:
> On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:
> 
>>
>>
>> On 2016/8/16 10:14, Chao Liu wrote:
>>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
>>>


 On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> On 15 Aug, Hendrik Leppkes wrote :
>>> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
 wrote:
> add libyami decoder/encoder/vpp in ffmpeg, about build step,
> please refer to the link: https://github.com/01org/
 ffmpeg_libyami/wiki/Build
>
>>>
>>> We've had patches for yami before, and they were not applied because
>>> many developers did not agree with adding more wrappers for the same
>>> hardware decoders which we already support.
>>> Please refer to the discussion in this thread:
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>>>
>>> The concerns and reasons brought up there should not really have
 changed.
> I still object very strongly against yami.
>
> It is a library that does not bring much that we could not do
>> ourselves,
> it duplicates a lot of our code, it is the wrong level of abstraction
> for libavcodec, it is using a bad license and there is no guarantee of
> maintainership in the future.

 I know the worry after read the above thread.For Intel GPU HW accelerate
 decode/encode,
 now have 3 options in ffmpeg:

 1. ffmpeg and QSV (Media SDK)
 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
 3. ffmpeg and libyami

>>> Sorry for this little diversion: what are the differences between QSV and
>>> vaapi?
>>> My understanding is that QSV has better performance, while vaapi supports
>>> more decoders / encoders. Is that correct?
>>> It would be nice if there are some data showing the speed of these HW
>>> accelerated decoders / encoders.
>>
>> QSV has better performance is right, but libyami have more
>> decoders/encoders than
>> vaapi hw accel decoder/encoder. :)
>>
>> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and
>> native
>> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
>> native
>> vaapi encoder
>>
>>>

 And I know the guys prefer option 2 than 3, but I have a little
>> question,
 what's the
 difference about ffmpeg/libyami and the other external codec library(e,g
 openh264,
 videotoolbox...)?

>>> Is 2 available in ffmpeg today or is it sth. planned?
>>>
>>
>> Option 2 is available today :), I think the wiki page (
>> https://wiki.libav.org/Hardware/vaapi)
>> is good refer to for option 2, if you want to try. :)
> 
> Thanks. But that's for libav. These decoders and encoders are not available
> for ffmpeg.
> 

I can run ffmpeg vaapi hw accel decoder and vaapi encoder with zero-copy mode 
for
transcode case, I don't know why you can't succeed.

Do you re-build intel-driver/libva with master branch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Jun Zhao]

On 2016/8/16 15:40, Chao Liu wrote:
> On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao  wrote:
> 
>>
>>
>> On 2016/8/16 11:07, Timothy Gu wrote:
>>> Hi
>>>
>>> On Mon, Aug 15, 2016 at 7:44 PM Jun Zhao  wrote:
>>>


 On 2016/8/16 10:14, Chao Liu wrote:
> Sorry for this little diversion: what are the differences between QSV
>> and
> vaapi?
> My understanding is that QSV has better performance, while vaapi
>> supports
> more decoders / encoders. Is that correct?
> It would be nice if there are some data showing the speed of these HW
> accelerated decoders / encoders.

 QSV has better performance is right, but libyami have more
 decoders/encoders than
 vaapi hw accel decoder/encoder. :)

>>>
>>> I am not sure where you got this information.
>>>
>>> On Intel platforms they all use the same chip. Because VAAPI supports
>> more
>>> than just Intel platforms, VAAPI supports all codecs libyami and QSV
>>> support, if not more.
>>>
>>> QSV works on both Windows and Linux, although it is a pain to set up a
>>> Linux QSV environment (you have to have the right distro, right kernel,
>>> etc.).
>>>
>>>
>>
>> I means ffmpeg_VAAPI hw accel decoder/native VAAPI encoder, not the VAAPI
>> as
>> interface.
>>

 According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
>> and
 native
 vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
 native
 vaapi encoder

>>>
>>> You didn't mention _how_ you profiled things, and for HW encoding
>> different
>>> ways of profiling can cause wildly different results. If for example you
>>> are not doing zero-copy VAAPI operations, you are inherently giving the
>>> other two methods an edge.
>>>
>>
>> I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode
>> transcode with default setting as profile case.
>>
> Perhaps you could share your test environment settings and the results, so
> others could repro and confirm what you said, which could make this patch
> more appealing.
> IIUC, there is no hardware accelerated encoder for VP8 in ffmpeg yet.
> That's another value of this patch..
> 

Yes, you are right, now ffmpeg missing VP8 hardware accelerated encoder/decoder.

If you want to reproduce the performance results, I think you can used the 
codebase
https://github.com/01org/ffmpeg_libyami branch rebase-upstream, when build the 
source code, pls --enable-vaapi. :)

Then you can try the transcode case with yami decoder/encoder, vaapi hardware 
accelerated encoder/decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop issue

[Ivan Uskov]

Hello Jun,

Thursday, August 11, 2016, 10:59:51 AM, you wrote:

> From cafa70e97ce48b65e2a4a99782f6ce3557fef755 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 11 Aug 2016 15:34:01 +0800
> Subject: [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop
>  issue.

> the merge commit 1b04ea1 "avconv: create simple filtergraphs earlier"
> will init the filtergraphs earlier, then init the QSV transcode can't
> suppose the nb_filters's value, else lead to the QSV transcode performance
> drop.

> Signed-off-by: Jun Zhao 
> ---
>  ffmpeg_qsv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

> diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
> index 95a2351..acc54dd 100644
> --- a/ffmpeg_qsv.c
> +++ b/ffmpeg_qsv.c
> @@ -210,8 +210,7 @@ int qsv_transcode_init(OutputStream *ost)
>  
>  /* check if the decoder supports QSV and the output only goes to this 
> stream */
>  ist = input_streams[ost->source_index];
-if (ist->nb_filters || ist->hwaccel_id != HWACCEL_QSV ||
-!ist->dec || !ist->dec->pix_fmts)
+if (ist->hwaccel_id != HWACCEL_QSV || !ist->dec || !ist->dec->pix_fmts)
>  return 0;
>  for (pix_fmt = ist->dec->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE; 
> pix_fmt++)
>  if (*pix_fmt == AV_PIX_FMT_QSV)
Thank, makes sense.
LGTM.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Jun Zhao]

On 2016/8/16 15:40, Chao Liu wrote:
> On Mon, Aug 15, 2016 at 10:22 PM, Jun Zhao  wrote:
> 
cult...
>>
>> I used the ffmpeg_QSV/ffmpeg_libyami/ffmpeg_vaapi to do zero-copy mode
>> transcode with default setting as profile case.
>>
> Perhaps you could share your test environment settings and the results, so
> others could repro and confirm what you said, which could make this patch
> more appealing.
> IIUC, there is no hardware accelerated encoder for VP8 in ffmpeg yet.
> That's another value of this patch..

some log you can refer to, and now I can't find QSV test bed :(

barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -vaapi_device 
/dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i 
../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 
'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 77 -level:v 40  -b 4000k  
output_vaapi_transcode.mp4
ffmpeg version N-81825-g80f8fc9 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.9.2 (Debian 4.9.2-10)
  configuration: --prefix=/opt/ffmpeg --enable-libyami --disable-doc 
--enable-version3 --enable-vaapi
  libavutil  55. 28.100 / 55. 28.100
  libavcodec 57. 51.102 / 57. 51.102
  libavformat57. 46.101 / 57. 46.101
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 51.100 /  6. 51.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /opt/yami/vaapi/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'../ffmpeg_yami_testcase/skyfall2-trailer.mp4':
  Metadata:
major_brand : mp42
minor_version   : 0
compatible_brands: isom
creation_time   : 2012-07-31 00:31:48
  Duration: 00:02:30.77, start: 0.00, bitrate: 4002 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 
1920x1080 [SAR 1:1 DAR 16:9], 3937 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 
tbc (default)
Metadata:
  creation_time   : 2012-07-31 00:31:48
  handler_name: MP4 Video Media Handler
  encoder : AVC Coding
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 
fltp, 61 kb/s (default)
Metadata:
  creation_time   : 2012-07-31 00:31:48
  handler_name: MP4 Sound Media Handler
Please use -profile:a or -profile:v, -profile is ambiguous
Please use -b:a or -b:v, -b is ambiguous
[mp4 @ 0x36bedc0] Using AVStream.codec to pass codec parameters to muxers is 
deprecated, use AVStream.codecpar instead.
Output #0, mp4, to 'output_vaapi_transcode.mp4':
  Metadata:
major_brand : mp42
minor_version   : 0
compatible_brands: isom
encoder : Lavf57.46.101
Stream #0:0(eng): Video: h264 (h264_vaapi) (Main) ([33][0][0][0] / 0x0021), 
vaapi_vld, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 4000 kb/s, 23.98 fps, 24k tbn, 
23.98 tbc (default)
Metadata:
  creation_time   : 2012-07-31 00:31:48
  handler_name: MP4 Video Media Handler
  encoder : Lavc57.51.102 h264_vaapi
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
[h264 @ 0x382ba40] Hardware accelerated decoding with frame threading is known 
to be unstable and its use is discouraged.
Input stream #0:0 frame changed from size:1920x1080 fmt:yuv420p to 
size:1920x1080 fmt:vaapi_vld
Unrepairable overflow!-0.0 size= 797kB time=00:00:01.79 
bitrate=3639.5kbits/s dup=1 drop=0 speed=3.54x
frame= 3615 fps=132 q=-0.0 Lsize=   71470kB time=00:02:30.69 
bitrate=3885.3kbits/s dup=1 drop=0 speed=5.49x
video:71435kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.048997%
barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
output_vaapi_transcode.mp4 
General
Complete name: output_vaapi_transcode.mp4
Format   : MPEG-4
Format profile   : Base Media
Codec ID : isom
File size: 69.8 MiB
Duration : 2mn 30s
Overall bit rate mode: Variable
Overall bit rate : 3 883 Kbps
Writing application  : Lavf57.46.101

Video
ID   : 1
Format   : AVC
Format/Info  : Advanced Video Codec
Format profile   : Main@L4.0
Format settings, CABAC   : Yes
Format settings, ReFrames: 2 frames
Codec ID : avc1
Codec ID/Info: Advanced Video Coding
Duration : 2mn 30s
Bit rate mode: Variable
Bit rate : 3 881 Kbps
Maximum bit rate  

Re: [FFmpeg-devel] [PATCH] avfilter/vf_geq: add interpolation option

[Michael Niedermayer]

On Tue, Aug 16, 2016 at 08:54:16AM +0200, Paul B Mahol wrote:
> On 8/16/16, Michael Niedermayer  wrote:
> > On Mon, Aug 15, 2016 at 08:15:10PM +0200, Paul B Mahol wrote:
> >> Hi,
> >>
> >> patch attached.
> >
> > this mail has no attachments
> >
> 
> Sorry.

>  doc/filters.texi |3 +++
>  libavfilter/vf_geq.c |   32 +++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 650a493e529b204f714d9dcd3cd0a4e61a083048  
> 0001-avfilter-vf_geq-add-interpolation-option.patch
> From 7460f0fd0829b5bf550fb0283d6d9f8a21e7467a Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Mon, 15 Aug 2016 19:54:29 +0200
> Subject: [PATCH] avfilter/vf_geq: add interpolation option
> 
> ---
>  doc/filters.texi |  3 +++
>  libavfilter/vf_geq.c | 32 +++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index c595fed..475a929 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -8221,6 +8221,9 @@ Set the red expression.
>  Set the green expression.
>  @item blue_expr, b
>  Set the blue expression.
> +@item interpolation, i
> +Set pixel interpolation. Can be @code{nearest} or @code{bilinear}.

> +Default is @code{bicubic}.

[...]
> +{ "interpolation", "set pixel interpolation", OFFSET(interpolate), 
> AV_OPT_TYPE_INT,{.i64=1}, 0, 1, FLAGS, "interpolate" },
> +{ "i", "set pixel interpolation", OFFSET(interpolate), 
> AV_OPT_TYPE_INT,{.i64=1}, 0, 1, FLAGS, "interpolate" },
> +{ "nearest",NULL,   0, 
> AV_OPT_TYPE_CONST,  {.i64=0}, 0, 1, FLAGS, "interpolate" },
> +{ "bilinear",   NULL,   0, 
> AV_OPT_TYPE_CONST,  {.i64=1}, 0, 1, FLAGS, "interpolate" },
>  {NULL},

docs mismatch code, there is no bicubic

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

[FFmpeg-devel] [PATCH v9 01/11] avformat: Add fifo pseudo-muxer

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 Changes since the last version of the patch:
 - fixed "s@item" in muxers.texi
 - fixed second -> seconds in FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC comment
 - removed AVFormat *oformat from FifoContext (it is local variable now)
 - if recovery uses stream time to wait, last_recovery_ts is set to 
AV_NOPTS_VALUE,
   and when recovery is attempted and last_recovery_ts recovery is performed 
immediately
 - fixed stray space in pthread_join in fifo_write_trailer
 - fixed superfluous tests and av_thread_message_flush() in fifo_deinit
 - changed upper bound for queue_size option to INT_MAX

 Changelog|   1 +
 configure|   1 +
 doc/muxers.texi  |  92 +++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/fifo.c   | 661 +++
 libavformat/version.h|   2 +-
 7 files changed, 758 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/fifo.c

diff --git a/Changelog b/Changelog
index b903e31..c693d34 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
 - True Audio (TTA) muxer
 - crystalizer audio filter
 - acrusher audio filter
+- fifo muxer
 
 
 version 3.1:
diff --git a/configure b/configure
index 9b92426..894e7a9 100755
--- a/configure
+++ b/configure
@@ -2834,6 +2834,7 @@ dv_muxer_select="dvprofile"
 dxa_demuxer_select="riffdec"
 eac3_demuxer_select="ac3_parser"
 f4v_muxer_select="mov_muxer"
+fifo_muxer_deps="pthreads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 5873269..617c9a3 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1436,6 +1436,98 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)
 
 @end table
 
+@section fifo
+
+The fifo pseudo-muxer allows the separation of encoding and muxing by using
+first-in-first-out queue and running the actual muxer in a separate thread. 
This
+is especially useful in combination with the @ref{tee} muxer and can be used to
+send data to several destinations with different reliability/writing 
speed/latency.
+
+The behavior of the fifo muxer if the queue fills up or if the output fails is
+selectable,
+
+@itemize @bullet
+
+@item
+output can be transparently restarted with configurable delay between retries
+based on real time or time of the processed stream.
+
+@item
+encoding can be blocked during temporary failure, or continue transparently
+dropping packets in case fifo queue fills up.
+
+@end itemize
+
+@table @option
+
+@item fifo_format
+Specify the format name. Useful if it cannot be guessed from the
+output name suffix.
+
+@item queue_size
+Specify size of the queue (number of packets). Default value is 60.
+
+@item format_opts
+Specify format options for the underlying muxer. Muxer options can be specified
+as a list of @var{key}=@var{value} pairs separated by ':'.
+
+@item drop_pkts_on_overflow @var{bool}
+If set to 1 (true), in case the fifo queue fills up, packets will be dropped
+rather than blocking the encoder. This allows to continue streaming without
+delaying the input, at the cost of ommiting part of the stream. By default
+this option is set to 0 (false), so in such cases the encoder will be blocked
+until the muxer processes some of the packets and none of them is lost.
+
+@item attempt_recovery @var{bool}
+If failure occurs, attempt to recover the output. This is especially useful
+when used with network output, allows to restart streaming transparently.
+By default this option set to 0 (false).
+
+@item max_recovery_attempts
+Sets maximum number of successive unsucessful recovery attempts after which
+the output fails permanently. By default this option is set to 0 (unlimited).
+
+@item recovery_wait_time @var{duration}
+Waiting time before the next recovery attempt after previous unsuccessfull
+recovery attempt. Default value is 5 seconds.
+
+@item recovery_wait_streamtime @var{bool}
+If set to 0 (false), the real time is used when waiting for the recovery
+attempt (i.e. the recovery will be attempted after at least
+recovery_wait_time seconds).
+If set to 1 (true), the time of the processed stream is taken into account
+instead (i.e. the recovery will be attempted after at least 
@var{recovery_wait_time}
+seconds of the stream is omitted).
+By default, this option is set to 0 (false).
+
+@item recover_any_error @var{bool}
+If set to 1 (true), recovery will be attempted regardless of type of the error
+causing the failure. By default this option is set to 0 (false) and in case of
+certain (usually permanent) errors the recovery is not attempted even when
+@var{attempt_recovery} is set to 1.
+
+@item restart_with_keyframe @var{bool}
+Specify whether to wait for the keyframe after recovering from
+queue overflow or failure. This option is set to 0 (false) by default.
+
+@end table
+
+@subsection Examples
+
+

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

[sebechlebskyjan]

From: Jan Sebechlebsky 

Add support for nonblocking calls.

Signed-off-by: Jan Sebechlebsky 
---
 No chanes since the last version of patch, rebased because of changes in the
 patch adding fifo.

 libavformat/fifo.c | 62 --
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 859cbb4..689581f 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -19,12 +19,14 @@
  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/atomic.h"
 #include "libavutil/opt.h"
 #include "libavutil/time.h"
 #include "libavutil/thread.h"
 #include "libavutil/threadmessage.h"
 #include "avformat.h"
 #include "internal.h"
+#include "url.h"
 
 #define FIFO_DEFAULT_QUEUE_SIZE  60
 #define FIFO_DEFAULT_MAX_RECOVERY_ATTEMPTS   0
@@ -76,6 +78,17 @@ typedef struct FifoContext {
 /* Value > 0 signals queue overflow */
 volatile uint8_t overflow_flag;
 
+/* 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 int termination_requested;
+
+/* Initially 0, set to 1 immediately before thread function
+ * returns */
+volatile int thread_finished_flag;
+
+/* Original interrupt callback of the underlying muxer. */
+AVIOInterruptCB orig_interrupt_callback;
 } FifoContext;
 
 typedef struct FifoThreadContext {
@@ -110,6 +123,16 @@ typedef struct FifoMessage {
 AVPacket pkt;
 } FifoMessage;
 
+static int fifo_interrupt_callback_wrapper(void *arg)
+{
+FifoContext *ctx = arg;
+
+if (avpriv_atomic_int_get(&ctx->termination_requested))
+return 1;
+
+return ff_check_interrupt(&ctx->orig_interrupt_callback);
+}
+
 static int fifo_thread_write_header(FifoThreadContext *ctx)
 {
 AVFormatContext *avf = ctx->avf;
@@ -435,12 +458,17 @@ static void *fifo_consumer_thread(void *data)
 
 fifo->write_trailer_ret = fifo_thread_write_trailer(&fifo_thread_ctx);
 
+/* This must be only return path from fifo_consumer_thread function,
+ * so the thread_finised_flag is set. */
+avpriv_atomic_int_set(&fifo->thread_finished_flag, 1);
 return NULL;
 }
 
 static int fifo_mux_init(AVFormatContext *avf, AVOutputFormat *oformat)
 {
 FifoContext *fifo = avf->priv_data;
+AVIOInterruptCB interrupt_cb = {.callback = 
fifo_interrupt_callback_wrapper,
+.opaque = fifo};
 AVFormatContext *avf2;
 int ret = 0, i;
 
@@ -451,7 +479,8 @@ static int fifo_mux_init(AVFormatContext *avf, 
AVOutputFormat *oformat)
 
 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(&avf2->metadata, avf->metadata, 0);
 if (ret < 0)
@@ -539,7 +568,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(&msg.pkt);
@@ -548,15 +577,21 @@ static int fifo_write_packet(AVFormatContext *avf, 
AVPacket *pkt)
 return ret;
 }
 
-ret = av_thread_message_queue_send(fifo->queue, &msg,
-   fifo->drop_pkts_on_overflow ?
-   AV_THREAD_MESSAGE_NONBLOCK : 0);
+if (fifo->drop_pkts_on_overflow || (avf->flags & AVFMT_FLAG_NONBLOCK))
+queue_flags |= AV_THREAD_MESSAGE_NONBLOCK;
+
+ret = av_thread_message_queue_send(fifo->queue, &msg, queue_flags);
+
 if (ret == AVERROR(EAGAIN)) {
-uint8_t overflow_set = 0;
+uint8_t overflow_set;
+
+if (avf->flags & AVFMT_FLAG_NONBLOCK)
+goto fail;
 
 /* 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(&fifo->overflow_flag_lock);
 if (!fifo->overflow_flag)
 fifo->overflow_flag = overflow_set = 1;
@@ -584,6 +619,10 @@ static int fifo_write_trailer(AVFormatContext *avf)
 
 av_thread_message_queue_set_err_recv(fifo->queue, AVERROR_EOF);
 
+if ((avf->flags & AVFMT_FLAG_NONBLOCK) &&
+!avpriv_atomic_int_get(&fifo->thread_finished_flag))
+   return AVERROR(EAGAIN);
+
 ret = pthread_join(fifo->writer_thread, NULL);
 if (ret < 0) {
 av_log(avf, AV_LOG_ERROR, "pthread join error: %s\n",
@@ -599,6 +638,17 @@ static void fifo_deinit(AVFormatContext *avf)
 {
 FifoContext *fifo = avf->priv_data;
 
+if (avf->flags & AVFMT_FLAG_NONBLOCK) {
+int ret;
+avpriv_atomic_int_set(&fifo->termination_requested, 1);
+re

[FFmpeg-devel] [PATCH 0/6] fixes for HEVC GPU accelerated codec

[Nablet Developer]

We have create 6 patches based on latest
ffmpeg-master: 3282e31baaa77d161a4451c27ad0d45f78e1da0a
With these patches:
1.  We modify HEVC plugin loading order, default to HW plugin,
since HEVC can be supported in SKL platform.
2.  Move code in vaapi_allocator.c to ffmpeg_qsv.c, and re-use
hwaccel_context to enable video-memory transcoding.
3.  Enabled VPP and fixed some issues.
4.  Fixed some issues which is found by customer 

ChaoX A Liu (6):
  lavc/qsv(hevc): Change default plugin from hevc_sw to hevc_default,
which will load hevc_hw first, due to newly released MSDK.
  lavf/vpp: Enable vpp filter, an Intel GPU accelerated scaler.
  lavc/qsv: Enable hwaccel qsv_vidmem.
  lavf/vpp: enable video memory accel for transcoding with vpp.
lavc/qsv: export symbols "ff_qsv_*" which will be used by vpp.
ffmpeg_qsv: set default hwaccel to qsv.
  lavc/qsvdec: Reset decoder if MFX_ERR_UNDEFINED_BEHAVIOR is caught,
because this error may get decoder stuck.
  lavc/qsv-lavc/vpp: Promote gpu_copy to be a selectable parameter.
GPU-copy is defaultly closed because it seems to be unstable.

 configure |   3 +
 ffmpeg.c  |   2 +-
 ffmpeg.h  |   2 +
 ffmpeg_opt.c  |   2 +-
 ffmpeg_qsv.c  | 668 ++-
 libavcodec/libavcodec.v   |   1 +
 libavcodec/qsv.c  |  96 +++--
 libavcodec/qsv.h  |   5 +
 libavcodec/qsv_internal.h |   9 +-
 libavcodec/qsvdec.c   |  52 ++-
 libavcodec/qsvdec_h2645.c |  29 +-
 libavcodec/qsvdec_mpeg2.c |   6 +
 libavcodec/qsvdec_vc1.c   |   6 +
 libavcodec/qsvenc.c   |  14 +-
 libavcodec/qsvenc.h   |   4 +
 libavcodec/qsvenc_hevc.c  |  19 +-
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_vpp.c  | 976 ++
 19 files changed, 1828 insertions(+), 68 deletions(-)
 create mode 100644 libavfilter/vf_vpp.c

-- 
2.5.0

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

[FFmpeg-devel] [PATCH 2/6] lavf/vpp: Enable vpp filter, an Intel GPU accelerated scaler.

[Nablet Developer]

From: ChaoX A Liu 

Signed-off-by: ChaoX A Liu 
---
 configure |   3 +
 libavcodec/qsv.c  |   2 +-
 libavcodec/qsv_internal.h |   2 +-
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_vpp.c  | 863 ++
 6 files changed, 870 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_vpp.c

diff --git a/configure b/configure
index 9b92426..7eb7ffd 100755
--- a/configure
+++ b/configure
@@ -2086,6 +2086,7 @@ CONFIG_EXTRA="
 qsv
 qsvdec
 qsvenc
+qsvvpp
 rangecoder
 riffdec
 riffenc
@@ -3076,6 +3077,8 @@ tinterlace_pad_test_deps="tinterlace_filter"
 uspp_filter_deps="gpl avcodec"
 vidstabdetect_filter_deps="libvidstab"
 vidstabtransform_filter_deps="libvidstab"
+vpp_filter_deps="libmfx"
+vpp_filter_select="qsv"
 zmq_filter_deps="libzmq"
 zoompan_filter_deps="swscale"
 zscale_filter_deps="libzimg"
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index b505e14..c180ca8 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -168,7 +168,7 @@ static int ff_qsv_set_display_handle(AVCodecContext *avctx, 
QSVSession *qs)
  * @param avctxffmpeg metadata for this codec context
  * @param session  the MSDK session used
  */
-int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs)
+int ff_qsv_init_internal_session(void *avctx, QSVSession *qs)
 {
 mfxIMPL impl   = MFX_IMPL_AUTO_ANY;
 mfxVersion ver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 59d1336..e43728b 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -80,7 +80,7 @@ int ff_qsv_error(int mfx_err);
 
 int ff_qsv_codec_id_to_mfx(enum AVCodecID codec_id);
 
-int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs);
+int ff_qsv_init_internal_session(void *avctx, QSVSession *qs);
 
 int ff_qsv_load_plugins(mfxSession session, const char *load_plugins);
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 0d94f84..a15bf3c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -286,6 +286,7 @@ OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
 OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += vidstabutils.o 
vf_vidstabdetect.o
 OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += vidstabutils.o 
vf_vidstabtransform.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
+OBJS-$(CONFIG_VPP_FILTER)+= vf_vpp.o
 OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index feed4f8..ce209cc 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -301,6 +301,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(VIDSTABDETECT,  vidstabdetect,  vf);
 REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
 REGISTER_FILTER(VIGNETTE,   vignette,   vf);
+REGISTER_FILTER(VPP,vpp,vf);
 REGISTER_FILTER(VSTACK, vstack, vf);
 REGISTER_FILTER(W3FDIF, w3fdif, vf);
 REGISTER_FILTER(WAVEFORM,   waveform,   vf);
diff --git a/libavfilter/vf_vpp.c b/libavfilter/vf_vpp.c
new file mode 100644
index 000..0cfeafc
--- /dev/null
+++ b/libavfilter/vf_vpp.c
@@ -0,0 +1,863 @@
+/*
+ * Intel MediaSDK Quick Sync Video VPP filter
+ *
+ * copyright (c) 2015 Sven Dueking
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with Libav; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "internal.h"
+#include 
+#include "libavutil/parseutils.h"
+#include "libavutil/timestamp.h"
+#include "libavcodec/qsv.h"
+
+/**
+ * ToDo :
+ *
+ * - double check surface pointers for different fourccs
+ * - handle empty extbuffers
+ * - cropping
+ * - use AV_PIX_FMT_QSV to pass surfaces to encoder
+ * - deinterlace check settings etc.
+ * - allocate number of surfaces depending modules and number of b frames
+ */
+
+#define VPP_ZERO_MEMORY(VAR){ memset(&VAR, 0, sizeof(VAR)); }
+#define VPP_ALIGN16(value)  (((value + 15) >> 4) << 4)  // 
round up to a multiple of 16
+#define VPP_ALIGN32(value)   

[FFmpeg-devel] [PATCH 6/6] lavc/qsv-lavc/vpp: Promote gpu_copy to be a selectable parameter. GPU-copy is defaultly closed because it seems to be unstable.

[Nablet Developer]

From: ChaoX A Liu 

Signed-off-by: ChaoX A Liu 
---
 libavcodec/qsv.c  |  7 ++-
 libavcodec/qsv_internal.h |  1 +
 libavcodec/qsvdec.c   | 22 +-
 libavcodec/qsvdec_h2645.c | 12 
 libavcodec/qsvdec_mpeg2.c |  6 ++
 libavcodec/qsvdec_vc1.c   |  6 ++
 libavcodec/qsvenc.h   |  4 
 libavfilter/vf_vpp.c  |  8 +++-
 8 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index c180ca8..c61a29c 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -172,11 +172,16 @@ int ff_qsv_init_internal_session(void *avctx, QSVSession 
*qs)
 {
 mfxIMPL impl   = MFX_IMPL_AUTO_ANY;
 mfxVersion ver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
+mfxInitParam par;
 
 const char *desc;
 int ret;
 
-ret = MFXInit(impl, &ver, &qs->session);
+memset(&par, 0, sizeof(par));
+par.Implementation = impl;
+par.Version = ver;
+par.GPUCopy = qs->gpu_copy;
+ret = MFXInitEx(par, &qs->session);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Error initializing an internal MFX 
session\n");
 return ff_qsv_error(ret);
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 58589df..39778a9 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -73,6 +73,7 @@ typedef struct QSVSession {
 intfd_display;
 VADisplay  va_display;
 #endif
+intgpu_copy;
 } QSVSession;
 
 /**
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 2075a23..08a5eaa 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -176,13 +176,25 @@ static int alloc_frame(AVCodecContext *avctx, QSVFrame 
*frame)
 {
 int ret;
 
-ret = ff_get_buffer(avctx, frame->frame, AV_GET_BUFFER_FLAG_REF);
-if (ret < 0)
-return ret;
-
-if (frame->frame->format == AV_PIX_FMT_QSV) {
+if (avctx->pix_fmt == AV_PIX_FMT_QSV) {
+ret = ff_get_buffer(avctx, frame->frame, AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
 frame->surface = (mfxFrameSurface1*)frame->frame->data[3];
 } else {
+/*
+ * Align frame's width x height to 128x64.
+ * It's recommended to do so if GPU_Copy is turned on.
+ */
+frame->frame->format = avctx->pix_fmt;
+frame->frame->width  = FFALIGN(avctx->width, 128);
+frame->frame->height = FFALIGN(avctx->height, 64);
+ret = av_frame_get_buffer(frame->frame, 64);
+if (ret < 0)
+return ret;
+frame->frame->width  = avctx->width;
+frame->frame->height = avctx->height;
+
 frame->surface_internal.Info.BitDepthLuma   = 8;
 frame->surface_internal.Info.BitDepthChroma = 8;
 frame->surface_internal.Info.FourCC = MFX_FOURCC_NV12;
diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
index 208302b..a4adc10 100755
--- a/libavcodec/qsvdec_h2645.c
+++ b/libavcodec/qsvdec_h2645.c
@@ -248,6 +248,12 @@ static const AVOption hevc_options[] = {
 
 { "load_plugins", "A :-separate list of hexadecimal plugin UIDs to load in 
an internal session",
 OFFSET(qsv.load_plugins), AV_OPT_TYPE_STRING, { .str = "" }, 0, 0, VD 
},
+
+{ "gpu_copy", "Enable gpu copy in sysmem mode [default = off]", 
OFFSET(qsv.internal_qs.gpu_copy), AV_OPT_TYPE_INT, { .i64 = MFX_GPUCOPY_OFF }, 
MFX_GPUCOPY_DEFAULT, MFX_GPUCOPY_OFF, .flags = VD, "gpu_copy" },
+{ "default",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_DEFAULT }, 
0, 0, .flags = VD, "gpu_copy" },
+{ "on",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_ON },  
0, 0, .flags = VD, "gpu_copy" },
+{ "off",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_OFF }, 
0, 0, .flags = VD, "gpu_copy" },
+
 { NULL },
 };
 
@@ -286,6 +292,12 @@ AVHWAccel ff_h264_qsv_hwaccel = {
 
 static const AVOption options[] = {
 { "async_depth", "Internal parallelization depth, the higher the value the 
higher the latency.", OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 = 
ASYNC_DEPTH_DEFAULT }, 0, INT_MAX, VD },
+
+{ "gpu_copy", "Enable gpu copy in sysmem mode [default = off]", 
OFFSET(qsv.internal_qs.gpu_copy), AV_OPT_TYPE_INT, { .i64 = MFX_GPUCOPY_OFF }, 
MFX_GPUCOPY_DEFAULT, MFX_GPUCOPY_OFF, .flags = VD, "gpu_copy" },
+{ "default",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_DEFAULT }, 
0, 0, .flags = VD, "gpu_copy" },
+{ "on",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_ON },  
0, 0, .flags = VD, "gpu_copy" },
+{ "off",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_OFF }, 
0, 0, .flags = VD, "gpu_copy" },
+
 { NULL },
 };
 
diff --git a/libavcodec/qsvdec_mpeg2.c b/libavcodec/qsvdec_mpeg2.c
index 70ccbc5..5e2354a 100644
--- a/libavcodec/qsvdec_mpeg2.c
+++ b/libavcodec/qsvdec_mpeg2.c
@@ -72,6 +72,12 @@ AVHWAccel ff_mpeg2_qsv_hwaccel = {
 #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
 static const AVOptio

[FFmpeg-devel] [PATCH 5/6] lavc/qsvdec: Reset decoder if MFX_ERR_UNDEFINED_BEHAVIOR is caught, because this error may get decoder stuck.

[Nablet Developer]

From: ChaoX A Liu 

Signed-off-by: ChaoX A Liu 
---
 libavcodec/qsvdec.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 47dd818..2075a23 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -370,13 +370,18 @@ static int do_qsv_decode(AVCodecContext *avctx, 
QSVContext *q,
 av_usleep(500);
 } while (1);
 
-if (MFX_WRN_VIDEO_PARAM_CHANGED==ret) {
+if (MFX_WRN_VIDEO_PARAM_CHANGED == ret) {
 /* TODO: handle here minor sequence header changing */
-} else if (MFX_ERR_INCOMPATIBLE_VIDEO_PARAM==ret) {
+} else if (MFX_ERR_INCOMPATIBLE_VIDEO_PARAM == ret) {
 av_fifo_reset(q->input_fifo);
 flush = q->reinit_pending = 1;
 continue;
-}
+} else if (MFX_ERR_UNDEFINED_BEHAVIOR == ret)
+/*
+ * Decoder may get stuck with this errorcode.
+ * Reset decoder to avoid that.
+ */
+ff_qsv_decode_reset(avctx, q);
 
 if (sync) {
 QSVFrame *out_frame = find_frame(q, outsurf);
-- 
2.5.0

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

[FFmpeg-devel] [PATCH 4/6] lavf/vpp: enable video memory accel for transcoding with vpp. lavc/qsv: export symbols "ff_qsv_*" which will be used by vpp. ffmpeg_qsv: set default hwaccel to qsv.

[Nablet Developer]

From: ChaoX A Liu 

Signed-off-by: ChaoX A Liu 
---
 ffmpeg_qsv.c|  46 ---
 libavcodec/libavcodec.v |   1 +
 libavcodec/qsv.h|   2 +
 libavfilter/vf_vpp.c| 153 
 4 files changed, 172 insertions(+), 30 deletions(-)

diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
index ec8a41b..70a3ecf 100644
--- a/ffmpeg_qsv.c
+++ b/ffmpeg_qsv.c
@@ -387,7 +387,7 @@ static mfxStatus frame_alloc(mfxHDL pthis, 
mfxFrameAllocRequest *request, mfxFra
 unsigned int va_fourcc = 0;
 mfxU32 fourcc = request->Info.FourCC;
 QSVContext *q = pthis;
-AVQSVContext *qsv = q->ost->enc_ctx->hwaccel_context;
+AVQSVContext *qsv = NULL;
 mfxU16 numAllocated = 0;
 bool bCreateSrfSucceeded = false;
 mfxU32 mfx_fourcc;
@@ -395,17 +395,40 @@ static mfxStatus frame_alloc(mfxHDL pthis, 
mfxFrameAllocRequest *request, mfxFra
 int width32;
 int height32;
 void *avctx = NULL;
+FilterGraph *fg = q->ost->filter->graph;
 
-av_log(avctx, AV_LOG_INFO, "=vaapi alloc frame==\n");
 if (!request || !response || !request->NumFrameSuggested)
 return MFX_ERR_MEMORY_ALLOC;
 
 memset(response, 0, sizeof(*response));
 surface_num = request->NumFrameSuggested;
-if ((request->Type & MFX_MEMTYPE_EXTERNAL_FRAME) &&
-(request->Type & MFX_MEMTYPE_FROM_DECODE))
-surface_num += (qsv->nb_encoder_surfaces + qsv->nb_decoder_surfaces);
+if (request->Type & MFX_MEMTYPE_FROM_DECODE) {
+avctx = input_streams[q->ost->source_index]->dec_ctx;
+if (request->Type & MFX_MEMTYPE_EXTERNAL_FRAME) {
+AVFilterContext *vpp = avfilter_graph_get_filter(fg->graph, 
"Parsed_vpp_0");
+qsv = 
input_streams[q->ost->source_index]->dec_ctx->hwaccel_context;
+surface_num += qsv->nb_decoder_surfaces;
+if (vpp) {
+qsv = vpp->hw_device_ctx->data;
+surface_num += qsv->nb_vpp_surfaces;
+} else {
+qsv = q->ost->enc_ctx->hwaccel_context;
+surface_num += qsv->nb_encoder_surfaces;
+}
+}
+} else if (request->Type & MFX_MEMTYPE_FROM_VPPOUT) {
+AVFilterContext *vpp = avfilter_graph_get_filter(fg->graph, 
"Parsed_vpp_0");
+avctx = vpp;
+if (request->Type & MFX_MEMTYPE_EXTERNAL_FRAME) {
+qsv = q->ost->enc_ctx->hwaccel_context;
+surface_num += qsv->nb_encoder_surfaces;
+}
+} else if (request->Type & MFX_MEMTYPE_FROM_ENCODE) {
+avctx = q->ost->enc_ctx;
+} else
+av_log(avctx, AV_LOG_WARNING, "FrameAlloc: may get a bug.\n");
 
+av_log(avctx, AV_LOG_INFO, "=vaapi alloc frame==\n");
 av_log(avctx, AV_LOG_INFO, "VAAPI: va_dpy =%p, surface_num=%d, width=%d, 
height=%d\n",
 g_session.va_display, surface_num, request->Info.Width, 
request->Info.Height);
 av_log(avctx, AV_LOG_INFO, "VAAPI: request->Type=%x\n",request->Type);
@@ -721,7 +744,7 @@ static int qsv_check_filters(const OutputStream *ost)
 AVFilterInOut *inputs, *outputs;
 int ret = 0;
 int i;
-const char *filter_list = "buffer|buffersink|null|format|setpts";
+const char *filter_list = "buffer|buffersink|null|format|setpts|vpp";
 
 if (!ost->avfilter)
 return -1;
@@ -821,6 +844,7 @@ int qsv_transcode_init_vidmem(OutputStream *ost)
 
 QSVContext *qsv = NULL;
 AVQSVContext *enc_hwctx = NULL;
+AVQSVContext *vpp_hwctx = NULL;
 
 /* check if the encoder supports QSV */
 if (!ost->enc->pix_fmts)
@@ -837,6 +861,8 @@ int qsv_transcode_init_vidmem(OutputStream *ost)
 
 /* check if the decoder supports QSV and the output only goes to this 
stream */
 ist = input_streams[ost->source_index];
+if (ist->hwaccel_id == HWACCEL_NONE || ist->hwaccel_id == HWACCEL_AUTO)
+ist->hwaccel_id = HWACCEL_QSV;
 if (ist->nb_filters || ist->hwaccel_id != HWACCEL_QSV ||
 !ist->dec || !ist->dec->pix_fmts)
 return 0;
@@ -855,7 +881,8 @@ int qsv_transcode_init_vidmem(OutputStream *ost)
 
 qsv   = av_mallocz(sizeof(*qsv));
 enc_hwctx = av_qsv_alloc_context();
-if (!qsv || !enc_hwctx)
+vpp_hwctx = av_qsv_alloc_context();
+if (!qsv || !enc_hwctx || !vpp_hwctx)
 goto fail;
 
 err = ff_qsv_init_internal_session(NULL, &g_session);
@@ -892,6 +919,11 @@ int qsv_transcode_init_vidmem(OutputStream *ost)
 ist->resample_pix_fmt= AV_PIX_FMT_QSV;
 ist->hwaccel_ctx = qsv;
 
+vpp_hwctx->session   = qsv->session;
+vpp_hwctx->iopattern = MFX_IOPATTERN_IN_VIDEO_MEMORY;
+vpp_hwctx->pFrameAllocator   = &qsv->frame_allocator;
+hw_device_ctx = av_buffer_create(vpp_hwctx, sizeof(*vpp_hwctx), 
av_buffer_default_free, NULL, 0);
+
 return 0;
 
 fail:
diff --git a/libavcodec/libavcodec.v b/libavcodec/libavcodec.v
index 304c2ef..1a4cac8 100644
--- a/l

[FFmpeg-devel] [PATCH 3/6] lavc/qsv: Enable hwaccel qsv_vidmem.

[Nablet Developer]

From: ChaoX A Liu 

Signed-off-by: ChaoX A Liu 
---
 ffmpeg.c  |   2 +-
 ffmpeg.h  |   2 +
 ffmpeg_opt.c  |   2 +-
 ffmpeg_qsv.c  | 636 +-
 libavcodec/qsv.h  |   3 +
 libavcodec/qsv_internal.h |   2 +
 libavcodec/qsvdec.c   |   5 +-
 libavcodec/qsvenc.c   |   2 +
 8 files changed, 649 insertions(+), 5 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index bae515d..a8bc237 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3050,7 +3050,7 @@ static int transcode_init(void)
 set_encoder_id(output_files[ost->file_index], ost);
 
 #if CONFIG_LIBMFX
-if (qsv_transcode_init(ost))
+if (qsv_transcode_init_vidmem(ost))
 exit_program(1);
 #endif
 
diff --git a/ffmpeg.h b/ffmpeg.h
index 49d65d8..266 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -585,6 +585,8 @@ int vda_init(AVCodecContext *s);
 int videotoolbox_init(AVCodecContext *s);
 int qsv_init(AVCodecContext *s);
 int qsv_transcode_init(OutputStream *ost);
+int qsv_init_vidmem(AVCodecContext *s);
+int qsv_transcode_init_vidmem(OutputStream *ost);
 int vaapi_decode_init(AVCodecContext *avctx);
 int vaapi_device_init(const char *device);
 int cuvid_init(AVCodecContext *s);
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 2ea09cf..b5e4483 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -79,7 +79,7 @@ const HWAccel hwaccels[] = {
 { "videotoolbox",   videotoolbox_init,   HWACCEL_VIDEOTOOLBOX,   
AV_PIX_FMT_VIDEOTOOLBOX },
 #endif
 #if CONFIG_LIBMFX
-{ "qsv",   qsv_init,   HWACCEL_QSV,   AV_PIX_FMT_QSV },
+{ "qsv",   qsv_init_vidmem,   HWACCEL_QSV,   AV_PIX_FMT_QSV },
 #endif
 #if CONFIG_VAAPI
 { "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI },
diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
index 95a2351..ec8a41b 100644
--- a/ffmpeg_qsv.c
+++ b/ffmpeg_qsv.c
@@ -18,11 +18,15 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "libavutil/dict.h"
 #include "libavutil/mem.h"
 #include "libavutil/opt.h"
+#include "libavutil/avstring.h"
 #include "libavcodec/qsv.h"
+#include "libavcodec/qsv_internal.h"
 
 #include "ffmpeg.h"
 
@@ -34,6 +38,8 @@ typedef struct QSVContext {
 mfxExtOpaqueSurfaceAlloc opaque_alloc;
 AVBufferRef *opaque_surfaces_buf;
 
+mfxFrameAllocator frame_allocator;
+
 uint8_t   *surface_used;
 mfxFrameSurface1 **surface_ptrs;
 int nb_surfaces;
@@ -60,7 +66,7 @@ static int qsv_get_buffer(AVCodecContext *s, AVFrame *frame, 
int flags)
  buffer_release, 
&qsv->surface_used[i], 0);
 if (!frame->buf[0])
 return AVERROR(ENOMEM);
-frame->data[3]   = (uint8_t*)qsv->surface_ptrs[i];
+frame->data[3]   = frame->buf[0]->data;
 qsv->surface_used[i] = 1;
 return 0;
 }
@@ -266,3 +272,631 @@ fail:
 av_freep(&qsv);
 return AVERROR_UNKNOWN;
 }
+
+enum {
+MFX_FOURCC_VP8_NV12= MFX_MAKEFOURCC('V','P','8','N'),
+MFX_FOURCC_VP8_MBDATA  = MFX_MAKEFOURCC('V','P','8','M'),
+MFX_FOURCC_VP8_SEGMAP  = MFX_MAKEFOURCC('V','P','8','S'),
+};
+
+typedef struct vaapiMemId
+{
+VASurfaceID* m_surface;
+VAImage m_image;
+unsigned int m_fourcc;
+mfxU8* m_sys_buffer;
+mfxU8* m_va_buffer;
+} vaapiMemId;
+
+static QSVSession g_session;
+
+/* 
** 
*\
+
+INTEL CORPORATION PROPRIETARY INFORMATION
+This software is supplied under the terms of a license agreement or 
nondisclosure
+agreement with Intel Corporation and may not be copied or disclosed except in
+accordance with the terms of that agreement
+Copyright(c) 2011-2014 Intel Corporation. All Rights Reserved.
+
+\* 
** 
*/
+static mfxStatus va_to_mfx_status(VAStatus va_res)
+{
+mfxStatus mfxRes = MFX_ERR_NONE;
+
+switch (va_res) {
+case VA_STATUS_SUCCESS:
+mfxRes = MFX_ERR_NONE;
+break;
+case VA_STATUS_ERROR_ALLOCATION_FAILED:
+mfxRes = MFX_ERR_MEMORY_ALLOC;
+break;
+case VA_STATUS_ERROR_ATTR_NOT_SUPPORTED:
+case VA_STATUS_ERROR_UNSUPPORTED_PROFILE:
+case VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT:
+case VA_STATUS_ERROR_UNSUPPORTED_RT_FORMAT:
+case VA_STATUS_ERROR_UNSUPPORTED_BUFFERTYPE:
+case VA_STATUS_ERROR_FLAG_NOT_SUPPORTED:
+case VA_STATUS_ERROR_RESOLUTION_NOT_SUPPORTED:
+mfxRes = MFX_ERR_UNSUPPORTED;
+break;
+case VA_STATUS_ERROR_INVALID_DISPLAY:
+case VA_STATUS_ERROR_INVALID_CONFIG:
+case VA_STATUS_ERROR_INVALID_CONTEXT:
+case VA_STATUS_ERROR_INVALID_SURFACE:
+case VA_STATUS_ERROR_INVALID_BUFFER:
+case VA_STATUS_ERROR_INVALID_IMAGE:
+case VA_STATUS_ERROR_INVALID_SUBPICTURE:
+mfxRes = MFX_ERR_NOT_INITIALIZED;

Re: [FFmpeg-devel] [PATCH] avfilter/vf_geq: add interpolation option

[Paul B Mahol]

On 8/16/16, Michael Niedermayer  wrote:
> On Tue, Aug 16, 2016 at 08:54:16AM +0200, Paul B Mahol wrote:
>> On 8/16/16, Michael Niedermayer  wrote:
>> > On Mon, Aug 15, 2016 at 08:15:10PM +0200, Paul B Mahol wrote:
>> >> Hi,
>> >>
>> >> patch attached.
>> >
>> > this mail has no attachments
>> >
>>
>> Sorry.
>
>>  doc/filters.texi |3 +++
>>  libavfilter/vf_geq.c |   32 +++-
>>  2 files changed, 34 insertions(+), 1 deletion(-)
>> 650a493e529b204f714d9dcd3cd0a4e61a083048
>> 0001-avfilter-vf_geq-add-interpolation-option.patch
>> From 7460f0fd0829b5bf550fb0283d6d9f8a21e7467a Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol 
>> Date: Mon, 15 Aug 2016 19:54:29 +0200
>> Subject: [PATCH] avfilter/vf_geq: add interpolation option
>>
>> ---
>>  doc/filters.texi |  3 +++
>>  libavfilter/vf_geq.c | 32 +++-
>>  2 files changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index c595fed..475a929 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -8221,6 +8221,9 @@ Set the red expression.
>>  Set the green expression.
>>  @item blue_expr, b
>>  Set the blue expression.
>> +@item interpolation, i
>> +Set pixel interpolation. Can be @code{nearest} or @code{bilinear}.
>
>> +Default is @code{bicubic}.
>
> [...]
>> +{ "interpolation", "set pixel interpolation", OFFSET(interpolate),
>> AV_OPT_TYPE_INT,{.i64=1}, 0, 1, FLAGS, "interpolate" },
>> +{ "i", "set pixel interpolation", OFFSET(interpolate),
>> AV_OPT_TYPE_INT,{.i64=1}, 0, 1, FLAGS, "interpolate" },
>> +{ "nearest",NULL,   0,
>> AV_OPT_TYPE_CONST,  {.i64=0}, 0, 1, FLAGS, "interpolate" },
>> +{ "bilinear",   NULL,   0,
>> AV_OPT_TYPE_CONST,  {.i64=1}, 0, 1, FLAGS, "interpolate" },
>>  {NULL},
>
> docs mismatch code, there is no bicubic

right, fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/6] lavf/vpp: Enable vpp filter, an Intel GPU accelerated scaler.

[Paul B Mahol]

On 8/16/16, Nablet Developer  wrote:
> From: ChaoX A Liu 
>
> Signed-off-by: ChaoX A Liu 
> ---
>  configure |   3 +
>  libavcodec/qsv.c  |   2 +-
>  libavcodec/qsv_internal.h |   2 +-
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_vpp.c  | 863
> ++
>  6 files changed, 870 insertions(+), 2 deletions(-)
>  create mode 100644 libavfilter/vf_vpp.c
>

vpp is too short and cryptic name IMHO.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/6] lavc/qsv(hevc): Change default plugin from hevc_sw to hevc_default, which will load hevc_hw first, due to newly released MSDK.

[Nablet Developer]

From: ChaoX A Liu 

Signed-off-by: ChaoX A Liu 
---
 libavcodec/qsv.c  | 89 ---
 libavcodec/qsv_internal.h |  6 ++--
 libavcodec/qsvdec.c   | 16 ++---
 libavcodec/qsvdec_h2645.c | 17 ++---
 libavcodec/qsvenc.c   | 12 +--
 libavcodec/qsvenc_hevc.c  | 19 +-
 6 files changed, 104 insertions(+), 55 deletions(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 11d453d..b505e14 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -168,8 +168,7 @@ static int ff_qsv_set_display_handle(AVCodecContext *avctx, 
QSVSession *qs)
  * @param avctxffmpeg metadata for this codec context
  * @param session  the MSDK session used
  */
-int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
- const char *load_plugins)
+int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs)
 {
 mfxIMPL impl   = MFX_IMPL_AUTO_ANY;
 mfxVersion ver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
@@ -187,67 +186,87 @@ int ff_qsv_init_internal_session(AVCodecContext *avctx, 
QSVSession *qs,
 if (ret < 0)
 return ret;
 
+MFXQueryIMPL(qs->session, &impl);
+
+switch (MFX_IMPL_BASETYPE(impl)) {
+case MFX_IMPL_SOFTWARE:
+desc = "software";
+break;
+case MFX_IMPL_HARDWARE:
+case MFX_IMPL_HARDWARE2:
+case MFX_IMPL_HARDWARE3:
+case MFX_IMPL_HARDWARE4:
+desc = "hardware accelerated";
+break;
+default:
+desc = "unknown";
+}
+
+av_log(avctx, AV_LOG_VERBOSE,
+   "Initialized an internal MFX session using %s implementation\n",
+   desc);
+
+return 0;
+}
+
+/**
+ * @brief Load plugins for a MSDK session
+ *
+ * Media SDK may need external plugins to decode/encode,
+ * such as hevc_dec and hevc_enc. So it's necessary to load
+ * proper plugins.
+ *
+ * @param session   the MSDK session used
+ * @param load_plugins  the load_plugins to be loaded.
+ */
+int ff_qsv_load_plugins(mfxSession session, const char *load_plugins)
+{
+int err = 0, load_num = 0, i;
+
 if (load_plugins && *load_plugins) {
 while (*load_plugins) {
 mfxPluginUID uid;
-int i, err = 0;
 
 char *plugin = av_get_token(&load_plugins, ":");
 if (!plugin)
 return AVERROR(ENOMEM);
 if (strlen(plugin) != 2 * sizeof(uid.Data)) {
-av_log(avctx, AV_LOG_ERROR, "Invalid plugin UID length\n");
 err = AVERROR(EINVAL);
 goto load_plugin_fail;
 }
+if (*load_plugins == ':')
+load_plugins ++;
 
 for (i = 0; i < sizeof(uid.Data); i++) {
 err = sscanf(plugin + 2 * i, "%2hhx", uid.Data + i);
 if (err != 1) {
-av_log(avctx, AV_LOG_ERROR, "Invalid plugin UID\n");
 err = AVERROR(EINVAL);
 goto load_plugin_fail;
 }
-
 }
 
-ret = MFXVideoUSER_Load(qs->session, &uid, 1);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Could not load the requested 
plugin: %s\n",
-   plugin);
-err = ff_qsv_error(ret);
+err = MFXVideoUSER_Load(session, &uid, 1);
+if (err < 0) {
+err = ff_qsv_error(err);
 goto load_plugin_fail;
 }
+load_num ++;
 
-if (*load_plugins)
-load_plugins++;
 load_plugin_fail:
 av_freep(&plugin);
-if (err < 0)
-return err;
+/*
+ * If more plugins are going to be loaded,
+ * ignore current error and continue.
+ */
+if (*load_plugins == ':') {
+load_plugins ++;
+err = 0;
+}
 }
+if (!load_num)
+return err;
 }
 
-MFXQueryIMPL(qs->session, &impl);
-
-switch (MFX_IMPL_BASETYPE(impl)) {
-case MFX_IMPL_SOFTWARE:
-desc = "software";
-break;
-case MFX_IMPL_HARDWARE:
-case MFX_IMPL_HARDWARE2:
-case MFX_IMPL_HARDWARE3:
-case MFX_IMPL_HARDWARE4:
-desc = "hardware accelerated";
-break;
-default:
-desc = "unknown";
-}
-
-av_log(avctx, AV_LOG_VERBOSE,
-   "Initialized an internal MFX session using %s implementation\n",
-   desc);
-
 return 0;
 }
 
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index f289a2b..59d1336 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -80,8 +80,10 @@ int ff_qsv_error(int mfx_err);
 
 int ff_qsv_codec_id_to_mfx(enum AVCodecID codec_id);
 
-int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
- const char *load_plugins);
+int ff_qsv_init_internal_session(AVCodecContext *avctx, Q

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add trailing_padding to AVCodecContext to match AVCodecParameters.

[Michael Niedermayer]

On Mon, Aug 15, 2016 at 01:13:06PM -0700, Jon Toohill wrote:
> Shows encoder delay/padding in the stream summary if they are set.
> ---
>  doc/APIchanges   |  4 
>  libavcodec/avcodec.h | 11 +++
>  libavcodec/utils.c   | 40 +++-
>  libavcodec/version.h |  2 +-
>  4 files changed, 39 insertions(+), 18 deletions(-)

applied

thanks

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

[FFmpeg-devel] [PATCH] avformat: Document thread-safety requirement for interrupt callback

[sebechlebskyjan]

From: Jan Sebechlebsky 

Muxing might be running in a separate thread if actual muxer is
run inside of fifo pseudo-muxer. Callback should be therefore
thread-safe.

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/avformat.h | 2 +-
 libavformat/avio.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 79c2511..8550dca 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1564,7 +1564,7 @@ typedef struct AVFormatContext {
  * muxing: set by the user before avformat_write_header()
  * (mainly useful for AVFMT_NOFILE formats). The callback
  * should also be passed to avio_open2() if it's used to
- * open the file.
+ * open the file. The callback must be thread-safe.
  */
 AVIOInterruptCB interrupt_callback;
 
diff --git a/libavformat/avio.h b/libavformat/avio.h
index b1ce1d1..b5d1396 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -43,6 +43,8 @@
  * opaque as parameter. If the callback returns 1, the
  * blocking operation will be aborted.
  *
+ * If the callback is used in muxing context, it has to be thread-safe.
+ *
  * No members can be added to this struct without a major bump, if
  * new elements have been added after this struct in AVFormatContext
  * or AVIOContext.
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add trailing_padding to AVCodecContext to match AVCodecParameters.

[Paul B Mahol]

On 8/16/16, Michael Niedermayer  wrote:
> On Mon, Aug 15, 2016 at 01:13:06PM -0700, Jon Toohill wrote:
>> Shows encoder delay/padding in the stream summary if they are set.
>> ---
>>  doc/APIchanges   |  4 
>>  libavcodec/avcodec.h | 11 +++
>>  libavcodec/utils.c   | 40 +++-
>>  libavcodec/version.h |  2 +-
>>  4 files changed, 39 insertions(+), 18 deletions(-)
>
> applied
>

Please revert, no proper review was made.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add trailing_padding to AVCodecContext to match AVCodecParameters.

[Michael Niedermayer]

On Tue, Aug 16, 2016 at 12:55:17PM +0200, Paul B Mahol wrote:
> On 8/16/16, Michael Niedermayer  wrote:
> > On Mon, Aug 15, 2016 at 01:13:06PM -0700, Jon Toohill wrote:
> >> Shows encoder delay/padding in the stream summary if they are set.
> >> ---
> >>  doc/APIchanges   |  4 
> >>  libavcodec/avcodec.h | 11 +++
> >>  libavcodec/utils.c   | 40 +++-
> >>  libavcodec/version.h |  2 +-
> >>  4 files changed, 39 insertions(+), 18 deletions(-)
> >
> > applied
> >
> 
> Please revert, no proper review was made.

please elaborate, what is the problem with the patch ?

also this patch was posted 4 times already
in may, june and july, noone objected to it previously. in fact the
only reply i see is a review from me in may

The only substantial difference to the previous patch i see was the
subject "lavc: show gapless info in stream summary"

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] avformat: Document thread-safety requirement for interrupt callback

[Nicolas George]

Le decadi 30 thermidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> From: Jan Sebechlebsky 
> 
> Muxing might be running in a separate thread if actual muxer is
> run inside of fifo pseudo-muxer. Callback should be therefore
> thread-safe.

This is an incompatible API change, and therefore not acceptable.

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] [FFmpeg-cvslog] avfilter/avf_showspectrum: add some multithreading support

[Michael Niedermayer]

On Mon, Aug 15, 2016 at 01:23:39PM +0200, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol  | Mon Aug 15 
> 11:53:56 2016 +0200| [ce5ba770794576cd40749d7754cb8a837ef73e2f] | committer: 
> Paul B Mahol
> 
> avfilter/avf_showspectrum: add some multithreading support
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ce5ba770794576cd40749d7754cb8a837ef73e2f
> ---
> 
>  libavfilter/avf_showspectrum.c | 232 
> +++--
>  1 file changed, 131 insertions(+), 101 deletions(-)

This breaks deterministic output

example:
./ffmpeg -f lavfi -i 
"amovie=fatesamples/fate/fate-suite/wavpack/num_channels/eva_2.22_6.1_16bit-partial.wv,showspectrum=s=340x240[out0]"
  -t 0.1 -qscale 2 -y file.avi ; md5sum file.avi

3c72107b59723d98b7c0189cb5b5c8ca  file.avi
3b499002b978dcd4e6f8ae3ea4ca9b1f  file.avi
b731923314d304234c01e1a985adfd19  file.avi

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

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


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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Michael Niedermayer]

On Sat, Aug 13, 2016 at 12:18:56PM +, Davinder Singh wrote:
> On Thu, Aug 11, 2016 at 12:10 AM Davinder Singh  wrote:
> 
> > [...]
> >
> > latest changes:
> https://github.com/dsmudhar/FFmpeg/blob/dev/libavfilter/vf_minterpolate.c
> uses shared motion estimation code now, added options, improved vsbmc
> i tried to make filter options as flexible as possible so that multiple
> algorithms are be supported.
> 
> @Ronald:
> have a look:
> https://github.com/dsmudhar/FFmpeg/blob/dev/libavfilter/motion_estimation.c
> i think if penalty factor can be moved into cost function, motion
> estimation can be shared with encoders. we can start work on this after
> GSoC?
> 
> TODO:
> frame border motion estimation.
> add scene change threshold. roughness check doesn't work so well and
> introduce artifacts.
> add docs.
> 
> 
> > here's another idea: dynamic block size selection for MC-FRUC
> > since it's not video encoding, using 16x16 block with fixed search window
> > may not work same for all resolution videos. what if we automatic resize
> > block depending on resolution? like if 16x16, P=20 works fine for 1280x720
> > video, we can scale it according to width, e.g for 1920x1080 which 1.5x
> > 1280, we use 24x24 block and also scale P accordingly? i haven't tested it
> > yet though.
> >
> 
> i tested this. quality was improved with 1080p but not with smaller
> resolution.
> 
> I tried to scale best settings of 720p. UMH. 1080p same video.
> scale nothing: mb16 p18
> stddev:1.16 PSNR: 46.80 MAXDIFF:  197 bytes:1085529600/1073088000
> scale search window: mb16, p27
> stddev:1.21 PSNR: 46.47 MAXDIFF:  193 bytes:1085529600/1073088000
> scale both: mb24 p18
> stddev:1.14 PSNR: 46.93 MAXDIFF:  181 bytes:1085529600/1073088000
> 
> ESA
> mb16 p16:
> stddev:1.18 PSNR: 46.65 MAXDIFF:  181 bytes:1085529600/1073088000
> mb24 p24:
> stddev:1.16 PSNR: 46.77 MAXDIFF:  181 bytes:1085529600/1073088000
> 
> 640p ESA
> m16 p16:
> stddev:1.01 PSNR: 47.97 MAXDIFF:  160 bytes:119577600/118540800
> scale p: mb16 p8:
> stddev:1.02 PSNR: 47.95 MAXDIFF:  148 bytes:119577600/118540800
> scale both: m8 p8:
> stddev:1.05 PSNR: 47.63 MAXDIFF:  187 bytes:119577600/118540800
> 
> i think quality can be further improved, generated test window weights were
> not perfect.
> should i keep this feature? since block-size won't be log2 int, that will
> break vsbmc which use quadtree division for smaller blocks.
> 
> 
> > [1]: JVT-F017.pdf by Z Chen 
> >
> 
> 
> On Thu, Aug 11, 2016 at 9:09 PM Paul B Mahol  wrote:
> 
> > Could you please squash your commits and attach patches that add
> > vf_mestimate
> > and vf_minterpolate filters?
> >
> 
> patch attached.

>  doc/filters.texi|   25 
>  libavfilter/Makefile|2 
>  libavfilter/allfilters.c|2 
>  libavfilter/motion_estimation.c |  451 +
>  libavfilter/motion_estimation.h |   76 ++
>  libavfilter/vf_mestimate.c  |  376 +++
>  libavfilter/vf_minterpolate.c   | 1332 
> 

not sure i suggested it previously already but you can add yourself
to the MAINTAINERs file if you want to maintain / continue working on
the code after GSoC

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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: Remove libfaac, the internal AAC encoder is better

[Robert Krüger]

On Mon, Aug 15, 2016 at 7:58 PM, Nicolas George  wrote:

> Le nonidi 29 thermidor, an CCXXIV, Rostislav Pehlivanov a écrit :
> > The git master is fast changing and  can happen API or setting
> > wise every day. Deprecations, behavioral changes, etc. This is why users
> > who need stability use the stable releases.
>
> Actually, I think the consensus is that releases are meant for
> distributions, not users, and even the Git head is supposed to maintain a
> reasonable stability.
>
>
I agree, whenever someone reports an issue, they are pointed to master
really being the thing maintained best.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

[Robert Krüger]

On Mon, Aug 15, 2016 at 7:47 PM, Rostislav Pehlivanov 
wrote:

> On 15 August 2016 at 11:51, Robert Krüger 
> wrote:
>
> > On Sun, Aug 14, 2016 at 5:05 PM, Rostislav Pehlivanov <
> atomnu...@gmail.com
> > >
> > wrote:
> >
> > > On 10 April 2016 at 16:38, Kieran Kunhya  wrote:
> > >
>
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> The git master is fast changing and  can happen API or setting
> wise every day. Deprecations, behavioral changes, etc. This is why users
> who need stability use the stable releases. Hell, we've removed far bigger
> external library support this year.
> So no. They've had PLENTY of time to switch to the internal AAC encoder
> (since December last year) and plenty of versions to try out since then.
> It's getting removed and it's getting removed soon. Like ffserver.
>
>
Your call but definitely not a nice thing with regard to users. I may have
missed it but I haven't seen an announcement that this is going to happen
and thought deprecation was the tool exactly for that as is used in other
software/frameworks/projects especially for non-exotic features like in
this case probably one of the most used encoders out there in ffmpeg-based
systems. but I will shut up now. You seem to have a pretty strong opinion
on this and I'm merely providing input as a downstream user not a dev.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avisynth: support pix_fmts added to AviSynth+

[Michael Niedermayer]

On Mon, Aug 15, 2016 at 12:37:31PM -0400, Stephen Hutchinson wrote:
> A number of new pix_fmts have been added to AviSynth+:
> 16-bit packed RGB and RGBA
> 10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
> 8-, 10-, 12-, 14-, and 16-bit Planar RGB
> 8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
> 10-, 12-, 14-, and 16-bit GRAY variants*
> 32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*
> 
> *some of which are not currently available pix_fmts here and were
>  not added to the demuxer due to this
> ---
>  libavformat/avisynth.c | 176 
> -
>  1 file changed, 175 insertions(+), 1 deletion(-)

breaks build

libavformat/avisynth.c:100:40: error: ‘AVS_PLANAR_G’ undeclared here (not in a 
function)
libavformat/avisynth.c:100:54: error: ‘AVS_PLANAR_B’ undeclared here (not in a 
function)
libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in a 
function)
libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in a 
function)
libavformat/avisynth.c: In function ‘avisynth_read_packet_video’:
libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgb’
libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgba’
make: *** [libavformat/avisynth.o] Error 1

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH 3/4] v5 - SCTE-35 support in hlsenc

[Michael Niedermayer]

On Mon, Aug 15, 2016 at 10:47:49AM -0700, Carlos Fernandez Sanz wrote:
> From: Carlos Fernandez 
> 
> Signed-off-by: Carlos Fernandez 
> ---
>  libavformat/Makefile  |   2 +-
>  libavformat/hlsenc.c  | 107 --
>  libavformat/scte_35.c | 525 
> ++
>  libavformat/scte_35.h |  86 +
>  4 files changed, 698 insertions(+), 22 deletions(-)
>  create mode 100644 libavformat/scte_35.c
>  create mode 100644 libavformat/scte_35.h

seems to break build

libavformat/scte_35.c: In function ‘ff_alloc_scte35_parser’:
libavformat/scte_35.c:511:30: error: ‘get_event_cache’ undeclared (first use in 
this function)
libavformat/scte_35.c:511:30: note: each undeclared identifier is reported only 
once for each function it appears in
libavformat/scte_35.c: In function ‘ff_delete_scte35_parser’:
libavformat/scte_35.c:523:30: error: ‘struct scte_35_interface’ has no member 
named ‘avbstrr’
libavformat/scte_35.c: At top level:
libavformat/scte_35.c:480:30: warning: ‘update_event_state’ defined but not 
used [-Wunused-function]
libavformat/hlsenc.c: In function ‘hls_write_packet’:
libavformat/hlsenc.c:895:36: error: ‘struct scte_35_interface’ has no member 
named ‘update_event_state’
make: *** [libavformat/scte_35.o] Error 1
make: *** [libavformat/hlsenc.o] Error 1

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

[FFmpeg-devel] PATCH: dshow prevent some windows 10 anniv. ed crashes

[Roger Pack]

Windows 10 anniversary edition screwed with how dshow video capture works.
This patch "helps" in some instances, though it still crashes with
rgb24 input (still working on that), at least now it works with yuvp
etc.
Thanks.
-Roger (a dshow maintainer)


0001-dshow-satisfy-alloc-contract-better-prevent-non-rgb2.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avisynth: support pix_fmts added to AviSynth+

[Roger Pack]

Does this require some version check in configure to be added as well?

On 8/16/16, Michael Niedermayer  wrote:
> On Mon, Aug 15, 2016 at 12:37:31PM -0400, Stephen Hutchinson wrote:
>> A number of new pix_fmts have been added to AviSynth+:
>> 16-bit packed RGB and RGBA
>> 10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
>> 8-, 10-, 12-, 14-, and 16-bit Planar RGB
>> 8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
>> 10-, 12-, 14-, and 16-bit GRAY variants*
>> 32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*
>>
>> *some of which are not currently available pix_fmts here and were
>>  not added to the demuxer due to this
>> ---
>>  libavformat/avisynth.c | 176
>> -
>>  1 file changed, 175 insertions(+), 1 deletion(-)
>
> breaks build
>
> libavformat/avisynth.c:100:40: error: ‘AVS_PLANAR_G’ undeclared here (not in
> a function)
> libavformat/avisynth.c:100:54: error: ‘AVS_PLANAR_B’ undeclared here (not in
> a function)
> libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in
> a function)
> libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in
> a function)
> libavformat/avisynth.c: In function ‘avisynth_read_packet_video’:
> libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named
> ‘avs_is_planar_rgb’
> libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named
> ‘avs_is_planar_rgba’
> make: *** [libavformat/avisynth.o] Error 1
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

[Roger Pack]

On 4/10/16, Michael Niedermayer  wrote:
> On Sun, Apr 10, 2016 at 07:29:05PM +0100, Rostislav Pehlivanov wrote:
>> On 10 April 2016 at 17:42, Michael Niedermayer 
>> wrote:
>>
>> > On Sun, Apr 10, 2016 at 04:38:35PM +0100, Kieran Kunhya wrote:
>> > > ---
>> > >  Changelog  |   1 +
>> > >  configure  |   6 --
>> > >  doc/encoders.texi  | 105 -
>> > >  doc/ffserver.conf  |   2 +-
>> > >  doc/general.texi   |   2 +-
>> > >  doc/muxers.texi|   4 +-
>> > >  doc/platform.texi  |   2 +-
>> > >  libavcodec/Makefile|   1 -
>> > >  libavcodec/allcodecs.c |   1 -
>> > >  libavcodec/libfaac.c   | 248
>> > -
>> > >  libavcodec/version.h   |   2 +-
>> > >  11 files changed, 7 insertions(+), 367 deletions(-)
>> > >  delete mode 100644 libavcodec/libfaac.c
>> >
>> > this is not possible currently libfaac is twice as fast than the
>> > native encoder.
>> >
>> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -c:a libfaac -y
>> > test.aac
>> > real0m2.828s
>> > user0m2.776s
>> > sys 0m0.048s
>> >
>> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -y test.aac
>> > real0m5.908s
>> > user0m5.856s
>> > sys 0m0.048s
>> >
>> >
>> >
>> FAAC isn't maintained, hasn't had any work done on it in who knows how
>> many
>> years, nobody but people who don't know that the native encoder/fdk is
>> better use it (just a few thankfully), isn't particularly stable
>> (segfaulted a few times when I was comparing it last year) and finally,
>> it's not good at all.
>> An argument that it's faster than the native encoder has as much weight
>> as
>> an argument that libaac_plus was also faster than the native encoder,
>> which
>> didn't matter as it was eventually removed
>> The age where we needed a few different AAC encoders because there wasn't
>> really a single good multipurpose one is gone now. The times have changed
>> since FAAC was developed (Nokia sponsored at lot of its development, and
>> you know what they used to make) and so have the computers. What was an
>> acceptable speed back then for encoding a file at a given quality isn't
>> necessarily the same now. And considering that fdk-aac can run as slow as
>> our encoder I'd say we're doing pretty well as far as the balance between
>> speed and quality goes.
>
> x264 can encode at really impressive speed and also at really
> impressive quality, its the users choice by using teh preset option
>
> for aac the user can choose speed through using the libfaac encoder
> or quality through using the native encoder
> speed matters for battery powered devices, not just for media servers
> on phones but also for plain audio recording on phones which i think
> is more common.

FWIW I once received a report that the old (now removed) vo-aacenc was
lightning fast.  Anybody have any speed/quality comparisons out there?
:)
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Compile using bash in Win10 anniversary?

[Roger Pack]

On 8/13/16, Timo Rothenpieler  wrote:
> On 8/12/2016 8:12 PM, Dan Haddix wrote:
>> Can you cross compile ffmpeg for Windows using the new bash built in to
>> Win10 anniversary? I'm currently using MinGW but it seems like it might be
>> easier to use the built in bash if possible. However I tried a basic
>> build, using the same commands I do in MinGW, and it fails. So I assume
>> there is something I need to do or setup to make it work, but I'm not sure
>> what as my knowledge of Linux is very limited. (I followed a guide to
>> setup MinGW)
>
> The bash for windows contains a full and native Ubuntu userland.
> So if you compile ffmpeg in there, you end up with an ELF binary for
> Linux, just as if you'd have compiled on an actual Ubuntu Linux.

Yeah, he mentioned cross compiling.  Anyway I have heard reports back
from users saying they have successfully used it for cross
compilation, FWIW (haven't tried it myself...).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Remove libfaac, the internal AAC encoder is better

[Paul B Mahol]

On 8/16/16, Roger Pack  wrote:
> On 4/10/16, Michael Niedermayer  wrote:
>> On Sun, Apr 10, 2016 at 07:29:05PM +0100, Rostislav Pehlivanov wrote:
>>> On 10 April 2016 at 17:42, Michael Niedermayer 
>>> wrote:
>>>
>>> > On Sun, Apr 10, 2016 at 04:38:35PM +0100, Kieran Kunhya wrote:
>>> > > ---
>>> > >  Changelog  |   1 +
>>> > >  configure  |   6 --
>>> > >  doc/encoders.texi  | 105 -
>>> > >  doc/ffserver.conf  |   2 +-
>>> > >  doc/general.texi   |   2 +-
>>> > >  doc/muxers.texi|   4 +-
>>> > >  doc/platform.texi  |   2 +-
>>> > >  libavcodec/Makefile|   1 -
>>> > >  libavcodec/allcodecs.c |   1 -
>>> > >  libavcodec/libfaac.c   | 248
>>> > -
>>> > >  libavcodec/version.h   |   2 +-
>>> > >  11 files changed, 7 insertions(+), 367 deletions(-)
>>> > >  delete mode 100644 libavcodec/libfaac.c
>>> >
>>> > this is not possible currently libfaac is twice as fast than the
>>> > native encoder.
>>> >
>>> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -c:a libfaac -y
>>> > test.aac
>>> > real0m2.828s
>>> > user0m2.776s
>>> > sys 0m0.048s
>>> >
>>> > time ./ffmpeg -v 0 -i matrixbench_mpeg2.mpg -vn -y test.aac
>>> > real0m5.908s
>>> > user0m5.856s
>>> > sys 0m0.048s
>>> >
>>> >
>>> >
>>> FAAC isn't maintained, hasn't had any work done on it in who knows how
>>> many
>>> years, nobody but people who don't know that the native encoder/fdk is
>>> better use it (just a few thankfully), isn't particularly stable
>>> (segfaulted a few times when I was comparing it last year) and finally,
>>> it's not good at all.
>>> An argument that it's faster than the native encoder has as much weight
>>> as
>>> an argument that libaac_plus was also faster than the native encoder,
>>> which
>>> didn't matter as it was eventually removed
>>> The age where we needed a few different AAC encoders because there wasn't
>>> really a single good multipurpose one is gone now. The times have changed
>>> since FAAC was developed (Nokia sponsored at lot of its development, and
>>> you know what they used to make) and so have the computers. What was an
>>> acceptable speed back then for encoding a file at a given quality isn't
>>> necessarily the same now. And considering that fdk-aac can run as slow as
>>> our encoder I'd say we're doing pretty well as far as the balance between
>>> speed and quality goes.
>>
>> x264 can encode at really impressive speed and also at really
>> impressive quality, its the users choice by using teh preset option
>>
>> for aac the user can choose speed through using the libfaac encoder
>> or quality through using the native encoder
>> speed matters for battery powered devices, not just for media servers
>> on phones but also for plain audio recording on phones which i think
>> is more common.
>
> FWIW I once received a report that the old (now removed) vo-aacenc was
> lightning fast.  Anybody have any speed/quality comparisons out there?

Yes, I. Its quality is useless.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] af_hdcd: Extract generic HDCD decoder, wrap for ffmpeg

[Michael Niedermayer]

On Tue, Aug 16, 2016 at 05:16:49AM -0500, Burt P wrote:
> af_hdcd.c began as an extended hdcd_decode.c from foo_hdcd, and
> recently the ffmpeg improvements were put back into a form that
> worked with foo_hdcd, but maintaining that sharing is cumbersome.
> 
> This patch moves the core HDCD decoder out of af_hdcd.c into
> hdcd_decode2.c. This is a generic version of the decoder that
> can be used in ffmpeg, foo_hdcd and whatever else. This way it is
> easier to share improvements to the decoder between projects.
> 
> af_hdcd.c is now an ffmpeg-specific wrapper to hdcd_decoder2.{h,c}.
> 
> Signed-off-by: Burt P 
> ---
>  libavfilter/Makefile   |1 +
>  libavfilter/af_hdcd.c  | 1674 
> 
>  libavfilter/hdcd_decode2.c | 1633 ++
>  libavfilter/hdcd_decode2.h |  204 ++

with -C this is a bit smaller though still large
not sure what is best for review

 libavfilter/Makefile  |1 +
 libavfilter/af_hdcd.c | 1674 ++---
 libavfilter/{af_hdcd.c => hdcd_decode2.c} |  958 +++--
 libavfilter/hdcd_decode2.h|  203 
 4 files changed, 724 insertions(+), 2112 deletions(-)
 copy libavfilter/{af_hdcd.c => hdcd_decode2.c} (86%)
 create mode 100644 libavfilter/hdcd_decode2.h

also
breaks fate

-- ./tests/ref/fate/source 2016-08-16 11:23:33.584756114 +0200
++ tests/data/fate/source  2016-08-16 15:51:48.601095192 +0200
@@ -26,3 +26,4 @@
 compat/avisynth/windowsPorts/windows2linux.h
 compat/float/float.h
 compat/float/limits.h
+libavfilter/hdcd_decode2.h
Test source failed. Look at tests/data/fate/source.err for details.
make: *** [fate-source] Error 1
make: *** Waiting for unfinished jobs

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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/6] lavf/vpp: Enable vpp filter, an Intel GPU accelerated scaler.

[Michael Niedermayer]

On Tue, Aug 16, 2016 at 05:10:03PM +0700, Nablet Developer wrote:
> From: ChaoX A Liu 
> 
> Signed-off-by: ChaoX A Liu 
> ---
>  configure |   3 +
>  libavcodec/qsv.c  |   2 +-
>  libavcodec/qsv_internal.h |   2 +-
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_vpp.c  | 863 
> ++
>  6 files changed, 870 insertions(+), 2 deletions(-)
>  create mode 100644 libavfilter/vf_vpp.c
> 
[...]
> diff --git a/libavfilter/vf_vpp.c b/libavfilter/vf_vpp.c
> new file mode 100644
> index 000..0cfeafc
> --- /dev/null
> +++ b/libavfilter/vf_vpp.c
> @@ -0,0 +1,863 @@
> +/*
> + * Intel MediaSDK Quick Sync Video VPP filter
> + *
> + * copyright (c) 2015 Sven Dueking
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *

> + * You should have received a copy of the GNU Lesser General Public
> + * License along with Libav; if not, write to the Free Software
 ^

We have to refer to the license included in FFmpeg


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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop issue

[Michael Niedermayer]

On Tue, Aug 16, 2016 at 11:45:52AM +0300, Ivan Uskov wrote:
> 
> Hello Jun,
> 
> Thursday, August 11, 2016, 10:59:51 AM, you wrote:
> 
> > From cafa70e97ce48b65e2a4a99782f6ce3557fef755 Mon Sep 17 00:00:00 2001
> > From: Jun Zhao 
> > Date: Thu, 11 Aug 2016 15:34:01 +0800
> > Subject: [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop
> >  issue.
> 
> > the merge commit 1b04ea1 "avconv: create simple filtergraphs earlier"
> > will init the filtergraphs earlier, then init the QSV transcode can't
> > suppose the nb_filters's value, else lead to the QSV transcode performance
> > drop.
> 
> > Signed-off-by: Jun Zhao 
> > ---
> >  ffmpeg_qsv.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> > diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
> > index 95a2351..acc54dd 100644
> > --- a/ffmpeg_qsv.c
> > +++ b/ffmpeg_qsv.c
> > @@ -210,8 +210,7 @@ int qsv_transcode_init(OutputStream *ost)
> >  
> >  /* check if the decoder supports QSV and the output only goes to this 
> > stream */
> >  ist = input_streams[ost->source_index];
> -if (ist->nb_filters || ist->hwaccel_id != HWACCEL_QSV ||
> -!ist->dec || !ist->dec->pix_fmts)
> +if (ist->hwaccel_id != HWACCEL_QSV || !ist->dec || !ist->dec->pix_fmts)
> >  return 0;
> >  for (pix_fmt = ist->dec->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE; 
> > pix_fmt++)
> >  if (*pix_fmt == AV_PIX_FMT_QSV)
> Thank, makes sense.
> LGTM.

applied

thanks

[...]
-- 
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 the people may require a leader. -- Plato


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

[FFmpeg-devel] [PATCH]lavf/udp: Do not use MCAST_* for multicast on tvOS

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5774.

Please comment, Carl Eugen
From 263e0b0f95bd20e557e53bee91d0a9488bf6a76e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 16 Aug 2016 17:51:03 +0200
Subject: [PATCH] lavf/udp: Do not use MCAST_* for multicast on tvOS.

Fixes ticket #5774.
---
 libavformat/udp.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 8699c1c..3835f98 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -42,6 +42,10 @@
 #include "os_support.h"
 #include "url.h"
 
+#ifdef __APPLE__
+#include "TargetConditionals.h"
+#endif
+
 #if HAVE_UDPLITE_H
 #include "udplite.h"
 #else
@@ -278,7 +282,7 @@ static int udp_set_multicast_sources(URLContext *h,
  int addr_len, char **sources,
  int nb_sources, int include)
 {
-#if HAVE_STRUCT_GROUP_SOURCE_REQ && defined(MCAST_BLOCK_SOURCE) && 
!defined(_WIN32)
+#if HAVE_STRUCT_GROUP_SOURCE_REQ && defined(MCAST_BLOCK_SOURCE) && 
!defined(_WIN32) && (!defined(TARGET_OS_TV) || !TARGET_OS_TV)
 /* These ones are available in the microsoft SDK, but don't seem to work
  * as on linux, so just prefer the v4-only approach there for now. */
 int i;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] avformat: Document thread-safety requirement for interrupt callback

[Marton Balint]

On Tue, 16 Aug 2016, Nicolas George wrote:


Le decadi 30 thermidor, an CCXXIV, sebechlebsky...@gmail.com a écrit :

From: Jan Sebechlebsky 

Muxing might be running in a separate thread if actual muxer is
run inside of fifo pseudo-muxer. Callback should be therefore
thread-safe.


This is an incompatible API change, and therefore not acceptable.



I think the idea was to document this limitation to the fifo muxer only.

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

Re: [FFmpeg-devel] [PATCH 3/4] v5 - SCTE-35 support in hlsenc

[Carlos Fernandez Sanz]

On Tue, Aug 16, 2016 at 6:39 AM, Michael Niedermayer
 wrote:
> On Mon, Aug 15, 2016 at 10:47:49AM -0700, Carlos Fernandez Sanz wrote:
>> From: Carlos Fernandez 
>
> seems to break build
>
> libavformat/scte_35.c: In function ‘ff_alloc_scte35_parser’:

Maybe some left overs from a previous version? The patches were
generated against yesterday's git and they merge cleanly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: Document thread-safety requirement for interrupt callback

[Nicolas George]

Le decadi 30 thermidor, an CCXXIV, Marton Balint a écrit :
> I think the idea was to document this limitation to the fifo muxer only.

That would be acceptable, although I still think it would be preferable to
avoid that requirement altogether.

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 2/2] avisynth: support pix_fmts added to AviSynth+

[Stephen Hutchinson]

On 8/16/2016 9:31 AM, Michael Niedermayer wrote:


breaks build

libavformat/avisynth.c:100:40: error: ‘AVS_PLANAR_G’ undeclared here (not in a 
function)
libavformat/avisynth.c:100:54: error: ‘AVS_PLANAR_B’ undeclared here (not in a 
function)
libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in a 
function)
libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in a 
function)
libavformat/avisynth.c: In function ‘avisynth_read_packet_video’:
libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgb’
libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgba’
make: *** [libavformat/avisynth.o] Error 1



That looks like the other patch updating compat/avisynth/avisynth_c.h 
wasn't applied first.

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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Davinder Singh]

On Tue, Aug 16, 2016 at 5:46 PM Michael Niedermayer 
wrote:

> [...]
>
> not sure i suggested it previously already but you can add yourself
> to the MAINTAINERs file if you want to maintain / continue working on
> the code after GSoC
>

i surely will.

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

Re: [FFmpeg-devel] [PATCH 2/2] avisynth: support pix_fmts added to AviSynth+

[Stephen Hutchinson]

On 8/16/2016 9:46 AM, Roger Pack wrote:

Does this require some version check in configure to be added as well?



No. We ship the header ourselves, rendering a version check in configure 
moot.  What configure checks for is the presence of the dynamic loading 
functionality that the library depends on.


The actual version compliancy checking occurs inside the AviSynth 
demuxer: version 2.5 is checked for at load time and rejected.  This 
patch adds a check for whether we're using AviSynth+ by detecting the 
presence of the planar RGB functions in the library, and if that's false 
(in other words, 2.6 is the one being used), it stops 2.6 from even 
attempting to use the two functions that it doesn't have.

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

Re: [FFmpeg-devel] [PATCH] avformat: Document thread-safety requirement for interrupt callback

[Jan Sebechlebsky]

On 08/16/2016 06:42 PM, Nicolas George wrote:


Le decadi 30 thermidor, an CCXXIV, Marton Balint a écrit :

I think the idea was to document this limitation to the fifo muxer only.

That would be acceptable, although I still think it would be preferable to
avoid that requirement altogether.

Regards,

Is it OK, if I leave the comment only in avformat.h in AVFormatContext 
and change it to

"Callback must be thread safe when fifo muxer is used"?

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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: implement floating point decoding

[Thilo Borgmann]

Am 12.08.16 um 14:27 schrieb Umair Khan:
> Hi,
> 
> On Mon, Aug 8, 2016 at 11:09 PM, Carl Eugen Hoyos  wrote:
>> 2016-08-08 19:10 GMT+02:00 Umair Khan :
>>> Attached the 3 separate patches.
>>
>> Which other codecs could use mlz decompression in the future?
>> Which other codecs could use IEEE 754 single floating point
>> soft float implementation in the future?
>>
>> I would suggest that there is one easy-to-understand new line
>> in the Changelog like "Floating point ALS decoding".
>>
> 
> Updated patches attached.

Ping. I'll push soon if there are no further complains.

-Thilo

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

Re: [FFmpeg-devel] [PATCH 2/2] avisynth: support pix_fmts added to AviSynth+

[Michael Niedermayer]

On Tue, Aug 16, 2016 at 12:57:53PM -0400, Stephen Hutchinson wrote:
> On 8/16/2016 9:31 AM, Michael Niedermayer wrote:
> >
> >breaks build
> >
> >libavformat/avisynth.c:100:40: error: ‘AVS_PLANAR_G’ undeclared here (not in 
> >a function)
> >libavformat/avisynth.c:100:54: error: ‘AVS_PLANAR_B’ undeclared here (not in 
> >a function)
> >libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in 
> >a function)
> >libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in 
> >a function)
> >libavformat/avisynth.c: In function ‘avisynth_read_packet_video’:
> >libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named 
> >‘avs_is_planar_rgb’
> >libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named 
> >‘avs_is_planar_rgba’
> >make: *** [libavformat/avisynth.o] Error 1
> >
> 
> That looks like the other patch updating
> compat/avisynth/avisynth_c.h wasn't applied first.

git log -2
commit 67f4e2cc041377cc5272a76ee1beaf73c3e49514
Author: Stephen Hutchinson 
Date:   Mon Aug 15 12:37:31 2016 -0400

avisynth: support pix_fmts added to AviSynth+

A number of new pix_fmts have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
10-, 12-, 14-, and 16-bit GRAY variants*
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*

*some of which are not currently available pix_fmts here and were
 not added to the demuxer due to this

Signed-off-by: Michael Niedermayer 

commit 220babe8078489065637b9b1bf2de013de7e6fd5
Author: Stephen Hutchinson 
Date:   Mon Aug 15 12:37:30 2016 -0400

compat/avisynth: update AviSynth+ header

Signed-off-by: Michael Niedermayer 

make distclean ; ./configure --enable-avisynth && make -j12

libavformat/avisynth.c:100:43: error: ‘AVS_PLANAR_G’ undeclared here (not in a 
function)
libavformat/avisynth.c:100:57: error: ‘AVS_PLANAR_B’ undeclared here (not in a 
function)
libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in a 
function)
libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in a 
function)
libavformat/avisynth.c: In function ‘avisynth_read_packet_video’:
libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgb’
libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgba’
make: *** [libavformat/avisynth.o] Error 1
make: *** Waiting for unfinished jobs


This works before the 2 patches

That is all on linux, straight compilation no cross build or anything

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

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


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

Re: [FFmpeg-devel] [PATCH 3/4] v5 - SCTE-35 support in hlsenc

[Michael Niedermayer]

On Tue, Aug 16, 2016 at 09:19:16AM -0700, Carlos Fernandez Sanz wrote:
> On Tue, Aug 16, 2016 at 6:39 AM, Michael Niedermayer
>  wrote:
> > On Mon, Aug 15, 2016 at 10:47:49AM -0700, Carlos Fernandez Sanz wrote:
> >> From: Carlos Fernandez 
> >
> > seems to break build
> >
> > libavformat/scte_35.c: In function ‘ff_alloc_scte35_parser’:
> 
> Maybe some left overs from a previous version? The patches were
> generated against yesterday's git and they merge cleanly.

in which patch is the function ?

git grep get_event_cache
libavformat/scte_35.c:iface->get_event_cache = get_event_cache;
libavformat/scte_35.h:struct scte_35_event* (*get_event_cache)(struct 
scte_35_interface *iface);



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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Mark Thompson]

On 16/08/16 03:44, Jun Zhao wrote:
> 
> 
> On 2016/8/16 10:14, Chao Liu wrote:
>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
>>
>>>
>>>
>>> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
 On 15 Aug, Hendrik Leppkes wrote :
>> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
>>> wrote:
 add libyami decoder/encoder/vpp in ffmpeg, about build step,
 please refer to the link: https://github.com/01org/
>>> ffmpeg_libyami/wiki/Build

>>
>> We've had patches for yami before, and they were not applied because
>> many developers did not agree with adding more wrappers for the same
>> hardware decoders which we already support.
>> Please refer to the discussion in this thread:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>>
>> The concerns and reasons brought up there should not really have
>>> changed.
 I still object very strongly against yami.

 It is a library that does not bring much that we could not do ourselves,
 it duplicates a lot of our code, it is the wrong level of abstraction
 for libavcodec, it is using a bad license and there is no guarantee of
 maintainership in the future.
>>>
>>> I know the worry after read the above thread.For Intel GPU HW accelerate
>>> decode/encode,
>>> now have 3 options in ffmpeg:
>>>
>>> 1. ffmpeg and QSV (Media SDK)
>>> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
>>> 3. ffmpeg and libyami
>>>
>> Sorry for this little diversion: what are the differences between QSV and
>> vaapi?
>> My understanding is that QSV has better performance, while vaapi supports
>> more decoders / encoders. Is that correct?
>> It would be nice if there are some data showing the speed of these HW
>> accelerated decoders / encoders.
> 
> QSV has better performance is right, but libyami have more decoders/encoders 
> than 
> vaapi hw accel decoder/encoder. :)
> 
> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and 
> native
> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and 
> native
> vaapi encoder

In a single ffmpeg process I believe that result, but I'm not sure that it's 
the question you really want to ask.

The lavc VAAPI hwaccel/encoder are both single-threaded, and while they overlap 
operations internally where possible the single-threadedness of ffmpeg (the 
program) itself means that they will not achieve the maximum performance.  If 
you really want to compare the single-transcode performance like this then you 
will want to make a test program which does the threading outside lavc.


In any case, I don't believe that the single generic transcode setup is a use 
that many people are interested in (beyond testing to observe that hardware 
encoders kindof suck relative to libx264, then using that instead).

To my mind, the cases where it is interesting to use VAAPI (or really any 
hardware encoder on a normal PC-like system) are:

* You want to do /lots/ of simultaneous transcodes in some sort of server setup 
(often with some simple transformation, like a scale or codec change), and want 
to maximise the number you can do while maintaining some minimum level of 
throughput on each one.  You can benchmark this case for VAAPI by running lots 
of instances of ffmpeg, and I expect that the libyami numbers will be precisely 
equivalent because libyami is using VAAPI anyway and the hardware is identical.

* You want to do other things with the surfaces on your GPU.  Here, using VAAPI 
directly is good because the DRM objects are easily exposed so you can move 
surfaces to and from whatever other stuff you want to use (OpenCL, DRI2 in X11, 
etc.).

* You want to minimise CPU/power use when doing one or a small number of live 
encodes/decodes (for example, video calling or screen recording).  Here 
performance is not really the issue - any of these solutions suffices but we 
should try to avoid it being too hard to use.

So, what do you think libyami brings to any of these cases?  I don't really see 
anything beyond the additional codec support* - have I missed something?

libyami also (I believe, correct me if I'm wrong) has Intel-specificity - this 
is significant given that mesa/gallium has very recently gained VAAPI encode 
support on AMD VCE (though I think it doesn't currently work well with lavc, 
I'm going to look into that soon).

I haven't done any detailed review of the patches; I'm happy to do so if people 
are generally in favour of having the library.

Thanks,

- Mark


* Which is fixable.  Wrt VP8, I wrote a bit of code but abandoned it because I 
don't know of anyone who actually cares about it.  Do you have some useful case 
for it?  If so, I'd be happy to implement it.  I am already intending to do VP9 
encode when I have hardware available; VP9 decode apparently already works 
though I don't have hardware myself.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Mark Thompson]

On 16/08/16 09:51, Jun Zhao wrote:
> 
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -vaapi_device 
> /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i 
> ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 
> 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 77 -level:v 40  -b 
> 4000k  output_vaapi_transcode.mp4
> ...
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
> output_vaapi_transcode.mp4 
> File size: 69.8 MiB
> ...
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -c:v libyami_h264 
> -i ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -c:v libyami_h264 
> output_yami_transcode.mp4 
> ...
> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
> output_yami_transcode.mp4 
> File size: 74.2 MiB

I'm assuming you are trying to show them with identical options?  Since the 
hardware is the same, you really should be able to get those two encodes to 
produce pretty much identical results.

Here I think the significant difference is probably that h264_vaapi is using 2 
B-frames by default, but there might be more subtle differences to remove as 
well.

- Mark

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

Re: [FFmpeg-devel] [PATCH 2/2] avisynth: support pix_fmts added to AviSynth+

[Stephen Hutchinson]

On 8/16/2016 2:00 PM, Michael Niedermayer wrote:

On Tue, Aug 16, 2016 at 12:57:53PM -0400, Stephen Hutchinson wrote:

On 8/16/2016 9:31 AM, Michael Niedermayer wrote:


breaks build

libavformat/avisynth.c:100:40: error: ‘AVS_PLANAR_G’ undeclared here (not in a 
function)
libavformat/avisynth.c:100:54: error: ‘AVS_PLANAR_B’ undeclared here (not in a 
function)
libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in a 
function)
libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in a 
function)
libavformat/avisynth.c: In function ‘avisynth_read_packet_video’:
libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgb’
libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgba’
make: *** [libavformat/avisynth.o] Error 1



That looks like the other patch updating
compat/avisynth/avisynth_c.h wasn't applied first.


git log -2
commit 67f4e2cc041377cc5272a76ee1beaf73c3e49514
Author: Stephen Hutchinson 
Date:   Mon Aug 15 12:37:31 2016 -0400

avisynth: support pix_fmts added to AviSynth+

A number of new pix_fmts have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
10-, 12-, 14-, and 16-bit GRAY variants*
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*

*some of which are not currently available pix_fmts here and were
 not added to the demuxer due to this

Signed-off-by: Michael Niedermayer 

commit 220babe8078489065637b9b1bf2de013de7e6fd5
Author: Stephen Hutchinson 
Date:   Mon Aug 15 12:37:30 2016 -0400

compat/avisynth: update AviSynth+ header

Signed-off-by: Michael Niedermayer 

make distclean ; ./configure --enable-avisynth && make -j12

libavformat/avisynth.c:100:43: error: ‘AVS_PLANAR_G’ undeclared here (not in a 
function)
libavformat/avisynth.c:100:57: error: ‘AVS_PLANAR_B’ undeclared here (not in a 
function)
libavformat/avisynth.c:101:43: error: ‘AVS_PLANAR_R’ undeclared here (not in a 
function)
libavformat/avisynth.c:103:57: error: ‘AVS_PLANAR_A’ undeclared here (not in a 
function)
libavformat/avisynth.c: In function ‘avisynth_read_packet_video’:
libavformat/avisynth.c:686:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgb’
libavformat/avisynth.c:687:36: error: ‘AviSynthLibrary’ has no member named 
‘avs_is_planar_rgba’
make: *** [libavformat/avisynth.o] Error 1
make: *** Waiting for unfinished jobs


This works before the 2 patches

That is all on linux, straight compilation no cross build or anything

[...]



Oh, right.  Yeah, I forgot about that.  There need to be ENABLE_AVISYNTH 
ifdefs around those because AvxSynth's header is the one that wasn't 
updated.


I'll fix it and send the patch again.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v10 01/11] avformat: Add fifo pseudo-muxer

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 Changes since the last version of the patch:
 - Added note in fifo muxer documentation in muxers.texi
   regarding thread-safety requirement for callbacks in AVFormatContext

 Changelog|   1 +
 configure|   1 +
 doc/muxers.texi  |  95 +++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/fifo.c   | 661 +++
 libavformat/version.h|   2 +-
 7 files changed, 761 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/fifo.c

diff --git a/Changelog b/Changelog
index b903e31..c693d34 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
 - True Audio (TTA) muxer
 - crystalizer audio filter
 - acrusher audio filter
+- fifo muxer
 
 
 version 3.1:
diff --git a/configure b/configure
index 9b92426..894e7a9 100755
--- a/configure
+++ b/configure
@@ -2834,6 +2834,7 @@ dv_muxer_select="dvprofile"
 dxa_demuxer_select="riffdec"
 eac3_demuxer_select="ac3_parser"
 f4v_muxer_select="mov_muxer"
+fifo_muxer_deps="pthreads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 5873269..0f36ddc 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1436,6 +1436,101 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)
 
 @end table
 
+@section fifo
+
+The fifo pseudo-muxer allows the separation of encoding and muxing by using
+first-in-first-out queue and running the actual muxer in a separate thread. 
This
+is especially useful in combination with the @ref{tee} muxer and can be used to
+send data to several destinations with different reliability/writing 
speed/latency.
+
+API users should be aware that callback functions (interrupt_callback,
+io_open and io_close) used within its AVFormatContext must be thread-safe.
+
+The behavior of the fifo muxer if the queue fills up or if the output fails is
+selectable,
+
+@itemize @bullet
+
+@item
+output can be transparently restarted with configurable delay between retries
+based on real time or time of the processed stream.
+
+@item
+encoding can be blocked during temporary failure, or continue transparently
+dropping packets in case fifo queue fills up.
+
+@end itemize
+
+@table @option
+
+@item fifo_format
+Specify the format name. Useful if it cannot be guessed from the
+output name suffix.
+
+@item queue_size
+Specify size of the queue (number of packets). Default value is 60.
+
+@item format_opts
+Specify format options for the underlying muxer. Muxer options can be specified
+as a list of @var{key}=@var{value} pairs separated by ':'.
+
+@item drop_pkts_on_overflow @var{bool}
+If set to 1 (true), in case the fifo queue fills up, packets will be dropped
+rather than blocking the encoder. This allows to continue streaming without
+delaying the input, at the cost of ommiting part of the stream. By default
+this option is set to 0 (false), so in such cases the encoder will be blocked
+until the muxer processes some of the packets and none of them is lost.
+
+@item attempt_recovery @var{bool}
+If failure occurs, attempt to recover the output. This is especially useful
+when used with network output, allows to restart streaming transparently.
+By default this option set to 0 (false).
+
+@item max_recovery_attempts
+Sets maximum number of successive unsucessful recovery attempts after which
+the output fails permanently. By default this option is set to 0 (unlimited).
+
+@item recovery_wait_time @var{duration}
+Waiting time before the next recovery attempt after previous unsuccessfull
+recovery attempt. Default value is 5 seconds.
+
+@item recovery_wait_streamtime @var{bool}
+If set to 0 (false), the real time is used when waiting for the recovery
+attempt (i.e. the recovery will be attempted after at least
+recovery_wait_time seconds).
+If set to 1 (true), the time of the processed stream is taken into account
+instead (i.e. the recovery will be attempted after at least 
@var{recovery_wait_time}
+seconds of the stream is omitted).
+By default, this option is set to 0 (false).
+
+@item recover_any_error @var{bool}
+If set to 1 (true), recovery will be attempted regardless of type of the error
+causing the failure. By default this option is set to 0 (false) and in case of
+certain (usually permanent) errors the recovery is not attempted even when
+@var{attempt_recovery} is set to 1.
+
+@item restart_with_keyframe @var{bool}
+Specify whether to wait for the keyframe after recovering from
+queue overflow or failure. This option is set to 0 (false) by default.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+Stream something to rtmp server, continue processing the stream at real-time
+rate even in case of temporary failure (network outage) and attempt to recover
+streaming every second indefinitely.
+@example
+ffmpeg -re -i ... -c:v libx264 -c:a aa

Re: [FFmpeg-devel] [PATCH 3/4] v5 - SCTE-35 support in hlsenc

[Carlos Fernandez Sanz]

On Tue, Aug 16, 2016 at 11:13 AM, Michael Niedermayer
 wrote:
>
> in which patch is the function ?

Apologies - looks like it's me who had some leftovers and didn't do a
proper clean before submitting.

I'll send a new patch set right away... just tested with current HEAD.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/4] v6 - Adding SCTE-35 CUI codec

[Carlos Fernandez Sanz]

From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavcodec/avcodec.h| 1 +
 libavcodec/codec_desc.c | 6 ++
 libavcodec/version.h| 2 +-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index b43ee5a..d564178 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/libavcodec/version.h b/libavcodec/version.h
index cdfc4f9..7ee5b5a 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  57
-#define LIBAVCODEC_VERSION_MINOR  53
+#define LIBAVCODEC_VERSION_MINOR  54
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 0/4] v6 - SCTE-35

[Carlos Fernandez Sanz]

* Patchset against current HEAD - v5 didn't build cleanly. Apologies.

Carlos Fernandez (4):
  Adding SCTE-35 CUI codec
  SCTE-35 extraction from mpegts
  SCTE-35 support in hlsenc
  Correct Indentation

 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   6 +
 libavcodec/version.h|   2 +-
 libavformat/Makefile|   2 +-
 libavformat/hlsenc.c| 115 ---
 libavformat/mpegts.c|  43 +++-
 libavformat/scte_35.c   | 525 
 libavformat/scte_35.h   |  86 
 8 files changed, 752 insertions(+), 28 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

[FFmpeg-devel] [PATCH 3/4] v6 - SCTE-35 support in hlsenc

[Carlos Fernandez Sanz]

From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavformat/Makefile  |   2 +-
 libavformat/hlsenc.c  | 107 --
 libavformat/scte_35.c | 525 ++
 libavformat/scte_35.h |  86 +
 4 files changed, 698 insertions(+), 22 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index fda1e17..7d47465 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 9f076ba..7c90157 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1,4 +1,4 @@
-/*
+ /*
  * Apple HTTP Live Streaming segmenter
  * Copyright (c) 2012, Luca Barbato
  *
@@ -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,8 @@ typedef struct HLSContext {
 int nb_entries;
 int discontinuity_set;
 
+int adv_count;
+struct scte_35_interface *scte_iface;
 HLSSegment *segments;
 HLSSegment *last_segment;
 HLSSegment *old_segments;
@@ -203,6 +212,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
 av_freep(&path);
 previous_segment = segment;
 segment = previous_segment->next;
+if (hls->scte_iface)
+hls->scte_iface->unref_scte35_event(&previous_segment->event);
 av_free(previous_segment);
 }
 
@@ -314,8 +325,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;
@@ -351,9 +362,23 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 
 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_state == EVENT_OUT_CONT) {
+en->adv_count = hls->adv_count;;
+hls->adv_count++;
+en->out = hls->scte_iface->event_state;
+} else {
+hls->adv_count = 0;
+en->out = hls->scte_iface->event_state;
+}
+}
+
+
 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 +500,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 = hls->scte_iface->get_hls_string(hls->scte_iface, 
en->event, fname, en->out, -1, e

[FFmpeg-devel] [PATCH 2/4] v6 - SCTE-35 extraction from mpegts

[Carlos Fernandez Sanz]

From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavformat/mpegts.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b31d233..4185af0 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(&pes->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,7 +2349,14 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 }
 }
 }
-
+} 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 {
 int ret;
 // Note: The position here points actually behind the current packet.
@@ -2730,6 +2769,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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] v6 - Correct Indentation

[Carlos Fernandez Sanz]

From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavformat/hlsenc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7c90157..a73c50d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -360,12 +360,12 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 else
 en->sub_filename[0] = '\0';
 
-en->duration = duration;
-en->pos  = pos;
-en->event= event;
-en->size = size;
+en->duration   = duration;
+en->pos= pos;
+en->event  = event;
+en->size   = size;
 en->start_pts  = start_pts;
-en->next = NULL;
+en->next   = NULL;
 
 if (hls->scte_iface) {
 if (hls->scte_iface->event_state == EVENT_OUT_CONT) {
-- 
2.7.4

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

[FFmpeg-devel] [PATCH v2] doc/APIchanges: Document addition of list BSF API in lavc

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 I've noticed that conflicting patch was applied meanwhile, so I'm resending 
this.
 Please apply :)

 doc/APIchanges | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/APIchanges b/doc/APIchanges
index 74145b2..582563a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -19,6 +19,13 @@ API changes, most recent first:
   Add trailing_padding to AVCodecContext to match the corresponding
   field in AVCodecParameters.
 
+2016-08-15 - b746ed7 - lavc 57.52.100 - avcodec.h
+  Add a new API for chained BSF filters and passthrough (null) BSF --
+  av_bsf_list_alloc(), av_bsf_list_free(), av_bsf_list_append(),
+  av_bsf_list_append2(), av_bsf_list_finalize(), av_bsf_list_parse_str()
+  and av_bsf_get_null_filter().
+
+
 2016-08-04 - xxx - lavf 57.46.100 - avformat.h
   Add av_get_frame_filename2()
 
-- 
1.9.1

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

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

[Moritz Barsnick]

On Tue, Aug 16, 2016 at 09:45:49 +0200, Paul B Mahol wrote:

> +Show & measure bit plane noise.

'&' seems a bit casual instead of "and". In several places.

It would perhaps be valuable to document how it's measured, and how
it's shown. (Is it really shown? Is the measured value not inserted
into metadata? If so, that might need to be said.)

+@item bitplane
+Set which plane to analyze & filter.
+@end table

Default: plane 1.

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

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

[Paul B Mahol]

On Tuesday, August 16, 2016, Moritz Barsnick  wrote:

> On Tue, Aug 16, 2016 at 09:45:49 +0200, Paul B Mahol wrote:
>
> > +Show & measure bit plane noise.
>
> '&' seems a bit casual instead of "and". In several places.
>
> It would perhaps be valuable to document how it's measured, and how
> it's shown. (Is it really shown? Is the measured value not inserted
> into metadata? If so, that might need to be said.)


Yes it is shown and is measured and metadata is stored in frame, for more
info use google.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avisynth: support pix_fmts added to AviSynth+

[Stephen Hutchinson]

A number of new pix_fmts have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
10-, 12-, 14-, and 16-bit GRAY variants*
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*

*some of which are not currently available pix_fmts here and were
 not added to the demuxer due to this
---
 libavformat/avisynth.c | 183 -
 1 file changed, 182 insertions(+), 1 deletion(-)

diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 04ac257..1fe8e08 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -68,6 +68,8 @@ typedef struct AviSynthLibrary {
 AVSC_DECLARE_FUNC(avs_get_pitch_p);
 AVSC_DECLARE_FUNC(avs_get_read_ptr_p);
 AVSC_DECLARE_FUNC(avs_get_row_size_p);
+AVSC_DECLARE_FUNC(avs_is_planar_rgb);
+AVSC_DECLARE_FUNC(avs_is_planar_rgba);
 #endif
 #undef AVSC_DECLARE_FUNC
 } AviSynthLibrary;
@@ -95,6 +97,14 @@ static const int avs_planes_packed[1] = { 0 };
 static const int avs_planes_grey[1]   = { AVS_PLANAR_Y };
 static const int avs_planes_yuv[3]= { AVS_PLANAR_Y, AVS_PLANAR_U,
   AVS_PLANAR_V };
+#ifdef USING_AVISYNTH
+static const int avs_planes_rgb[3]= { AVS_PLANAR_G, AVS_PLANAR_B,
+  AVS_PLANAR_R };
+static const int avs_planes_yuva[4]   = { AVS_PLANAR_Y, AVS_PLANAR_U,
+  AVS_PLANAR_V, AVS_PLANAR_A };
+static const int avs_planes_rgba[4]   = { AVS_PLANAR_G, AVS_PLANAR_B,
+  AVS_PLANAR_R, AVS_PLANAR_A };
+#endif
 
 /* A conflict between C++ global objects, atexit, and dynamic loading requires
  * us to register our own atexit handler to prevent double freeing. */
@@ -138,6 +148,8 @@ static av_cold int avisynth_load_library(void)
 LOAD_AVS_FUNC(avs_get_pitch_p, 1);
 LOAD_AVS_FUNC(avs_get_read_ptr_p, 1);
 LOAD_AVS_FUNC(avs_get_row_size_p, 1);
+LOAD_AVS_FUNC(avs_is_planar_rgb, 1);
+LOAD_AVS_FUNC(avs_is_planar_rgba, 1);
 #endif
 #undef LOAD_AVS_FUNC
 
@@ -222,7 +234,7 @@ static av_cold void avisynth_atexit_handler(void)
 static int avisynth_create_stream_video(AVFormatContext *s, AVStream *st)
 {
 AviSynthContext *avs = s->priv_data;
-int planar = 0; // 0: packed, 1: YUV, 2: Y8
+int planar = 0; // 0: packed, 1: YUV, 2: Y8, 3: Planar RGB, 4: YUVA, 5: 
Planar RGBA
 
 st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
 st->codecpar->codec_id   = AV_CODEC_ID_RAWVIDEO;
@@ -238,6 +250,136 @@ static int avisynth_create_stream_video(AVFormatContext 
*s, AVStream *st)
 
 switch (avs->vi->pixel_type) {
 #ifdef USING_AVISYNTH
+/* 10~16-bit YUV pix_fmts (AviSynth+) */
+case AVS_CS_YUV444P10:
+st->codecpar->format = AV_PIX_FMT_YUV444P10;
+planar   = 1;
+break;
+case AVS_CS_YUV422P10:
+st->codecpar->format = AV_PIX_FMT_YUV422P10;
+planar   = 1;
+break;
+case AVS_CS_YUV420P10:
+st->codecpar->format = AV_PIX_FMT_YUV420P10;
+planar   = 1;
+break;
+case AVS_CS_YUV444P12:
+st->codecpar->format = AV_PIX_FMT_YUV444P12;
+planar   = 1;
+break;
+case AVS_CS_YUV422P12:
+st->codecpar->format = AV_PIX_FMT_YUV422P12;
+planar   = 1;
+break;
+case AVS_CS_YUV420P12:
+st->codecpar->format = AV_PIX_FMT_YUV420P12;
+planar   = 1;
+break;
+case AVS_CS_YUV444P14:
+st->codecpar->format = AV_PIX_FMT_YUV444P14;
+planar   = 1;
+break;
+case AVS_CS_YUV422P14:
+st->codecpar->format = AV_PIX_FMT_YUV422P14;
+planar   = 1;
+break;
+case AVS_CS_YUV420P14:
+st->codecpar->format = AV_PIX_FMT_YUV420P14;
+planar   = 1;
+break;
+case AVS_CS_YUV444P16:
+st->codecpar->format = AV_PIX_FMT_YUV444P16;
+planar   = 1;
+break;
+case AVS_CS_YUV422P16:
+st->codecpar->format = AV_PIX_FMT_YUV422P16;
+planar   = 1;
+break;
+case AVS_CS_YUV420P16:
+st->codecpar->format = AV_PIX_FMT_YUV420P16;
+planar   = 1;
+break;
+/* 8~16-bit YUV pix_fmts with Alpha (AviSynth+) */
+case AVS_CS_YUVA444:
+st->codecpar->format = AV_PIX_FMT_YUVA444P;
+planar   = 4;
+break;
+case AVS_CS_YUVA422:
+st->codecpar->format = AV_PIX_FMT_YUVA422P;
+planar   = 4;
+break;
+case AVS_CS_YUVA420:
+st->codecpar->format = AV_PIX_FMT_YUVA420P;
+planar   = 4;
+break;
+case AVS_CS_YUVA444P10:
+st->codecpar->format = AV_PIX_FMT_YUVA444P10;
+planar 

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Jun Zhao]

On 2016/8/17 2:33, Mark Thompson wrote:
> On 16/08/16 09:51, Jun Zhao wrote:
>>
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -vaapi_device 
>> /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i 
>> ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -an -vf 
>> 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 77 -level:v 40  -b 
>> 4000k  output_vaapi_transcode.mp4
>> ...
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
>> output_vaapi_transcode.mp4 
>> File size: 69.8 MiB
>> ...
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ ./ffmpeg -y -c:v 
>> libyami_h264 -i ../ffmpeg_yami_testcase/skyfall2-trailer.mp4 -c:v 
>> libyami_h264 output_yami_transcode.mp4 
>> ...
>> barry@barry:~/Source/video/yami/ffmpeg_libyami$ mediainfo 
>> output_yami_transcode.mp4 
>> File size: 74.2 MiB
> 
> I'm assuming you are trying to show them with identical options?  Since the 
> hardware is the same, you really should be able to get those two encodes to 
> produce pretty much identical results.
> 
> Here I think the significant difference is probably that h264_vaapi is using 
> 2 B-frames by default, but there might be more subtle differences to remove 
> as well.
> 
> - Mark

Hi, Mark:

I just used this show how to run ffmpeg/vaapi and ffmpeg/libyami :)

For the performance gap, I think the root cause is that ffmpeg/vaapi transcode 
use VPP in the pipeline, but ffmpeg/libyami transcode without VPP.

I will double-check this case.



> 
> ___
> 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 1/5] lavc : yami : add libyami decoder/encoder

[Jun Zhao]

On 2016/8/17 2:27, Mark Thompson wrote:
> On 16/08/16 03:44, Jun Zhao wrote:
>>
>>
>> On 2016/8/16 10:14, Chao Liu wrote:
>>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
>>>


 On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> On 15 Aug, Hendrik Leppkes wrote :
>>> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
 wrote:
> add libyami decoder/encoder/vpp in ffmpeg, about build step,
> please refer to the link: https://github.com/01org/
 ffmpeg_libyami/wiki/Build
>
>>>
>>> We've had patches for yami before, and they were not applied because
>>> many developers did not agree with adding more wrappers for the same
>>> hardware decoders which we already support.
>>> Please refer to the discussion in this thread:
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
>>>
>>> The concerns and reasons brought up there should not really have
 changed.
> I still object very strongly against yami.
>
> It is a library that does not bring much that we could not do ourselves,
> it duplicates a lot of our code, it is the wrong level of abstraction
> for libavcodec, it is using a bad license and there is no guarantee of
> maintainership in the future.

 I know the worry after read the above thread.For Intel GPU HW accelerate
 decode/encode,
 now have 3 options in ffmpeg:

 1. ffmpeg and QSV (Media SDK)
 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
 3. ffmpeg and libyami

>>> Sorry for this little diversion: what are the differences between QSV and
>>> vaapi?
>>> My understanding is that QSV has better performance, while vaapi supports
>>> more decoders / encoders. Is that correct?
>>> It would be nice if there are some data showing the speed of these HW
>>> accelerated decoders / encoders.
>>
>> QSV has better performance is right, but libyami have more decoders/encoders 
>> than 
>> vaapi hw accel decoder/encoder. :)
>>
>> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder and 
>> native
>> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and 
>> native
>> vaapi encoder
> 
> In a single ffmpeg process I believe that result, but I'm not sure that it's 
> the question you really want to ask.
> 
> The lavc VAAPI hwaccel/encoder are both single-threaded, and while they 
> overlap operations internally where possible the single-threadedness of 
> ffmpeg (the program) itself means that they will not achieve the maximum 
> performance.  If you really want to compare the single-transcode performance 
> like this then you will want to make a test program which does the threading 
> outside lavc.

I agree with you :), now I use thread in ffmpeg/yami encoder/decoder, and
 QSV (Media SDK) use the thread in the library, in this respect, compare the
one way (1 input/1 output)transcode speed is unfair to ffmpeg/vaapi.

> 
> In any case, I don't believe that the single generic transcode setup is a use 
> that many people are interested in (beyond testing to observe that hardware 
> encoders kindof suck relative to libx264, then using that instead).
> 
> To my mind, the cases where it is interesting to use VAAPI (or really any 
> hardware encoder on a normal PC-like system) are:
> 
> * You want to do /lots/ of simultaneous transcodes in some sort of server 
> setup (often with some simple transformation, like a scale or codec change), 
> and want to maximise the number you can do while maintaining some minimum 
> level of throughput on each one.  You can benchmark this case for VAAPI by 
> running lots of instances of ffmpeg, and I expect that the libyami numbers 
> will be precisely equivalent because libyami is using VAAPI anyway and the 
> hardware is identical.
> 
> * You want to do other things with the surfaces on your GPU.  Here, using 
> VAAPI directly is good because the DRM objects are easily exposed so you can 
> move surfaces to and from whatever other stuff you want to use (OpenCL, DRI2 
> in X11, etc.).
> 
> * You want to minimise CPU/power use when doing one or a small number of live 
> encodes/decodes (for example, video calling or screen recording).  Here 
> performance is not really the issue - any of these solutions suffices but we 
> should try to avoid it being too hard to use.
> 
> So, what do you think libyami brings to any of these cases?  I don't really 
> see anything beyond the additional codec support* - have I missed something?

vpp missing some features, e,g de-noise/de-interlance/...,but I think fill the 
gap is not difficulty, I hope I can submit some patch for this. :)

> 
> libyami also (I believe, correct me if I'm wrong) has Intel-specificity - 
> this is significant given that mesa/gallium has very recently gained VAAPI 
> encode support on AMD VCE (though I think it doesn't currently work well with 
> lavc, I'm going to look into that soon).
> 
> I haven't done any detailed review of 

Re: [FFmpeg-devel] [PATCH v2] doc/APIchanges: Document addition of list BSF API in lavc

[James Almer]

On 8/16/2016 5:14 PM, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky 
> 
> Signed-off-by: Jan Sebechlebsky 
> ---
>  I've noticed that conflicting patch was applied meanwhile, so I'm resending 
> this.
>  Please apply :)

Applied.

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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Tue, Aug 16, 2016 at 1:06 AM, Jun Zhao  wrote:

>
>
> On 2016/8/16 15:37, Chao Liu wrote:
> > On Mon, Aug 15, 2016 at 7:44 PM, Jun Zhao  wrote:
> >
> >>
> >>
> >> On 2016/8/16 10:14, Chao Liu wrote:
> >>> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >>>
> 
> 
>  On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
> > On 15 Aug, Hendrik Leppkes wrote :
> >>> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
>  wrote:
> > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> > please refer to the link: https://github.com/01org/
>  ffmpeg_libyami/wiki/Build
> >
> >>>
> >>> We've had patches for yami before, and they were not applied
> because
> >>> many developers did not agree with adding more wrappers for the
> same
> >>> hardware decoders which we already support.
> >>> Please refer to the discussion in this thread:
> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >>>
> >>> The concerns and reasons brought up there should not really have
>  changed.
> > I still object very strongly against yami.
> >
> > It is a library that does not bring much that we could not do
> >> ourselves,
> > it duplicates a lot of our code, it is the wrong level of abstraction
> > for libavcodec, it is using a bad license and there is no guarantee
> of
> > maintainership in the future.
> 
>  I know the worry after read the above thread.For Intel GPU HW
> accelerate
>  decode/encode,
>  now have 3 options in ffmpeg:
> 
>  1. ffmpeg and QSV (Media SDK)
>  2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
>  3. ffmpeg and libyami
> 
> >>> Sorry for this little diversion: what are the differences between QSV
> and
> >>> vaapi?
> >>> My understanding is that QSV has better performance, while vaapi
> supports
> >>> more decoders / encoders. Is that correct?
> >>> It would be nice if there are some data showing the speed of these HW
> >>> accelerated decoders / encoders.
> >>
> >> QSV has better performance is right, but libyami have more
> >> decoders/encoders than
> >> vaapi hw accel decoder/encoder. :)
> >>
> >> According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and
> >> native
> >> vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> >> native
> >> vaapi encoder
> >>
> >>>
> 
>  And I know the guys prefer option 2 than 3, but I have a little
> >> question,
>  what's the
>  difference about ffmpeg/libyami and the other external codec
> library(e,g
>  openh264,
>  videotoolbox...)?
> 
> >>> Is 2 available in ffmpeg today or is it sth. planned?
> >>>
> >>
> >> Option 2 is available today :), I think the wiki page (
> >> https://wiki.libav.org/Hardware/vaapi)
> >> is good refer to for option 2, if you want to try. :)
> >
> > Thanks. But that's for libav. These decoders and encoders are not
> available
> > for ffmpeg.
> >
>
> I can run ffmpeg vaapi hw accel decoder and vaapi encoder with zero-copy
> mode for
> transcode case, I don't know why you can't succeed.
>
> Do you re-build intel-driver/libva with master branch?
>
Right. I am using an old version. There is an h264_vaapi encoder in the
latest release.

> ___
> 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] examples/demuxing_decoding: convert to codecpar

[James Almer]

On 8/10/2016 1:20 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  doc/examples/demuxing_decoding.c | 33 ++---
>  1 file changed, 22 insertions(+), 11 deletions(-)

I'll be pushing this soon unless someone objects.

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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Tue, Aug 16, 2016 at 11:27 AM, Mark Thompson  wrote:

> On 16/08/16 03:44, Jun Zhao wrote:
> >
> >
> > On 2016/8/16 10:14, Chao Liu wrote:
> >> On Mon, Aug 15, 2016 at 6:00 PM, Jun Zhao  wrote:
> >>
> >>>
> >>>
> >>> On 2016/8/16 1:48, Jean-Baptiste Kempf wrote:
>  On 15 Aug, Hendrik Leppkes wrote :
> >> On Mon, Aug 15, 2016 at 10:22 AM, Jun Zhao 
> >>> wrote:
>  add libyami decoder/encoder/vpp in ffmpeg, about build step,
>  please refer to the link: https://github.com/01org/
> >>> ffmpeg_libyami/wiki/Build
> 
> >>
> >> We've had patches for yami before, and they were not applied because
> >> many developers did not agree with adding more wrappers for the same
> >> hardware decoders which we already support.
> >> Please refer to the discussion in this thread:
> >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167388.html
> >>
> >> The concerns and reasons brought up there should not really have
> >>> changed.
>  I still object very strongly against yami.
> 
>  It is a library that does not bring much that we could not do
> ourselves,
>  it duplicates a lot of our code, it is the wrong level of abstraction
>  for libavcodec, it is using a bad license and there is no guarantee of
>  maintainership in the future.
> >>>
> >>> I know the worry after read the above thread.For Intel GPU HW
> accelerate
> >>> decode/encode,
> >>> now have 3 options in ffmpeg:
> >>>
> >>> 1. ffmpeg and QSV (Media SDK)
> >>> 2. ffmpeg vaapi hw accelerate decoder/native vaapi encoder
> >>> 3. ffmpeg and libyami
> >>>
> >> Sorry for this little diversion: what are the differences between QSV
> and
> >> vaapi?
> >> My understanding is that QSV has better performance, while vaapi
> supports
> >> more decoders / encoders. Is that correct?
> >> It would be nice if there are some data showing the speed of these HW
> >> accelerated decoders / encoders.
> >
> > QSV has better performance is right, but libyami have more
> decoders/encoders than
> > vaapi hw accel decoder/encoder. :)
> >
> > According our profile, the speed of QSV/Libyami/vaapi-hw accel decoder
> and native
> > vaapi encoder are: QSV > ffmpeg and libyami > vaapi-hw accel decoder and
> native
> > vaapi encoder
>
> In a single ffmpeg process I believe that result, but I'm not sure that
> it's the question you really want to ask.
>
> The lavc VAAPI hwaccel/encoder are both single-threaded, and while they
> overlap operations internally where possible the single-threadedness of
> ffmpeg (the program) itself means that they will not achieve the maximum
> performance.  If you really want to compare the single-transcode
> performance like this then you will want to make a test program which does
> the threading outside lavc.
>
>
> In any case, I don't believe that the single generic transcode setup is a
> use that many people are interested in (beyond testing to observe that
> hardware encoders kindof suck relative to libx264, then using that instead).
>
> To my mind, the cases where it is interesting to use VAAPI (or really any
> hardware encoder on a normal PC-like system) are:
>
> * You want to do /lots/ of simultaneous transcodes in some sort of server
> setup (often with some simple transformation, like a scale or codec
> change), and want to maximise the number you can do while maintaining some
> minimum level of throughput on each one.  You can benchmark this case for
> VAAPI by running lots of instances of ffmpeg, and I expect that the libyami
> numbers will be precisely equivalent because libyami is using VAAPI anyway
> and the hardware is identical.
>
Our use case is similar to this one. In one process, we have multiple
threads that decode the input video streams, process the decoded frames and
encode.
To process the frames efficiently, we would like the decoded frames to be
of some format like yuv420p, which has a separate luminance channel.
We would like to use whatever hardware accelerations that are available. So
far, we have only tried QSV. It works, with some problems though, like no
support for VP8, only available for relatively new intel CPUs.
I just took a look at vaapi hwaccel, curious why its pix format has to
be AV_PIX_FMT_VAAPI? Jun's patch does support other pix format like yuv420p.

>
> * You want to do other things with the surfaces on your GPU.  Here, using
> VAAPI directly is good because the DRM objects are easily exposed so you
> can move surfaces to and from whatever other stuff you want to use (OpenCL,
> DRI2 in X11, etc.).
>
> * You want to minimise CPU/power use when doing one or a small number of
> live encodes/decodes (for example, video calling or screen recording).
> Here performance is not really the issue - any of these solutions suffices
> but we should try to avoid it being too hard to use.
>
> So, what do you think libyami brings to any of these cases?  I don't
> really see anything beyond the additional codec support* - have I missed
> somet

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: add UID for unconstrained H.264 coded video in baseline profile

[Carl Eugen Hoyos]

Hi!

2016-08-15 21:45 GMT+02:00 Matthias Hunstock :
> how can I access the sample file of https://trac.ffmpeg.org/ticket/5068 ?

I don't think I have it.

Sorry, Carl Eugen
___
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.

[Steven Robertson]

Yes, thank you. I'll resend this.

On Wed, Aug 3, 2016 at 2:01 PM, Mark Reid  wrote:

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

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

[Steven Robertson]

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..60bfd34 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 yuv422p12le
 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..eb57167
--- /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,  8294400, 0x31bfa8f1
-- 
2.8.0.rc2

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