Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Tom Butterworth]

Hey Martin

> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> +avctx->pix_fmt = AV_PIX_FMT_RGB0;

The rgtc1u_block function places the single channel value in every channel 
except the alpha channel
The pixel format you have chosen is one which disregards the alpha channel

The output of this alpha-only decoder should be in the alpha channel of a pixel 
format which carries alpha. Probably other channels should have zero values.

> On 23 Sep 2017, at 20:52, Martin Vignali  wrote:
> 
> Sorry, i made a mistake in the previous patchs
> 
> Correct patchs in attach
> 
> Martin
> <0001-libavformat-add-mov-dataformat-tag-for-HapAlphaOnly-.patch><0002-libavcodec-hapdec-add-support-HapAlphaOnly.patch>___
> 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] cross compile on Ubuntu for Arm with --enable-omx meet "ERROR: OpenMAX IL headers not found"

[chang jc]

Dear all:

I meet the problem "ERROR: OpenMAX IL headers not found" when I cross
compile ffmpeg for Arm on Ubuntu  with --enable-omx.

How could I resolve this problem?

I guess there should be something missed.

Thanks in advance!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale_unscaled: fix DITHER_COPY macro, use it only for dst_depth == 8

[Mateusz]

W dniu 2017-09-26 o 13:31, Carl Eugen Hoyos pisze:
> 2017-09-26 1:33 GMT+02:00 Mateusz :
> 
>> I've sent C code patch 2017-09-06 (and nothing) so I thought that the
>> problem is with speed. For simplicity I've attached this patch.
> 
> You could (wait a day or two and) either add an option to
> select your dithering code or put it under #ifdef so more
> people can test it.

I've attached patch that do nothing unless you specify
--extra-cflags="-DNEW_DITHER_COPY" or export CFLAGS="-DNEW_DITHER_COPY"

>> In theory it is enough to make only dst = (src + dither)>>shift;
>> -- white in limited range has 0 on bits to remove (235*4 for example)
>> so overflow is impossible. For files with full range not marked as
>> full range overflow is possible (for dither > 0) and white goes
>> to black. tmp - (tmp>>dst_depth) undoing this overflow.
> 
> (Not necessarily related, sorry if I misunderstand:)
> Valid limited-range frames can contain some pixels with peak
> values outside of the defined range.
> 
> Carl Eugen

OK, so this fight with possible overflow is even more needed.

Mateusz
From 2c0adb2d9a0fc0fbbffc643d27860fbb779c08fc Mon Sep 17 00:00:00 2001
From: Mateusz 
Date: Tue, 26 Sep 2017 22:20:10 +0200
Subject: [PATCH] swscale: new precise DITHER_COPY macro (if
 "-DNEW_DITHER_COPY" CFLAGS)

---
 libswscale/swscale_unscaled.c | 47 ++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index ef36aec..0d41695 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -110,6 +110,7 @@ DECLARE_ALIGNED(8, static const uint8_t, dithers)[8][8][8]={
   { 112, 16,104,  8,118, 22,110, 14,},
 }};
 
+#ifndef NEW_DITHER_COPY
 static const uint16_t dither_scale[15][16]={
 {2,3,3,5,5,5,5,5,5,5,5,5,
5,5,5,5,},
 {2,3,7,7,   13,   13,   25,   25,   25,   25,   25,   25,   
25,   25,   25,   25,},
@@ -127,7 +128,7 @@ static const uint16_t dither_scale[15][16]={
 {3,5,7,9,   10,   12,   14,   14,   14,   14,   14,   14,   
14,   15,32767,32767,},
 {3,5,7,9,   11,   12,   14,   15,   15,   15,   15,   15,   
15,   15,   16,65535,},
 };
-
+#endif
 
 static void fillPlane(uint8_t *plane, int stride, int width, int height, int y,
   uint8_t val)
@@ -1501,6 +1502,7 @@ static int packedCopyWrapper(SwsContext *c, const uint8_t 
*src[],
 return srcSliceH;
 }
 
+#ifndef NEW_DITHER_COPY
 #define DITHER_COPY(dst, dstStride, src, srcStride, bswap, dbswap)\
 uint16_t scale= dither_scale[dst_depth-1][src_depth-1];\
 int shift= src_depth-dst_depth + dither_scale[src_depth-2][dst_depth-1];\
@@ -1521,6 +1523,49 @@ static int packedCopyWrapper(SwsContext *c, const 
uint8_t *src[],
 dst += dstStride;\
 src += srcStride;\
 }
+#else
+#define DITHER_COPY(dst, dstStride, src, srcStride, bswap, dbswap)\
+unsigned shift= src_depth-dst_depth, tmp;\
+if (shiftonly) {\
+for (i = 0; i < height; i++) {\
+const uint8_t *dither= dithers[shift-1][i&7];\
+for (j = 0; j < length-7; j+=8){\
+tmp = (bswap(src[j+0]) + dither[0])>>shift; dst[j+0] = 
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+1]) + dither[1])>>shift; dst[j+1] = 
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+2]) + dither[2])>>shift; dst[j+2] = 
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+3]) + dither[3])>>shift; dst[j+3] = 
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+4]) + dither[4])>>shift; dst[j+4] = 
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+5]) + dither[5])>>shift; dst[j+5] = 
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+6]) + dither[6])>>shift; dst[j+6] = 
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+7]) + dither[7])>>shift; dst[j+7] = 
dbswap(tmp - (tmp>>dst_depth));\
+}\
+for (; j < length; j++){\
+tmp = (bswap(src[j]) + dither[j&7])>>shift; dst[j] = 
dbswap(tmp - (tmp>>dst_depth));\
+}\
+dst += dstStride;\
+src += srcStride;\
+}\
+} else {\
+for (i = 0; i < height; i++) {\
+const uint8_t *dither= dithers[shift-1][i&7];\
+for (j = 0; j < length-7; j+=8){\
+tmp = bswap(src[j+0]); dst[j+0] = dbswap((tmp - 
(tmp>>dst_depth) + dither[0])>>shift);\
+tmp = bswap(src[j+1]); dst[j+1] = dbswap((tmp - 
(tmp>>dst_depth) + dither[1])>>shift);\
+tmp = bswap(src[j+2]); dst[j+2] = dbswap((tmp - 
(tmp>>dst_depth) + dither[2])>>shift);\
+tmp = bswap(src[j+3]); dst[j+3] = dbswap((tmp - 
(tmp>>dst_depth) + dither[3])>>shift);\
+tmp = bswap(src[j+4]); dst[j+4] = dbswap((tmp - 
(tmp>>dst_depth) + dither[

Re: [FFmpeg-devel] libavcodec/hapenc : add support for hap alpha only encoding

[Tom Butterworth]

Yo

> Patch 1 : 0004-libavcodec-texturedspenc-add-rgtc1u-encoding

> +/**
> + * Compress one block of RGBA pixels in a RGTC1U texture and store the
> + * resulting bytes in 'dst'. Alpha is preserved.
> + *
> + * @param dstoutput buffer.
> + * @param stride scanline in bytes.
> + * @param block  block to compress.
> + * @return how much texture data has been written.
> + */
> +static int rgtc1u_block(uint8_t *dst, ptrdiff_t stride, const uint8_t *block)
> +{
> +compress_alpha(dst, stride, block);
> +
> +return 8;
> +}

Although this makes sense for Hap which stores an alpha channel in RGTC 
textures, this is not standard and a general purpose RGTC1U compressor should 
take its values from the red channel. This function should match your 
rgtc1u_alpha_block() from your 
0006-libavodec-texturedsp-add-rgtc1u_alpha-uncompress-fun.patch

> Patch 2 : 0005-libavcodec-hapenc-add-support-for-hap-alpha-only-enc
> enable hap alpha only encoding in hapenc (and doc)
> Ratio need to be 8 for RGTC1 otherwise, only ffmpeg can decode the frame
> (the official hap lib failed to read the frame)

8 is correct so that makes sense

> +case HAP_FMT_RGTC1:
> +ratio = 8;
> +avctx->codec_tag = MKTAG('H', 'a', 'p', 'A');
> +avctx->bits_per_coded_sample = 24;

Some applications use the value from bits_per_coded_sample to determine the 
presence of alpha, so by convention this should probably be 32.

Cheers - Tom

> 
> To test :
> FFmpeg need to be compile with snappy library (--enable-libsnappy)
> 
> ./ffmpeg -i fileRgba -c:v hap -format hap_alpha_only res.mov
> 
> I test the result in the 3 hap mode (with ffmpeg (with previous patch for
> hap alpha only decoding decoding) and HapInAVFoundation test app (in OpenGL
> mode))
> 
> compressor None
> compressor snappy 1 chunk
> compressor snappy 16 chunks
> 
> 
> Martin
> Jokyo Images
> <0004-libavcodec-texturedspenc-add-rgtc1u-encoding.patch><0005-libavcodec-hapenc-add-support-for-hap-alpha-only-enc.patch>___
> 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] ffmpeg have program decoding ACC ltam audo stream

[Carl Eugen Hoyos]

2017-09-27 6:41 GMT+02:00  :

> Seems ffmpeg had problem decoding the audio stream - ACC ltam 5.1
>
> Appreciate your advise

Please post your question on the user mailing list and
provide a sample input file.

See also http://ffmpeg.org/contact.html#MailingLists

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

Re: [FFmpeg-devel] [PATCH] swscale_unscaled: fix DITHER_COPY macro, use it only for dst_depth == 8

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 12:04 PM, Mateusz  wrote:
>
> OK, so this fight with possible overflow is even more needed.
>

Luckily x86 SIMD has saturating instructions which don't overflow, so
if we device a way to properly optimize this in yasm/nasm assembly,
then this should be pretty simple to do.

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Martin Vignali]

>
> > +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> > +avctx->pix_fmt = AV_PIX_FMT_RGB0;
>
> The rgtc1u_block function places the single channel value in every channel
> except the alpha channel
> The pixel format you have chosen is one which disregards the alpha channel
>
> The output of this alpha-only decoder should be in the alpha channel of a
> pixel format which carries alpha. Probably other channels should have zero
> values.
>
>
Hi Tom,

After Carl answer, and thinking about that,
The goal of HapAlphaOnly, is to store alpha, but can also store gray only
(much better than HAP)
In fact, it can be call HAP Gray !
For example from my part, i would like to use this codec, for matte, but
also for gray only layer (use with color blending)

So i think, the best way to manage that, in the decoding and the encoding
part, is to
output GRAY8 in decoding
and encode from GRAY 8 only.

This approach is also more consistent, with other gray only
decoding/encoding of images files (like in tga, png, sgi...)

(For a future support of HAPQA encoding, the RGTC1 texture, will be use for
alpha, but we can consider that as a special case of rgtc1 encoding)

If a user want to compress a gray picture, it can be done using RGB to Gray
conversion
And if user want to compress only alpha or a specific channel, i think
ffmpeg have a filter for that (extractplanes (untested)),
so several encoding option, can be done, with simple command line, and can
adapt for several cases.

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Tom Butterworth]

> On 27 Sep 2017, at 11:59, Martin Vignali  wrote:
> 
>> 
>>> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
>>> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
>> 
>> The rgtc1u_block function places the single channel value in every channel
>> except the alpha channel
>> The pixel format you have chosen is one which disregards the alpha channel
>> 
>> The output of this alpha-only decoder should be in the alpha channel of a
>> pixel format which carries alpha. Probably other channels should have zero
>> values.
>> 
>> 
> Hi Tom,
> 
> After Carl answer, and thinking about that,
> The goal of HapAlphaOnly, is to store alpha, but can also store gray only
> (much better than HAP)
> In fact, it can be call HAP Gray !

But it isn’t

> For example from my part, i would like to use this codec, for matte, but
> also for gray only layer (use with color blending)

This is fine, but let’s concentrate on supporting Hap Alpha Only, not your 
non-standard use of it. If you would like this flexibility in Hap, that should 
be argued for on the Hap project, not within FFmpeg.

Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the 
implementation in FFmpeg must follow the definition (see 
https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md 
 ).

The Alpha Only encoder and decoder must ingest and emit a pixel format which 
carries alpha. It may be that adding a new alpha-only pixel format is not seen 
as desirable, in which case an existing format with alpha should be selected. 
This allows users to, eg, transcode from an RGBA format to Hap Alpha Only and 
have the channel they expect be preserved from the input video. Any other 
behaviour (eg having RGB converted to grey and then stored as alpha) is not 
acceptable.

> If a user want to compress a gray picture, it can be done using RGB to Gray
> conversion
> And if user want to compress only alpha or a specific channel, i think
> ffmpeg have a filter for that (extractplanes (untested)),

Your non-standard usage can still be achieved by channel switching in a filter, 
the default behaviour must be according to the standard, which is to encode and 
decode the alpha channel.

Cheers - Tom

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

[FFmpeg-devel] lavd: remove deprecated dv1394 device

[Josh de Kock]

Support for this device has been removed in kernel since v2.6.37. dv1394
has been superseded by libiec61883 which is functionally equivalent.

Signed-off-by: Josh de Kock 
---
 configure|   3 -
 doc/indevs.texi  |  25 
 libavdevice/Makefile |   1 -
 libavdevice/alldevices.c |   1 -
 libavdevice/dv1394.c | 239 ---
 libavdevice/dv1394.h | 357
---
 6 files changed, 626 deletions(-)
 delete mode 100644 libavdevice/dv1394.c
 delete mode 100644 libavdevice/dv1394.h

diff --git a/configure b/configure
index ba38a73906..a645ff4959 100755
--- a/configure
+++ b/configure
@@ -3075,8 +3075,6 @@ libndi_newtek_outdev_deps="libndi_newtek"
 libndi_newtek_outdev_extralibs="-lndi"
 dshow_indev_deps="IBaseFilter"
 dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32
-lshlwapi"
-dv1394_indev_deps="dv1394"
-dv1394_indev_select="dv_demuxer"
 fbdev_indev_deps="linux_fb_h"
 fbdev_outdev_deps="linux_fb_h"
 gdigrab_indev_deps="CreateDIBSection"
@@ -5068,7 +5066,6 @@ case $target_os in
 add_cppflags -U__STRICT_ANSI__
 ;;
 linux)
-enable dv1394
 enable section_data_rel_ro
 enabled_any arm aarch64 && enable_weak linux_perf
 ;;
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 30b7ac2380..776e563160 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -641,31 +641,6 @@ $ ffmpeg -f dshow -show_video_device_dialog true
-crossbar_video_input_pin_numbe

 @end itemize

-@section dv1394
-
-Linux DV 1394 input device.
-
-@subsection Options
-
-@table @option
-
-@item framerate
-Set the frame rate. Default is 25.
-
-@item standard
-
-Available values are:
-@table @samp
-@item pal
-
-@item ntsc
-
-@end table
-
-Default value is @code{ntsc}.
-
-@end table
-
 @section fbdev

 Linux framebuffer input device.
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index f40f4d5298..8228d62147 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -24,7 +24,6 @@ OBJS-$(CONFIG_LIBNDI_NEWTEK_INDEV)   +=
libndi_newtek_dec.o
 OBJS-$(CONFIG_DSHOW_INDEV)   += dshow_crossbar.o dshow.o
dshow_enummediatypes.o \
 dshow_enumpins.o
dshow_filter.o \
 dshow_pin.o dshow_common.o
-OBJS-$(CONFIG_DV1394_INDEV)  += dv1394.o
 OBJS-$(CONFIG_FBDEV_INDEV)   += fbdev_dec.o \
 fbdev_common.o
 OBJS-$(CONFIG_FBDEV_OUTDEV)  += fbdev_enc.o \
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index b31558bcb5..b767b6a718 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -48,7 +48,6 @@ static void register_all(void)
 REGISTER_INOUTDEV(DECKLINK, decklink);
 REGISTER_INOUTDEV(LIBNDI_NEWTEK,libndi_newtek);
 REGISTER_INDEV   (DSHOW,dshow);
-REGISTER_INDEV   (DV1394,   dv1394);
 REGISTER_INOUTDEV(FBDEV,fbdev);
 REGISTER_INDEV   (GDIGRAB,  gdigrab);
 REGISTER_INDEV   (IEC61883, iec61883);
diff --git a/libavdevice/dv1394.c b/libavdevice/dv1394.c
deleted file mode 100644
index c3483010fa..00
--- a/libavdevice/dv1394.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/*
- * Linux DV1394 interface
- * Copyright (c) 2003 Max Krasnyansky 
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
- */
-
-#include "config.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "libavutil/internal.h"
-#include "libavutil/log.h"
-#include "libavutil/opt.h"
-#include "avdevice.h"
-#include "libavformat/dv.h"
-#include "dv1394.h"
-
-struct dv1394_data {
-AVClass *class;
-int fd;
-int channel;
-int format;
-
-uint8_t *ring; /* Ring buffer */
-int index;  /* Current frame index */
-int avail;  /* Number of frames available for reading */
-int done;   /* Number of completed frames */
-
-DVDemuxContext* dv_demux; /* Generic DV muxing/demuxing context */
-};
-
-/*
- * The trick here is to kludge around well known problem with kernel
Ooopsing
- * when you try to capture PAL on a device node configure for NTSC. That's
- * why we have to configure the device 

Re: [FFmpeg-devel] [PATCH v4] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 26.09.2017 09:54, Tobias Rapp wrote:

On 20.09.2017 11:01, Tobias Rapp wrote:

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp 
---
tested on Linux x86-32/64 and Mips (Qemu)

v4:
  - fixed iteration order of final print loop
  - update of debug output

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

  tests/fate-run.sh |  9 +
  tests/fate/filter-video.mak   | 14 
  tests/ref/fate/filter-refcmp-psnr-rgb | 45 
  tests/ref/fate/filter-refcmp-psnr-yuv | 45 
  tests/ref/fate/filter-refcmp-ssim-rgb | 30 
  tests/ref/fate/filter-refcmp-ssim-yuv | 30 
  tests/refcmp-metadata.awk | 64 
+++

  7 files changed, 237 insertions(+)
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
  create mode 100644 tests/refcmp-metadata.awk

[...]


I'd like to push this soon, if there are no objections (Nicolas?).


Unfortunately the patch could not be applied as the reference files 
contain trailing whitespace.


Not sure what would be the preferred way to fix this:
- somehow change the git attributes to treat the reference files as 
binary (if possible)

- change the fate test to trim filter output line-by-line
- change the metadata filter itself to trim the affected lines
?

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[wm4]

On Tue, 26 Sep 2017 19:49:34 -0700
Aman Gupta  wrote:

> On Tue, Sep 26, 2017 at 7:20 PM, James Almer  wrote:
> 
> > On 9/26/2017 10:08 PM, Aman Gupta wrote:  
> > > From: Aman Gupta 
> > >
> > > ---
> > >  configure|   2 +
> > >  libavcodec/allcodecs.c   |   1 +
> > >  libavcodec/hevc_refs.c   |   3 +
> > >  libavcodec/hevcdec.c |  12 ++-
> > >  libavcodec/vda_vt_internal.h |   1 +
> > >  libavcodec/videotoolbox.c| 203 ++  
> > +  
> > >  6 files changed, 221 insertions(+), 1 deletion(-)  
> >  
> > > +CFDataRef ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
> > > +{
> > > +HEVCContext *h = avctx->priv_data;
> > > +const HEVCVPS *vps = (const HEVCVPS *)h->ps.vps_list[0]->data;
> > > +const HEVCSPS *sps = (const HEVCSPS *)h->ps.sps_list[0]->data;
> > > +int i, num_pps = 0;
> > > +const HEVCPPS *pps = h->ps.pps;  
> >  
> 
> One thing that surprised me.. when this is invoked, h->vps and h->sps are
> not yet set. Only h->pps has a value. I had to pull the vps and sps from
> the vps_list/sps_list directly.
> 
> 
> > > +PTLCommon ptlc = vps->ptl.general_ptl;
> > > +VUI vui = sps->vui;
> > > +uint8_t parallelismType;
> > > +CFDataRef data = NULL;
> > > +uint8_t *p;
> > > +int vt_extradata_size = 23 + 5 + vps->data_size + 5 +  
> > sps->data_size + 3;  
> > > +uint8_t *vt_extradata;
> > > +
> > > +for (i = 0; i < MAX_PPS_COUNT; i++) {
> > > +if (h->ps.pps_list[i]) {
> > > +const HEVCPPS *pps = (const HEVCPPS  
> > *)h->ps.pps_list[i]->data;  
> > > +vt_extradata_size += 2 + pps->data_size;
> > > +num_pps++;
> > > +}
> > > +}
> > > +
> > > +vt_extradata = av_malloc(vt_extradata_size);
> > > +if (!vt_extradata)
> > > +return NULL;
> > > +p = vt_extradata;
> > > +
> > > +/* unsigned int(8) configurationVersion = 1; */
> > > +AV_W8(p + 0, 1);  
> >
> > p is uint8_t*. Seems weird using AV_W8() for it.
> >
> > Yes, i know ff_videotoolbox_avcc_extradata_create() uses it, but there's
> > no reason to extend that behavior to new functions.
> >  
> 
> Are you recommending simple array access instead, i.e. `p[0] = 1`?
> 
> I just noticed the avcc creation is using AV_WB16() which would simplify
> some of my code.

AV_W8 doesn't actually exist - it's just a trivial macro defined in
videotoolbox.c. I added it because it looks more readable and symmetric,
especially mixed with AV_W16.

As for using bytestream writers etc. - I chose to manually write the
data, because this was the simplest at the time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] lavd: remove deprecated dv1394 device

[wm4]

On Wed, 27 Sep 2017 13:09:02 +0100
Josh de Kock  wrote:

> Support for this device has been removed in kernel since v2.6.37. dv1394
> has been superseded by libiec61883 which is functionally equivalent.
> 
> Signed-off-by: Josh de Kock 
> ---

The API has been removed 7 years ago from the kernel. LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[wm4]

On Tue, 26 Sep 2017 18:08:10 -0700
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> ---
>  configure|   2 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/hevc_refs.c   |   3 +
>  libavcodec/hevcdec.c |  12 ++-
>  libavcodec/vda_vt_internal.h |   1 +
>  libavcodec/videotoolbox.c| 203 
> +++
>  6 files changed, 221 insertions(+), 1 deletion(-)
> 

Generally LGTM, it basically does the same as h264.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[wm4]

On Tue, 26 Sep 2017 18:08:10 -0700
Aman Gupta  wrote:

> From: Aman Gupta 
> 
> ---
>  configure|   2 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/hevc_refs.c   |   3 +
>  libavcodec/hevcdec.c |  12 ++-
>  libavcodec/vda_vt_internal.h |   1 +
>  libavcodec/videotoolbox.c| 203 
> +++
>  6 files changed, 221 insertions(+), 1 deletion(-)

PS: A final patch should make sure these symbols don't cause build
failures with older SDKs:

> +case kCMVideoCodecType_HEVC :

> +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;


Maybe with a configure check.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4] fate: add tests for psnr and ssim filter

[Paul B Mahol]

On 9/27/17, Tobias Rapp  wrote:
> On 26.09.2017 09:54, Tobias Rapp wrote:
>> On 20.09.2017 11:01, Tobias Rapp wrote:
>>> Metadata filter output is passed through an Awk script comparing floats
>>> against reference values with specified "fuzz" tolerance to account for
>>> architectural differences (e.g. x86-32 vs. x86-64).
>>>
>>> Signed-off-by: Tobias Rapp 
>>> ---
>>> tested on Linux x86-32/64 and Mips (Qemu)
>>>
>>> v4:
>>>   - fixed iteration order of final print loop
>>>   - update of debug output
>>>
>>> v3:
>>>   - avoid precision loss due to rounding of float values
>>>
>>> v2:
>>>   - removed CPUFLAGS work-around for ssim filter issue
>>>   - added metadata float value post-processing script
>>>
>>>   tests/fate-run.sh |  9 +
>>>   tests/fate/filter-video.mak   | 14 
>>>   tests/ref/fate/filter-refcmp-psnr-rgb | 45 
>>>   tests/ref/fate/filter-refcmp-psnr-yuv | 45 
>>>   tests/ref/fate/filter-refcmp-ssim-rgb | 30 
>>>   tests/ref/fate/filter-refcmp-ssim-yuv | 30 
>>>   tests/refcmp-metadata.awk | 64
>>> +++
>>>   7 files changed, 237 insertions(+)
>>>   create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
>>>   create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
>>>   create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
>>>   create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
>>>   create mode 100644 tests/refcmp-metadata.awk
>>>
>>> [...]
>>
>> I'd like to push this soon, if there are no objections (Nicolas?).
>
> Unfortunately the patch could not be applied as the reference files
> contain trailing whitespace.
>
> Not sure what would be the preferred way to fix this:
> - somehow change the git attributes to treat the reference files as
> binary (if possible)
> - change the fate test to trim filter output line-by-line
> - change the metadata filter itself to trim the affected lines

This last one sounds best.

> ?
>
> Regards,
> Tobias
>
> ___
> 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] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[wm4]

On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz  wrote:

> Stopping the codec when no more input is available causes captured
> buffers that might be ready to be dequeued to be invalidated.
> 
> This commit follows the V4L2 API more closely:
> 1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
> 2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
> raised by the driver (EOF condition)
> 
> This also has the advantage of making the timeout on dequeuing capture
> buffers while draining unnecessary.
> ---
>  libavcodec/v4l2_context.c | 162 
> ++
>  1 file changed, 64 insertions(+), 98 deletions(-)

I can't really comment on the logic of this code. So LGTM, just some
minor comments/questions.

> -/* 0. handle errors */
> +/* handle errors */

(Apparently) unrelated cosmetic changes should usually be in separate
patches, but that's probably not worth the trouble in this case.

> +if (!frame) {
> +/* flag that we are draining */
> +ctx_to_m2mctx(ctx)->draining = 1;
> +
> +/* send EOS */
> +avbuf->buf.m.planes[0].bytesused = 1;
> +avbuf->flags |= V4L2_BUF_FLAG_LAST;
> +} else {
> +ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
> +if (ret)
> +return ret;
> +}

Wouldn't it be better to switch the if/else bodies and avoid the
negation in the if condition?

> -ret = ff_v4l2_buffer_avpkt_to_buf(pkt, avbuf);
> -if (ret)
> -return ret;
> +if (!pkt->size) {
> +/* flag that we are draining */
> +ctx_to_m2mctx(ctx)->draining = 1;
> +
> +/* send EOS */
> +avbuf->buf.m.planes[0].bytesused = 1;
> +avbuf->flags |= V4L2_BUF_FLAG_LAST;

What is going on here? Dummy buffer of size 1 to send the flag?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Deprecation of visual output devices

[Josh de Kock]

Hi,

There is no point of having these output devices as all the
functionality is contained in the 'ffplay' tool. If people wanted to
integrate these devices in their own programs instead of using the
ffmpeg tool then they are far too constrained for proper control, not to
mention output devices have been quick hacky in libavdevice for a long
time. There are three patches attached to deprecate the SDL2, OpenGL,
and libcaca devices.

-- 
Josh
From f950674e8893da8438ade6cee1050062d2bfb86c Mon Sep 17 00:00:00 2001
From: Josh de Kock 
Date: Wed, 27 Sep 2017 13:26:19 +0100
Subject: [PATCH 1/3] lavd: deprecate libcaca output device

Signed-off-by: Josh de Kock 
---
 libavdevice/caca.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavdevice/caca.c b/libavdevice/caca.c
index 93cc0ffd25..31cb94eda9 100644
--- a/libavdevice/caca.c
+++ b/libavdevice/caca.c
@@ -95,6 +95,8 @@ static int caca_write_header(AVFormatContext *s)
 AVCodecParameters *encctx = st->codecpar;
 int ret, bpp;
 
+av_log(s, AV_LOG_WARNING, "The libcaca output device is DEPRECATED and 
will be removed in a future version.\n");
+
 c->ctx = s;
 if (c->list_drivers) {
 list_drivers(c);
-- 
2.11.0 (Apple Git-81)

From da4aba837ff0effe873ea16d17100397843db464 Mon Sep 17 00:00:00 2001
From: Josh de Kock 
Date: Wed, 27 Sep 2017 13:27:53 +0100
Subject: [PATCH 2/3] lavd: deprecate opengl output device

Signed-off-by: Josh de Kock 
---
 libavdevice/opengl_enc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index bb6787c6f1..046383066f 100644
--- a/libavdevice/opengl_enc.c
+++ b/libavdevice/opengl_enc.c
@@ -1054,6 +1054,8 @@ static av_cold int opengl_write_header(AVFormatContext *h)
 AVStream *st;
 int ret;
 
+av_log(h, AV_LOG_WARNING, "The OpenGL output device is DEPRECATED and will 
be removed in a future version.\n");
+
 if (h->nb_streams != 1 ||
 h->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
 h->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
-- 
2.11.0 (Apple Git-81)

From 7c576e6acfa04cec6df9f8a59d98bacf43a44938 Mon Sep 17 00:00:00 2001
From: Josh de Kock 
Date: Wed, 27 Sep 2017 13:28:47 +0100
Subject: [PATCH 3/3] lavd: deprecate SDL2 output device

Signed-off-by: Josh de Kock 
---
 libavdevice/sdl2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c
index 5d9e91ec21..e53637eb42 100644
--- a/libavdevice/sdl2.c
+++ b/libavdevice/sdl2.c
@@ -164,6 +164,8 @@ static int sdl2_write_header(AVFormatContext *s)
 int i, ret = 0;
 int flags  = 0;
 
+av_log(s, AV_LOG_WARNING, "The SDL2 output device is DEPRECATED and will 
be removed in a future version.\n");
+
 if (!sdl->window_title)
 sdl->window_title = av_strdup(s->filename);
 
-- 
2.11.0 (Apple Git-81)

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Martin Vignali]

2017-09-27 13:25 GMT+02:00 Tom Butterworth :

>
>
> > On 27 Sep 2017, at 11:59, Martin Vignali 
> wrote:
> >
> >>
> >>> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> >>> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
> >>
> >> The rgtc1u_block function places the single channel value in every
> channel
> >> except the alpha channel
> >> The pixel format you have chosen is one which disregards the alpha
> channel
> >>
> >> The output of this alpha-only decoder should be in the alpha channel of
> a
> >> pixel format which carries alpha. Probably other channels should have
> zero
> >> values.
> >>
> >>
> > Hi Tom,
> >
> > After Carl answer, and thinking about that,
> > The goal of HapAlphaOnly, is to store alpha, but can also store gray only
> > (much better than HAP)
> > In fact, it can be call HAP Gray !
>
> But it isn’t
>
> > For example from my part, i would like to use this codec, for matte, but
> > also for gray only layer (use with color blending)
>
> This is fine, but let’s concentrate on supporting Hap Alpha Only, not your
> non-standard use of it. If you would like this flexibility in Hap, that
> should be argued for on the Hap project, not within FFmpeg.
>
> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the
> implementation in FFmpeg must follow the definition (see
> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md <
> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md>
> ).
>
> The Alpha Only encoder and decoder must ingest and emit a pixel format
> which carries alpha. It may be that adding a new alpha-only pixel format is
> not seen as desirable, in which case an existing format with alpha should
> be selected. This allows users to, eg, transcode from an RGBA format to Hap
> Alpha Only and have the channel they expect be preserved from the input
> video. Any other behaviour (eg having RGB converted to grey and then stored
> as alpha) is not acceptable.
>
> > If a user want to compress a gray picture, it can be done using RGB to
> Gray
> > conversion
> > And if user want to compress only alpha or a specific channel, i think
> > ffmpeg have a filter for that (extractplanes (untested)),
>
> Your non-standard usage can still be achieved by channel switching in a
> filter, the default behaviour must be according to the standard, which is
> to encode and decode the alpha channel.
>
> Cheers - Tom
> 
>


Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
alpha from RGBA input)
I will change the 24 to 32 as requested and send a new patch

Before sending a new patch for the decoding :
did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha]
for RGTC1 alpha decoding in RGBA ?

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 14:18:13 +0100
Josh de Kock  wrote:

> Hi,
> 
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool. If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control, not to
> mention output devices have been quick hacky in libavdevice for a long
> time. There are three patches attached to deprecate the SDL2, OpenGL,
> and libcaca devices.
> 

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Paul B Mahol]

On 9/27/17, Josh de Kock  wrote:
> Hi,
>
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool. If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control, not to
> mention output devices have been quick hacky in libavdevice for a long
> time. There are three patches attached to deprecate the SDL2, OpenGL,
> and libcaca devices.
>
> --
> Josh
>

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

[FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 libavfilter/f_metadata.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 23bc254..523a94d 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -314,14 +314,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 break;
 case METADATA_PRINT:
 if (!s->key && e) {
-s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%-7s\n",
+s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%s\n",
  inlink->frame_count_out, av_ts2str(frame->pts), 
av_ts2timestr(frame->pts, &inlink->time_base));
 s->print(ctx, "%s=%s\n", e->key, e->value);
 while ((e = av_dict_get(*metadata, "", e, AV_DICT_IGNORE_SUFFIX)) 
!= NULL) {
 s->print(ctx, "%s=%s\n", e->key, e->value);
 }
 } else if (e && e->value && (!s->value || (e->value && s->compare(s, 
e->value, s->value {
-s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%-7s\n",
+s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%s\n",
  inlink->frame_count_out, av_ts2str(frame->pts), 
av_ts2timestr(frame->pts, &inlink->time_base));
 s->print(ctx, "%s=%s\n", s->key, e->value);
 }
-- 
2.7.4


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

[FFmpeg-devel] [PATCH v5 2/2] fate: add tests for psnr and ssim filter

[Tobias Rapp]

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp 
---
tested on Linux x86-32/64 and Mips (Qemu)

v5:
  - fixed trailing whitespace within reference files

v4:
  - fixed iteration order of final print loop
  - update of debug output

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

 tests/fate-run.sh |  9 +
 tests/fate/filter-video.mak   | 14 
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 
 tests/refcmp-metadata.awk | 64 +++
 7 files changed, 237 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
 create mode 100644 tests/refcmp-metadata.awk

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 9aa9a22..c5480c7 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -234,6 +234,15 @@ lavftest(){
 ${base}/lavf-regression.sh $t lavf tests/vsynth1 "$target_exec" 
"$target_path" "$threads" "$thread_type" "$cpuflags" "$target_samples"
 }
 
+refcmp_metadata(){
+refcmp=$1
+pixfmt=$2
+fuzz=${3:-0.001}
+ffmpeg $FLAGS $ENC_OPTS \
+-lavfi 
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
 \
+-f null /dev/null | awk -v ref=${ref} -v fuzz=${fuzz} -f 
${base}/refcmp-metadata.awk -
+}
+
 video_filter(){
 filters=$1
 shift
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index d1e1341..78cd471 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -747,6 +747,20 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-rgb
+fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb 
b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..f06db57
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0
+lavfi.psnr.mse.r=1381.80
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=896.00
+lavfi.psnr.psnr.g=18.61
+lavfi.psnr.mse.b=277.38
+lavfi.psnr.psnr.b=23.70
+lavfi.psnr.mse_avg=851.73
+lavfi.psnr.psnr_avg=18.83
+frame:1pts:1   pts_time:1
+lavfi.psnr.mse.r=1380.37
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=975.91
+lavfi.psnr.psnr.g=18.24
+lavfi.psnr.mse.b=435.72
+lavfi.psnr.psnr.b=21.74
+lavfi.psnr.mse_avg=930.67
+lavfi.psnr.psnr_avg=18.44
+frame:2pts:2   pts_time:2
+lavfi.psnr.mse.r=1403.20
+lavfi.psnr.psnr.r=16.66
+lavfi.psnr.mse.g=954.05
+lavfi.psnr.psnr.g=18.34
+lavfi.psnr.mse.b=494.22
+lavfi.psnr.psnr.b=21.19
+lavfi.psnr.mse_avg=950.49
+lavfi.psnr.psnr_avg=18.35
+frame:3pts:3   pts_time:3
+lavfi.psnr.mse.r=1452.80
+lavfi.psnr.psnr.r=16.51
+lavfi.psnr.mse.g=1001.02
+lavfi.psnr.psnr.g=18.13
+lavfi.psnr.mse.b=557.39
+lavfi.psnr.psnr.b=20.67
+lavfi.psnr.mse_avg=1003.74
+lavfi.psnr.psnr_avg=18.11
+frame:4pts:4   pts_time:4
+lavfi.psnr.mse.r=1401.25
+lavfi.psnr.psnr.r=16.67
+lavfi.psnr.mse.g=1009.80
+lavfi.psnr.psnr.g=18.09
+lavfi.psnr.mse.b=602.42
+lavfi.psnr.psnr.b=20.33
+lavfi.psnr.mse_avg=1004.49
+lavfi.psnr.psnr_avg=18.11
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv 
b/tests/ref/fate/filter-refcmp-psnr-yuv
new file mode 100644
index 000..0e634ed
--- /dev/null
+++ b/tests/ref/fate/f

Re: [FFmpeg-devel] Deprecation of visual output devices

[Nicolas George]

Le sextidi 6 vendémiaire, an CCXXVI, Josh de Kock a écrit :
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool.

ffplay is not a library.

>  If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control

Maybe for your needs. Do not generalize.

Regards,

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Tom Butterworth]

> On 27 Sep 2017, at 14:20, Martin Vignali  wrote:
> 
> 2017-09-27 13:25 GMT+02:00 Tom Butterworth  >:
> 
>> 
>> 
>>> On 27 Sep 2017, at 11:59, Martin Vignali 
>> wrote:
>>> 
 
> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
 
 The rgtc1u_block function places the single channel value in every
>> channel
 except the alpha channel
 The pixel format you have chosen is one which disregards the alpha
>> channel
 
 The output of this alpha-only decoder should be in the alpha channel of
>> a
 pixel format which carries alpha. Probably other channels should have
>> zero
 values.
 
 
>>> Hi Tom,
>>> 
>>> After Carl answer, and thinking about that,
>>> The goal of HapAlphaOnly, is to store alpha, but can also store gray only
>>> (much better than HAP)
>>> In fact, it can be call HAP Gray !
>> 
>> But it isn’t
>> 
>>> For example from my part, i would like to use this codec, for matte, but
>>> also for gray only layer (use with color blending)
>> 
>> This is fine, but let’s concentrate on supporting Hap Alpha Only, not your
>> non-standard use of it. If you would like this flexibility in Hap, that
>> should be argued for on the Hap project, not within FFmpeg.
>> 
>> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the
>> implementation in FFmpeg must follow the definition (see
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md <
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md 
>> >
>> ).
>> 
>> The Alpha Only encoder and decoder must ingest and emit a pixel format
>> which carries alpha. It may be that adding a new alpha-only pixel format is
>> not seen as desirable, in which case an existing format with alpha should
>> be selected. This allows users to, eg, transcode from an RGBA format to Hap
>> Alpha Only and have the channel they expect be preserved from the input
>> video. Any other behaviour (eg having RGB converted to grey and then stored
>> as alpha) is not acceptable.
>> 
>>> If a user want to compress a gray picture, it can be done using RGB to
>> Gray
>>> conversion
>>> And if user want to compress only alpha or a specific channel, i think
>>> ffmpeg have a filter for that (extractplanes (untested)),
>> 
>> Your non-standard usage can still be achieved by channel switching in a
>> filter, the default behaviour must be according to the standard, which is
>> to encode and decode the alpha channel.
>> 
>> Cheers - Tom
>> > >
>> 
> 
> 
> Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> alpha from RGBA input)
> I will change the 24 to 32 as requested and send a new patch
> 
> Before sending a new patch for the decoding :
> did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha]
> for RGTC1 alpha decoding in RGBA ?

Personally I’d think 0 to allow further operations to eg combine the image with 
one with colour channels to work as expected.

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

Re: [FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Paul B Mahol]

On 9/27/17, Tobias Rapp  wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  libavfilter/f_metadata.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Martin Vignali]

2017-09-27 15:33 GMT+02:00 Tom Butterworth :

>
>
> > On 27 Sep 2017, at 14:20, Martin Vignali 
> wrote:
> >
> > 2017-09-27 13:25 GMT+02:00 Tom Butterworth  bangno...@gmail.com>>:
> >
> >>
> >>
> >>> On 27 Sep 2017, at 11:59, Martin Vignali 
> >> wrote:
> >>>
> 
> > +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> > +avctx->pix_fmt = AV_PIX_FMT_RGB0;
> 
>  The rgtc1u_block function places the single channel value in every
> >> channel
>  except the alpha channel
>  The pixel format you have chosen is one which disregards the alpha
> >> channel
> 
>  The output of this alpha-only decoder should be in the alpha channel
> of
> >> a
>  pixel format which carries alpha. Probably other channels should have
> >> zero
>  values.
> 
> 
> >>> Hi Tom,
> >>>
> >>> After Carl answer, and thinking about that,
> >>> The goal of HapAlphaOnly, is to store alpha, but can also store gray
> only
> >>> (much better than HAP)
> >>> In fact, it can be call HAP Gray !
> >>
> >> But it isn’t
> >>
> >>> For example from my part, i would like to use this codec, for matte,
> but
> >>> also for gray only layer (use with color blending)
> >>
> >> This is fine, but let’s concentrate on supporting Hap Alpha Only, not
> your
> >> non-standard use of it. If you would like this flexibility in Hap, that
> >> should be argued for on the Hap project, not within FFmpeg.
> >>
> >> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and
> the
> >> implementation in FFmpeg must follow the definition (see
> >> https://github.com/Vidvox/hap/blob/master/documentation/
> HapVideoDRAFT.md <
> >> https://github.com/Vidvox/hap/blob/master/documentation/
> HapVideoDRAFT.md  HapVideoDRAFT.md>>
> >> ).
> >>
> >> The Alpha Only encoder and decoder must ingest and emit a pixel format
> >> which carries alpha. It may be that adding a new alpha-only pixel
> format is
> >> not seen as desirable, in which case an existing format with alpha
> should
> >> be selected. This allows users to, eg, transcode from an RGBA format to
> Hap
> >> Alpha Only and have the channel they expect be preserved from the input
> >> video. Any other behaviour (eg having RGB converted to grey and then
> stored
> >> as alpha) is not acceptable.
> >>
> >>> If a user want to compress a gray picture, it can be done using RGB to
> >> Gray
> >>> conversion
> >>> And if user want to compress only alpha or a specific channel, i think
> >>> ffmpeg have a filter for that (extractplanes (untested)),
> >>
> >> Your non-standard usage can still be achieved by channel switching in a
> >> filter, the default behaviour must be according to the standard, which
> is
> >> to encode and decode the alpha channel.
> >>
> >> Cheers - Tom
> >>  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>
> >>
> >
> >
> > Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> > alpha from RGBA input)
> > I will change the 24 to 32 as requested and send a new patch
> >
> > Before sending a new patch for the decoding :
> > did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha]
> > for RGTC1 alpha decoding in RGBA ?
>
> Personally I’d think 0 to allow further operations to eg combine the image
> with one with colour channels to work as expected.
>
> Ok, i will do that,
so i can have the same decoding func in texture dsp that the one use for
hapqa_decoding.

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

Re: [FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Tobias Rapp]

On 27.09.2017 15:50, Paul B Mahol wrote:

On 9/27/17, Tobias Rapp  wrote:

Signed-off-by: Tobias Rapp 
---
  libavfilter/f_metadata.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



lgtm


Pushed both patches.

Thanks,
Tobias

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Michael Niedermayer]

On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
> Hi,
> 
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool. If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control, not to

> mention output devices have been quick hacky in libavdevice for a long

then please write a better API / lib / system


> time. There are three patches attached to deprecate the SDL2, OpenGL,
> and libcaca devices.

Once a better system exists with these features this can be deprecated.
requiring each user application to directly support each API of each
of these systems is very inconvenient for all but the large applications

Indeed the large applications benefit from the absence of a single API
as they eliminate competition from smaller apps which are unable to
maintain support for a wide range of output devices.

I think a good API that supports a wide range of in/out devices would
be very usefull for smaller/simpler applications using the libs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Anonymous Maarten]

Hey,

Building the static ffmpeg library using vcpkg is currently broken [1][2].
This is mainly due to the fact that the built static libraries are .a files
with lib prefixes.

The attached patch sets the lib prefix to "" and the lib suffix to ".lib".

Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
Edition on Windows 10.
The resulted libraries link correctly to my application.

[1]
https://github.com/Microsoft/vcpkg/blob/084b1afe9af1690916fab95bbb80c6891109f0fc/ports/ffmpeg/portfile.cmake#L1-L4
[2] https://github.com/Microsoft/vcpkg/issues/1821

Maarten,


0001-configure-create-.lib-static-libraries-using-MSVC-co.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 16:34:49 +0200
Michael Niedermayer  wrote:

> On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
> > Hi,
> > 
> > There is no point of having these output devices as all the
> > functionality is contained in the 'ffplay' tool. If people wanted to
> > integrate these devices in their own programs instead of using the
> > ffmpeg tool then they are far too constrained for proper control, not to  
> 
> > mention output devices have been quick hacky in libavdevice for a long  
> 
> then please write a better API / lib / system

It should never have been added this way. Why did it happen? On that
note, I tried to prevent it, and to argue that the contributor should
have created a better API instead of badly hacking it into libavdevice.

Why do you suddenly think there is a strong argument for keeping it?

> > time. There are three patches attached to deprecate the SDL2, OpenGL,
> > and libcaca devices.  
> 
> Once a better system exists with these features this can be deprecated.

> requiring each user application to directly support each API of each
> of these systems is very inconvenient for all but the large applications

There are entire frameworks for abstracting these things. libavdevice
is one of them, but only as a joke.

> Indeed the large applications benefit from the absence of a single API
> as they eliminate competition from smaller apps which are unable to
> maintain support for a wide range of output devices.
> 
> I think a good API that supports a wide range of in/out devices would
> be very usefull for smaller/simpler applications using the libs

Name a user of these APIs.

Your argumentation is full of fallacies. We don't actually do any of
those things for applications. As far as I'm aware, only the person who
added this API is even using it. Are you even aware that ffplay doesn't
use this API?

I'm sick of this attitude to keep bad/broken stuff just so that we
"have it". Supporting a feature is meaningless if it's low quality.
Maybe one day you will learn this.

I can't way for the day libavdevice or libavfilter will grow a UI
toolkit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Carl Eugen Hoyos]

2017-09-27 16:43 GMT+02:00 Anonymous Maarten :

> Building the static ffmpeg library using vcpkg is currently broken [1][2].
> This is mainly due to the fact that the built static libraries are .a files
> with lib prefixes.

Did this work with older versions of any of the involved tools
(including FFmpeg)?

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Carl Eugen Hoyos]

2017-09-27 15:18 GMT+02:00 Josh de Kock :

> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool.

I use at least sdl and opengl regularly for tests that cannot
be done with ffplay.

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[James Almer]

On 9/27/2017 12:01 PM, wm4 wrote:
> On Wed, 27 Sep 2017 16:34:49 +0200
> Michael Niedermayer  wrote:
> 
>> On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
>>> Hi,
>>>
>>> There is no point of having these output devices as all the
>>> functionality is contained in the 'ffplay' tool. If people wanted to
>>> integrate these devices in their own programs instead of using the
>>> ffmpeg tool then they are far too constrained for proper control, not to  
>>
>>> mention output devices have been quick hacky in libavdevice for a long  
>>
>> then please write a better API / lib / system
> 
> It should never have been added this way. Why did it happen? On that
> note, I tried to prevent it, and to argue that the contributor should
> have created a better API instead of badly hacking it into libavdevice.
> 
> Why do you suddenly think there is a strong argument for keeping it?
> 
>>> time. There are three patches attached to deprecate the SDL2, OpenGL,
>>> and libcaca devices.  
>>
>> Once a better system exists with these features this can be deprecated.
> 
>> requiring each user application to directly support each API of each
>> of these systems is very inconvenient for all but the large applications
> 
> There are entire frameworks for abstracting these things. libavdevice
> is one of them, but only as a joke.
> 
>> Indeed the large applications benefit from the absence of a single API
>> as they eliminate competition from smaller apps which are unable to
>> maintain support for a wide range of output devices.
>>
>> I think a good API that supports a wide range of in/out devices would
>> be very usefull for smaller/simpler applications using the libs
> 
> Name a user of these APIs.
> 
> Your argumentation is full of fallacies. We don't actually do any of
> those things for applications. As far as I'm aware, only the person who
> added this API is even using it. Are you even aware that ffplay doesn't
> use this API?
> 
> I'm sick of this attitude to keep bad/broken stuff just so that we
> "have it". Supporting a feature is meaningless if it's low quality.
> Maybe one day you will learn this.

We can't just remove something that works and has a defined use, as much
as it's disliked, without at least come up with a replacement or a good
reason why it's being dropped without a replacement. And by good reason
i mean something like "This is in the way of this other useful thing
that we're trying to add/achieve". If that happens, i assume not a lot
of people will speak in favor of lavd.

> 
> I can't way for the day libavdevice or libavfilter will grow a UI
> toolkit.
> ___
> 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 a test for latm-in-dvb autodetection

[Carl Eugen Hoyos]

Hi!

Attached patch adds a test for ticket #6657.

Please comment, Carl Eugen
From bef8e7beff7a674180404aa70424f08c6a86a9cd Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Sep 2017 17:05:14 +0200
Subject: [PATCH] fate: Add a test for latm-in-dvb auto-detection, ticket
 #6657.

---
 tests/Makefile   |1 +
 tests/fate/mpegts.mak|   14 +++
 tests/ref/fate/mpegts-probe-latm |  191 ++
 3 files changed, 206 insertions(+)
 create mode 100644 tests/fate/mpegts.mak
 create mode 100644 tests/ref/fate/mpegts-probe-latm

diff --git a/tests/Makefile b/tests/Makefile
index 99f7e17..278be24 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -156,6 +156,7 @@ include $(SRC_PATH)/tests/fate/mov.mak
 include $(SRC_PATH)/tests/fate/mp3.mak
 include $(SRC_PATH)/tests/fate/mpc.mak
 include $(SRC_PATH)/tests/fate/mpeg4.mak
+include $(SRC_PATH)/tests/fate/mpegts.mak
 include $(SRC_PATH)/tests/fate/mxf.mak
 include $(SRC_PATH)/tests/fate/opus.mak
 include $(SRC_PATH)/tests/fate/pcm.mak
diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
new file mode 100644
index 000..b0644aa
--- /dev/null
+++ b/tests/fate/mpegts.mak
@@ -0,0 +1,14 @@
+#
+# Test probing MPEGTS format and stream properties
+#
+PROBE_FORMAT_STREAMS_COMMAND = \
+ffprobe$(PROGSSUF)$(EXESUF) -show_entries format=format_tags:streams \
+-print_format default -bitexact -v 0
+
+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += fate-mpegts-probe-latm
+fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
+fate-mpegts-probe-latm: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)"
+
+FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)
+
+fate-mpegts: $(FATE_MPEGTS_PROBE-yes)
diff --git a/tests/ref/fate/mpegts-probe-latm b/tests/ref/fate/mpegts-probe-latm
new file mode 100644
index 000..1d36306
--- /dev/null
+++ b/tests/ref/fate/mpegts-probe-latm
@@ -0,0 +1,191 @@
+[PROGRAM]
+[STREAM]
+index=0
+codec_name=hevc
+profile=1
+codec_type=video
+codec_time_base=1/50
+codec_tag_string=[36][0][0][0]
+codec_tag=0x0024
+width=1920
+height=1080
+coded_width=1920
+coded_height=1080
+has_b_frames=5
+sample_aspect_ratio=1:1
+display_aspect_ratio=16:9
+pix_fmt=yuv420p
+level=123
+color_range=tv
+color_space=bt709
+color_transfer=bt709
+color_primaries=bt709
+chroma_location=unspecified
+field_order=unknown
+timecode=N/A
+refs=1
+id=0x551
+r_frame_rate=50/1
+avg_frame_rate=50/1
+time_base=1/9
+start_pts=2863340144
+start_time=31814.890489
+duration_ts=41400
+duration=0.46
+bit_rate=N/A
+max_bit_rate=N/A
+bits_per_raw_sample=N/A
+nb_frames=N/A
+nb_read_frames=N/A
+nb_read_packets=N/A
+DISPOSITION:default=0
+DISPOSITION:dub=0
+DISPOSITION:original=0
+DISPOSITION:comment=0
+DISPOSITION:lyrics=0
+DISPOSITION:karaoke=0
+DISPOSITION:forced=0
+DISPOSITION:hearing_impaired=0
+DISPOSITION:visual_impaired=0
+DISPOSITION:clean_effects=0
+DISPOSITION:attached_pic=0
+DISPOSITION:timed_thumbnails=0
+[/STREAM]
+[STREAM]
+index=1
+codec_name=aac_latm
+profile=1
+codec_type=audio
+codec_time_base=1/48000
+codec_tag_string=[15][0][0][0]
+codec_tag=0x000f
+sample_fmt=fltp
+sample_rate=48000
+channels=2
+channel_layout=stereo
+bits_per_sample=0
+id=0x552
+r_frame_rate=0/0
+avg_frame_rate=0/0
+time_base=1/9
+start_pts=2863278584
+start_time=31814.206489
+duration_ts=24960
+duration=0.277333
+bit_rate=N/A
+max_bit_rate=N/A
+bits_per_raw_sample=N/A
+nb_frames=N/A
+nb_read_frames=N/A
+nb_read_packets=N/A
+DISPOSITION:default=0
+DISPOSITION:dub=0
+DISPOSITION:original=0
+DISPOSITION:comment=0
+DISPOSITION:lyrics=0
+DISPOSITION:karaoke=0
+DISPOSITION:forced=0
+DISPOSITION:hearing_impaired=0
+DISPOSITION:visual_impaired=0
+DISPOSITION:clean_effects=0
+DISPOSITION:attached_pic=0
+DISPOSITION:timed_thumbnails=0
+[/STREAM]
+[/PROGRAM]
+[STREAM]
+index=0
+codec_name=hevc
+profile=1
+codec_type=video
+codec_time_base=1/50
+codec_tag_string=[36][0][0][0]
+codec_tag=0x0024
+width=1920
+height=1080
+coded_width=1920
+coded_height=1080
+has_b_frames=5
+sample_aspect_ratio=1:1
+display_aspect_ratio=16:9
+pix_fmt=yuv420p
+level=123
+color_range=tv
+color_space=bt709
+color_transfer=bt709
+color_primaries=bt709
+chroma_location=unspecified
+field_order=unknown
+timecode=N/A
+refs=1
+id=0x551
+r_frame_rate=50/1
+avg_frame_rate=50/1
+time_base=1/9
+start_pts=2863340144
+start_time=31814.890489
+duration_ts=41400
+duration=0.46
+bit_rate=N/A
+max_bit_rate=N/A
+bits_per_raw_sample=N/A
+nb_frames=N/A
+nb_read_frames=N/A
+nb_read_packets=N/A
+DISPOSITION:default=0
+DISPOSITION:dub=0
+DISPOSITION:original=0
+DISPOSITION:comment=0
+DISPOSITION:lyrics=0
+DISPOSITION:karaoke=0
+DISPOSITION:forced=0
+DISPOSITION:hearing_impaired=0
+DISPOSITION:visual_impaired=0
+DISPOSITION:clean_effects=0
+DISPOSITION:attached_pic=0
+DISPOSITION:timed_thumbnails=0
+[/STREAM]
+[STREAM]
+index=1
+codec_name=aac_latm
+profile=1
+codec_type=audio
+codec_time_base=1/48000
+codec_tag_string=[15][0][0][0]
+codec_tag=0x000

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 17:08:06 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
> 
> > There is no point of having these output devices as all the
> > functionality is contained in the 'ffplay' tool.  
> 
> I use at least sdl and opengl regularly for tests that cannot
> be done with ffplay.

How does it make sense to use those for testing, when the rendering
isn't particularly correct in the first place? Seems like a rather bad
idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Deprecation of visual output devices

[Carl Eugen Hoyos]

2017-09-27 17:15 GMT+02:00 wm4 :
> On Wed, 27 Sep 2017 17:08:06 +0200
> Carl Eugen Hoyos  wrote:
>
>> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
>>
>> > There is no point of having these output devices as all the
>> > functionality is contained in the 'ffplay' tool.
>>
>> I use at least sdl and opengl regularly for tests that cannot
>> be done with ffplay.
>
> How does it make sense to use those for testing

FFplay only supports a limited set of pix_fmts,
contrary to those devices.

> when the rendering isn't particularly correct in the first place?

I had not known this / this has not hit me so far.
How can I reproduce?

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Josh de Kock]

On 27/09/2017 16:17, Carl Eugen Hoyos wrote:
> 2017-09-27 17:15 GMT+02:00 wm4 :
>> On Wed, 27 Sep 2017 17:08:06 +0200
>> Carl Eugen Hoyos  wrote:
>>
>>> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
>>>
 There is no point of having these output devices as all the
 functionality is contained in the 'ffplay' tool.
>>>
>>> I use at least sdl and opengl regularly for tests that cannot
>>> be done with ffplay.
>>
>> How does it make sense to use those for testing
> 
> FFplay only supports a limited set of pix_fmts,
> contrary to those devices.
> 

So if there is pix_fmt parity then I can remove OpenGL, and SDL2? This
should be simple enough.

>> when the rendering isn't particularly correct in the first place?
> 
> I had not known this / this has not hit me so far.
> How can I reproduce?
> 
> Carl Eugen

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

Re: [FFmpeg-devel] [PATCH v5 2/2] fate: add tests for psnr and ssim filter

[Carl Eugen Hoyos]

2017-09-27 15:30 GMT+02:00 Tobias Rapp :
> Metadata filter output is passed through an Awk script comparing floats

Is awk needed on the host or the target system?

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Michael Niedermayer]

On Wed, Sep 27, 2017 at 05:01:59PM +0200, wm4 wrote:
> On Wed, 27 Sep 2017 16:34:49 +0200
> Michael Niedermayer  wrote:
> 
> > On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
> > > Hi,
> > > 
> > > There is no point of having these output devices as all the
> > > functionality is contained in the 'ffplay' tool. If people wanted to
> > > integrate these devices in their own programs instead of using the
> > > ffmpeg tool then they are far too constrained for proper control, not to  
> > 
> > > mention output devices have been quick hacky in libavdevice for a long  
> > 
> > then please write a better API / lib / system
> 
> It should never have been added this way. Why did it happen? On that
> note, I tried to prevent it,

> and to argue that the contributor should
> have created a better API instead of badly hacking it into libavdevice.

I did not say anything like that.

What i stated should be the obvious
if people feel what we have doesnt serve its intended goals then
it makes sense to write something that does.

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 17:17:37 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 17:15 GMT+02:00 wm4 :
> > On Wed, 27 Sep 2017 17:08:06 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
> >>  
> >> > There is no point of having these output devices as all the
> >> > functionality is contained in the 'ffplay' tool.  
> >>
> >> I use at least sdl and opengl regularly for tests that cannot
> >> be done with ffplay.  
> >
> > How does it make sense to use those for testing  
> 
> FFplay only supports a limited set of pix_fmts,
> contrary to those devices.
> 
> > when the rendering isn't particularly correct in the first place?  
> 
> I had not known this / this has not hit me so far.
> How can I reproduce?

Apparently it doesn't respect colorspace, any other colorimetry
settings, chroma location, and I wouldn't trust it to get odd cropping
right. It's really basic and naive.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Deprecation of visual output devices

[Carl Eugen Hoyos]

2017-09-27 17:21 GMT+02:00 Josh de Kock :
> On 27/09/2017 16:17, Carl Eugen Hoyos wrote:
>> 2017-09-27 17:15 GMT+02:00 wm4 :
>>> On Wed, 27 Sep 2017 17:08:06 +0200
>>> Carl Eugen Hoyos  wrote:
>>>
 2017-09-27 15:18 GMT+02:00 Josh de Kock :

> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool.

 I use at least sdl and opengl regularly for tests that cannot
 be done with ffplay.
>>>
>>> How does it make sense to use those for testing
>>
>> FFplay only supports a limited set of pix_fmts,
>> contrary to those devices.
>
> So if there is pix_fmt parity then I can remove OpenGL, and SDL2?

No, but you can mark my argument as obsolete.

> This should be simple enough.

Sure?
I was more under the assumption that this is simply impossible.
(Until SDL3)

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Josh de Kock]

On 27/09/2017 16:28, Carl Eugen Hoyos wrote:
> 2017-09-27 17:21 GMT+02:00 Josh de Kock :
>> On 27/09/2017 16:17, Carl Eugen Hoyos wrote:
>>> 2017-09-27 17:15 GMT+02:00 wm4 :
 On Wed, 27 Sep 2017 17:08:06 +0200
 Carl Eugen Hoyos  wrote:

> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
>
>> There is no point of having these output devices as all the
>> functionality is contained in the 'ffplay' tool.
>
> I use at least sdl and opengl regularly for tests that cannot
> be done with ffplay.

 How does it make sense to use those for testing
>>>
>>> FFplay only supports a limited set of pix_fmts,
>>> contrary to those devices.
>>
>> So if there is pix_fmt parity then I can remove OpenGL, and SDL2?
> 
> No, but you can mark my argument as obsolete.

I see no reason to bring parity to ffplay then.

>> This should be simple enough.
> 
> Sure?
> I was more under the assumption that this is simply impossible.
> (Until SDL3)

Why would it be impossible? I don't see how the OpenGL, SDL2 device
could support more pixel formats than FFplay when they *all* use SDL2.

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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
 wrote:
> Hey,
>
> Building the static ffmpeg library using vcpkg is currently broken [1][2].
> This is mainly due to the fact that the built static libraries are .a files
> with lib prefixes.
>
> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>
> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
> Edition on Windows 10.
> The resulted libraries link correctly to my application.
>

This would break the workflow for everyone that is currently working
with the current names, however.

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 16:31:37 +0100
Josh de Kock  wrote:

> On 27/09/2017 16:28, Carl Eugen Hoyos wrote:
> > 2017-09-27 17:21 GMT+02:00 Josh de Kock :  
> >> On 27/09/2017 16:17, Carl Eugen Hoyos wrote:  
> >>> 2017-09-27 17:15 GMT+02:00 wm4 :  
>  On Wed, 27 Sep 2017 17:08:06 +0200
>  Carl Eugen Hoyos  wrote:
>   
> > 2017-09-27 15:18 GMT+02:00 Josh de Kock :
> >  
> >> There is no point of having these output devices as all the
> >> functionality is contained in the 'ffplay' tool.  
> >
> > I use at least sdl and opengl regularly for tests that cannot
> > be done with ffplay.  
> 
>  How does it make sense to use those for testing  
> >>>
> >>> FFplay only supports a limited set of pix_fmts,
> >>> contrary to those devices.  
> >>
> >> So if there is pix_fmt parity then I can remove OpenGL, and SDL2?  
> > 
> > No, but you can mark my argument as obsolete.  
> 
> I see no reason to bring parity to ffplay then.
> 
> >> This should be simple enough.  
> > 
> > Sure?
> > I was more under the assumption that this is simply impossible.
> > (Until SDL3)  
> 
> Why would it be impossible? I don't see how the OpenGL, SDL2 device
> could support more pixel formats than FFplay when they *all* use SDL2.

The OpenGL one uses shaders, but for the others his argument is bogus,
yes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Carl Eugen Hoyos]

2017-09-27 15:20 GMT+02:00 Martin Vignali :
> 2017-09-27 13:25 GMT+02:00 Tom Butterworth :
>
>>
>>
>> > On 27 Sep 2017, at 11:59, Martin Vignali 
>> wrote:
>> >
>> >>
>> >>> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
>> >>> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
>> >>
>> >> The rgtc1u_block function places the single channel value in every
>> channel
>> >> except the alpha channel
>> >> The pixel format you have chosen is one which disregards the alpha
>> channel
>> >>
>> >> The output of this alpha-only decoder should be in the alpha channel of
>> a
>> >> pixel format which carries alpha. Probably other channels should have
>> zero
>> >> values.
>> >>
>> >>
>> > Hi Tom,
>> >
>> > After Carl answer, and thinking about that,
>> > The goal of HapAlphaOnly, is to store alpha, but can also store gray only
>> > (much better than HAP)
>> > In fact, it can be call HAP Gray !
>>
>> But it isn’t
>>
>> > For example from my part, i would like to use this codec, for matte, but
>> > also for gray only layer (use with color blending)
>>
>> This is fine, but let’s concentrate on supporting Hap Alpha Only, not your
>> non-standard use of it. If you would like this flexibility in Hap, that
>> should be argued for on the Hap project, not within FFmpeg.
>>
>> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the
>> implementation in FFmpeg must follow the definition (see
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md <
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md>
>> ).
>>
>> The Alpha Only encoder and decoder must ingest and emit a pixel format
>> which carries alpha. It may be that adding a new alpha-only pixel format is
>> not seen as desirable, in which case an existing format with alpha should
>> be selected. This allows users to, eg, transcode from an RGBA format to Hap
>> Alpha Only and have the channel they expect be preserved from the input
>> video. Any other behaviour (eg having RGB converted to grey and then stored
>> as alpha) is not acceptable.
>>
>> > If a user want to compress a gray picture, it can be done using
>> > RGB to Gray conversion

Of course.
But if the input is single-plane, 8bit, it does not make sense to
output rgb (or rgba).

>> > And if user want to compress only alpha or a specific channel, i think
>> > ffmpeg have a filter for that (extractplanes (untested)),
>>
>> Your non-standard usage can still be achieved by channel switching in a
>> filter, the default behaviour must be according to the standard, which is
>> to encode and decode the alpha channel.

Which is not possible because FFmpeg does not support a single
alpha plane.

> Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> alpha from RGBA input)

I am less convinced:
As long as FFmpeg does not have a native alpha-only
pix_fmt (I am not sure this would have any user-visible
advantage), single-layer 8bit formats should be decoded
as gray8.

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[Jorge Ramirez-Ortiz]

On 09/27/2017 06:01 AM, wm4 wrote:

On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz  wrote:


Stopping the codec when no more input is available causes captured
buffers that might be ready to be dequeued to be invalidated.

This commit follows the V4L2 API more closely:
1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
raised by the driver (EOF condition)

This also has the advantage of making the timeout on dequeuing capture
buffers while draining unnecessary.
---
  libavcodec/v4l2_context.c | 162 ++
  1 file changed, 64 insertions(+), 98 deletions(-)

I can't really comment on the logic of this code. So LGTM, just some
minor comments/questions.


-/* 0. handle errors */
+/* handle errors */

(Apparently) unrelated cosmetic changes should usually be in separate
patches, but that's probably not worth the trouble in this case.


ACK. will do on any following patches - or I can do it on this one if you want.


+if (!frame) {
+/* flag that we are draining */
+ctx_to_m2mctx(ctx)->draining = 1;
+
+/* send EOS */
+avbuf->buf.m.planes[0].bytesused = 1;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;
+} else {
+ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
+if (ret)
+return ret;
+}

Wouldn't it be better to switch the if/else bodies and avoid the
negation in the if condition?


yes
I am going to add a ff_v4l2_buffer_eos() to avoid exposing the bytesused at this 
level as well.

will fix




-ret = ff_v4l2_buffer_avpkt_to_buf(pkt, avbuf);
-if (ret)
-return ret;
+if (!pkt->size) {
+/* flag that we are draining */
+ctx_to_m2mctx(ctx)->draining = 1;
+
+/* send EOS */
+avbuf->buf.m.planes[0].bytesused = 1;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;

What is going on here? Dummy buffer of size 1 to send the flag?


yes. we need to queue a dummy buffer to the input queue that carries that flag.
that way, the v4l2 device driver can raise EPIPE to indicate that the last 
buffer was processed.





___
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/2] avcodec/hevc_ps: extract SPS fields required for hvcC construction

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 06:08:09PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/hevc_ps.c | 3 ++-
>  libavcodec/hevc_ps.h | 2 ++
>  2 files changed, 4 insertions(+), 1 deletion(-)

LGTM

thx

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

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


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

[FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

Hi!

The existing amr demuxer does not allow reading streams, it requires
the 3GPP-conforming file header.
Attached patch allows reading amrnb and amrwb from (live) streams,
fixes ticket #6678.

Please comment, Carl Eugen
From 1b548fbd47f521d0c2a7b443ac2b1f2925e8bb41 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Sep 2017 18:04:39 +0200
Subject: [PATCH] lavf/amr: Add amrnb and amrwb demuxers.

Fixes ticket #6678.
---
 libavformat/Makefile |2 ++
 libavformat/allformats.c |2 ++
 libavformat/amr.c|   54 ++
 libavformat/version.h|4 ++--
 4 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index df709c29..c4c8713 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -87,6 +87,8 @@ OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o id3v2enc.o
 OBJS-$(CONFIG_AIX_DEMUXER)   += aixdec.o
 OBJS-$(CONFIG_AMR_DEMUXER)   += amr.o
 OBJS-$(CONFIG_AMR_MUXER) += amr.o
+OBJS-$(CONFIG_AMRNB_DEMUXER) += amr.o
+OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
 OBJS-$(CONFIG_ANM_DEMUXER)   += anm.o
 OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5..dc8984e 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -63,6 +63,8 @@ static void register_all(void)
 REGISTER_MUXDEMUX(AIFF, aiff);
 REGISTER_DEMUXER (AIX,  aix);
 REGISTER_MUXDEMUX(AMR,  amr);
+REGISTER_DEMUXER (AMRNB,amrnb);
+REGISTER_DEMUXER (AMRWB,amrwb);
 REGISTER_DEMUXER (ANM,  anm);
 REGISTER_DEMUXER (APC,  apc);
 REGISTER_DEMUXER (APE,  ape);
diff --git a/libavformat/amr.c b/libavformat/amr.c
index b5194a2..07f2315 100644
--- a/libavformat/amr.c
+++ b/libavformat/amr.c
@@ -176,6 +176,60 @@ AVInputFormat ff_amr_demuxer = {
 };
 #endif
 
+#if CONFIG_AMRNB_DEMUXER
+static int amrnb_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_tag  = MKTAG('s', 'a', 'm', 'r');
+st->codecpar->codec_id   = AV_CODEC_ID_AMR_NB;
+st->codecpar->sample_rate= 8000;
+st->codecpar->channels   = 1;
+st->codecpar->channel_layout = AV_CH_LAYOUT_MONO;
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+avpriv_set_pts_info(st, 64, 1, 8000);
+
+return 0;
+}
+
+AVInputFormat ff_amrnb_demuxer = {
+.name   = "amrnb",
+.long_name  = NULL_IF_CONFIG_SMALL("raw AMR-NB"),
+.priv_data_size = sizeof(AMRContext),
+.read_header= amrnb_read_header,
+.read_packet= amr_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
+#endif
+
+#if CONFIG_AMRWB_DEMUXER
+static int amrwb_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_tag  = MKTAG('s', 'a', 'w', 'b');
+st->codecpar->codec_id   = AV_CODEC_ID_AMR_WB;
+st->codecpar->sample_rate= 16000;
+st->codecpar->channels   = 1;
+st->codecpar->channel_layout = AV_CH_LAYOUT_MONO;
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+avpriv_set_pts_info(st, 64, 1, 16000);
+
+return 0;
+}
+
+AVInputFormat ff_amrwb_demuxer = {
+.name   = "amrwb",
+.long_name  = NULL_IF_CONFIG_SMALL("raw AMR-WB"),
+.priv_data_size = sizeof(AMRContext),
+.read_header= amrwb_read_header,
+.read_packet= amr_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
+#endif
+
 #if CONFIG_AMR_MUXER
 AVOutputFormat ff_amr_muxer = {
 .name  = "amr",
diff --git a/libavformat/version.h b/libavformat/version.h
index ac6edf7..878917d 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,8 +32,8 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  57
-#define LIBAVFORMAT_VERSION_MINOR  82
-#define LIBAVFORMAT_VERSION_MICRO 102
+#define LIBAVFORMAT_VERSION_MINOR  83
+#define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
1.7.10.4

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

Re: [FFmpeg-devel] lavd: remove deprecated dv1394 device

[Josh de Kock]

On 27/09/2017 13:33, wm4 wrote:
> On Wed, 27 Sep 2017 13:09:02 +0100
> Josh de Kock  wrote:
> 
>> Support for this device has been removed in kernel since v2.6.37. dv1394
>> has been superseded by libiec61883 which is functionally equivalent.
>>
>> Signed-off-by: Josh de Kock 
>> ---
> 
> The API has been removed 7 years ago from the kernel. LGTM.

Thanks pushed,

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[Aman Gupta]

On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:

> On Tue, 26 Sep 2017 18:08:10 -0700
> Aman Gupta  wrote:
>
> > From: Aman Gupta 
> >
> > ---
> >  configure|   2 +
> >  libavcodec/allcodecs.c   |   1 +
> >  libavcodec/hevc_refs.c   |   3 +
> >  libavcodec/hevcdec.c |  12 ++-
> >  libavcodec/vda_vt_internal.h |   1 +
> >  libavcodec/videotoolbox.c| 203 ++
> +
> >  6 files changed, 221 insertions(+), 1 deletion(-)
>
> PS: A final patch should make sure these symbols don't cause build
> failures with older SDKs:
>
> > +case kCMVideoCodecType_HEVC :
>
> > +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;
>
>
> Maybe with a configure check.
>

This is available since macOS 10.11. How far back does ffmpeg support?


> ___
> 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] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[wm4]

On Wed, 27 Sep 2017 09:03:58 -0700
Jorge Ramirez-Ortiz  wrote:

> On 09/27/2017 06:01 AM, wm4 wrote:
> > On Tue, 26 Sep 2017 16:22:23 -0700
> > Jorge Ramirez-Ortiz  wrote:
> >  
> >> Stopping the codec when no more input is available causes captured
> >> buffers that might be ready to be dequeued to be invalidated.
> >>
> >> This commit follows the V4L2 API more closely:
> >> 1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
> >> 2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
> >> raised by the driver (EOF condition)
> >>
> >> This also has the advantage of making the timeout on dequeuing capture
> >> buffers while draining unnecessary.
> >> ---
> >>   libavcodec/v4l2_context.c | 162 
> >> ++
> >>   1 file changed, 64 insertions(+), 98 deletions(-)  
> > I can't really comment on the logic of this code. So LGTM, just some
> > minor comments/questions.
> >  
> >> -/* 0. handle errors */
> >> +/* handle errors */  
> > (Apparently) unrelated cosmetic changes should usually be in separate
> > patches, but that's probably not worth the trouble in this case.  
> 
> ACK. will do on any following patches - or I can do it on this one if you 
> want.

Not necessary. In general we prefer separating unrelated changes, but I
think there's a limit to which we have to cause additional work to
follow this rule. (It's mainly in cases where the cosmetic changes are
significant or in completely different code.)

> >> +if (!frame) {
> >> +/* flag that we are draining */
> >> +ctx_to_m2mctx(ctx)->draining = 1;
> >> +
> >> +/* send EOS */
> >> +avbuf->buf.m.planes[0].bytesused = 1;
> >> +avbuf->flags |= V4L2_BUF_FLAG_LAST;
> >> +} else {
> >> +ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
> >> +if (ret)
> >> +return ret;
> >> +}  
> > Wouldn't it be better to switch the if/else bodies and avoid the
> > negation in the if condition?  
> 
> yes
> I am going to add a ff_v4l2_buffer_eos() to avoid exposing the bytesused at 
> this 
> level as well.
> will fix

That sounds good. So you're going to send a new patch? Then I'll hold
off applying this one.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[wm4]

On Wed, 27 Sep 2017 09:17:36 -0700
Aman Gupta  wrote:

> On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:
> 
> > On Tue, 26 Sep 2017 18:08:10 -0700
> > Aman Gupta  wrote:
> >  
> > > From: Aman Gupta 
> > >
> > > ---
> > >  configure|   2 +
> > >  libavcodec/allcodecs.c   |   1 +
> > >  libavcodec/hevc_refs.c   |   3 +
> > >  libavcodec/hevcdec.c |  12 ++-
> > >  libavcodec/vda_vt_internal.h |   1 +
> > >  libavcodec/videotoolbox.c| 203 ++  
> > +  
> > >  6 files changed, 221 insertions(+), 1 deletion(-)  
> >
> > PS: A final patch should make sure these symbols don't cause build
> > failures with older SDKs:
> >  
> > > +case kCMVideoCodecType_HEVC :  
> >  
> > > +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;  
> >
> >
> > Maybe with a configure check.
> >  
> 
> This is available since macOS 10.11. How far back does ffmpeg support?

Really not sure. If VideoToolbox support is never detected before
10.11, then it's OK.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 18:08:19 +0200
Carl Eugen Hoyos  wrote:

> Hi!
> 
> The existing amr demuxer does not allow reading streams, it requires
> the 3GPP-conforming file header.
> Attached patch allows reading amrnb and amrwb from (live) streams,
> fixes ticket #6678.
> 
> Please comment, Carl Eugen

That seems particularly pointless, since the user has to force the
demuxers. I don't know what that ticket is, all information should be
in the commit message anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/9] avcodec/h264, videotoolbox: return AVERROR_INVALIDDATA when no frames are produced

[Michael Niedermayer]

On Mon, Sep 25, 2017 at 05:36:28PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> The only reason videotoolbox wouldn't produce frames is if the data fed
> to it was invalid, so returning AVERROR_INVALIDDATA makes sense here.
> 
> Further, it means AVERROR_EXTERNAL can be used in further commits to signal
> fatal VideoToolbox errors, letting the user know that they need to fallback to
> another decoder.
> ---
>  libavcodec/h264dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

probably ok

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 18:40 GMT+02:00 wm4 :
> On Wed, 27 Sep 2017 18:08:19 +0200
> Carl Eugen Hoyos  wrote:
>
>> Hi!
>>
>> The existing amr demuxer does not allow reading streams, it requires
>> the 3GPP-conforming file header.
>> Attached patch allows reading amrnb and amrwb from (live) streams,
>> fixes ticket #6678.
>>
>> Please comment, Carl Eugen
>
> That seems particularly pointless, since the user has to force the
> demuxers.

Like for any other demuxer without auto-detection?

I wasn't able to "force" reading such a stream without this patch,
am I missing something?

> I don't know what that ticket is

Then it may be better not to comment.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[James Almer]

On 9/27/2017 1:37 PM, wm4 wrote:
> On Wed, 27 Sep 2017 09:17:36 -0700
> Aman Gupta  wrote:
> 
>> On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:
>>
>>> On Tue, 26 Sep 2017 18:08:10 -0700
>>> Aman Gupta  wrote:
>>>  
 From: Aman Gupta 

 ---
  configure|   2 +
  libavcodec/allcodecs.c   |   1 +
  libavcodec/hevc_refs.c   |   3 +
  libavcodec/hevcdec.c |  12 ++-
  libavcodec/vda_vt_internal.h |   1 +
  libavcodec/videotoolbox.c| 203 ++  
>>> +  
  6 files changed, 221 insertions(+), 1 deletion(-)  
>>>
>>> PS: A final patch should make sure these symbols don't cause build
>>> failures with older SDKs:
>>>  
 +case kCMVideoCodecType_HEVC :  
>>>  
 +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;  
>>>
>>>
>>> Maybe with a configure check.
>>>  
>>
>> This is available since macOS 10.11. How far back does ffmpeg support?
> 
> Really not sure. If VideoToolbox support is never detected before
> 10.11, then it's OK.

Videotoolbox is available since 10.8, so this definitely needs a
configure check, much like we're doing for DXVA_PicParams_HEVC in dxva2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 6:37 PM, wm4  wrote:
> On Wed, 27 Sep 2017 09:17:36 -0700
> Aman Gupta  wrote:
>
>> On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:
>>
>> > On Tue, 26 Sep 2017 18:08:10 -0700
>> > Aman Gupta  wrote:
>> >
>> > > From: Aman Gupta 
>> > >
>> > > ---
>> > >  configure|   2 +
>> > >  libavcodec/allcodecs.c   |   1 +
>> > >  libavcodec/hevc_refs.c   |   3 +
>> > >  libavcodec/hevcdec.c |  12 ++-
>> > >  libavcodec/vda_vt_internal.h |   1 +
>> > >  libavcodec/videotoolbox.c| 203 ++
>> > +
>> > >  6 files changed, 221 insertions(+), 1 deletion(-)
>> >
>> > PS: A final patch should make sure these symbols don't cause build
>> > failures with older SDKs:
>> >
>> > > +case kCMVideoCodecType_HEVC :
>> >
>> > > +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;
>> >
>> >
>> > Maybe with a configure check.
>> >
>>
>> This is available since macOS 10.11. How far back does ffmpeg support?
>
> Really not sure. If VideoToolbox support is never detected before
> 10.11, then it's OK.

VT is supported since 10.8, if anything newer is required for this,
then it should get a configure check.

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 18:47:16 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 18:40 GMT+02:00 wm4 :
> > On Wed, 27 Sep 2017 18:08:19 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> Hi!
> >>
> >> The existing amr demuxer does not allow reading streams, it requires
> >> the 3GPP-conforming file header.
> >> Attached patch allows reading amrnb and amrwb from (live) streams,
> >> fixes ticket #6678.
> >>
> >> Please comment, Carl Eugen  
> >
> > That seems particularly pointless, since the user has to force the
> > demuxers.  
> 
> Like for any other demuxer without auto-detection?

Actually no.

> I wasn't able to "force" reading such a stream without this patch,
> am I missing something?

Then maybe there should be a mechanism to force stream parameters, just
like they obviously exist for raw audio/video.

> > I don't know what that ticket is  
> 
> Then it may be better not to comment.

It may be better for you not committing anything if you don't know what
commit messages are.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 18:58 GMT+02:00 wm4 :

> It may be better for you not committing anything if you don't know what
> commit messages are.

I assume this is how you interpret our code-of-conduct
to which you agreed?

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 19:00:04 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 18:58 GMT+02:00 wm4 :
> 
> > It may be better for you not committing anything if you don't know what
> > commit messages are.  
> 
> I assume this is how you interpret our code-of-conduct
> to which you agreed?
> 
> Watch your tongue, Carl Eugen

I don't know, you started with this. I only replied with the equivalent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[Jorge Ramirez-Ortiz]

On 09/27/2017 09:31 AM, wm4 wrote:

On Wed, 27 Sep 2017 09:03:58 -0700
Jorge Ramirez-Ortiz  wrote:


On 09/27/2017 06:01 AM, wm4 wrote:

On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz  wrote:
  

Stopping the codec when no more input is available causes captured
buffers that might be ready to be dequeued to be invalidated.

This commit follows the V4L2 API more closely:
1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
raised by the driver (EOF condition)

This also has the advantage of making the timeout on dequeuing capture
buffers while draining unnecessary.
---
   libavcodec/v4l2_context.c | 162 
++
   1 file changed, 64 insertions(+), 98 deletions(-)

I can't really comment on the logic of this code. So LGTM, just some
minor comments/questions.
  

-/* 0. handle errors */
+/* handle errors */

(Apparently) unrelated cosmetic changes should usually be in separate
patches, but that's probably not worth the trouble in this case.

ACK. will do on any following patches - or I can do it on this one if you want.

Not necessary. In general we prefer separating unrelated changes, but I
think there's a limit to which we have to cause additional work to
follow this rule. (It's mainly in cases where the cosmetic changes are
significant or in completely different code.)


+if (!frame) {
+/* flag that we are draining */
+ctx_to_m2mctx(ctx)->draining = 1;
+
+/* send EOS */
+avbuf->buf.m.planes[0].bytesused = 1;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;
 /* handle the end of stream case */
+} else {
+ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
+if (ret)
+return ret;
+}

Wouldn't it be better to switch the if/else bodies and avoid the
negation in the if condition?

yes
I am going to add a ff_v4l2_buffer_eos() to avoid exposing the bytesused at this
level as well.
will fix

That sounds good. So you're going to send a new patch? Then I'll hold
off applying this one.


yes, just testing.
it is much cleaner this way.

I looked [1] at how the  V4L2_BUF_FLAG_LAST is used in the Venus driver and it 
seems that I could either set bytesused to 0 _OR_ set the  V4L2_BUF_FLAG_LAST 
instead (the API suggests using the flag)
I will do both to make sure all cases are covered in drivers that might not use 
the flag.


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/qcom/venus/helpers.c?h=v4.14-rc2#n325



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



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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 19:02 GMT+02:00 wm4 :
> On Wed, 27 Sep 2017 19:00:04 +0200
> Carl Eugen Hoyos  wrote:
>
>> 2017-09-27 18:58 GMT+02:00 wm4 :
>>
>> > It may be better for you not committing anything if you don't know what
>> > commit messages are.
>>
>> I assume this is how you interpret our code-of-conduct
>> to which you agreed?
>>
>> Watch your tongue, Carl Eugen
>
> I don't know, you started with this. I only replied with the equivalent.

While this does not sound true to me, I wonder how it is related.

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 19:04:26 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 19:02 GMT+02:00 wm4 :
> > On Wed, 27 Sep 2017 19:00:04 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2017-09-27 18:58 GMT+02:00 wm4 :
> >>  
> >> > It may be better for you not committing anything if you don't know what
> >> > commit messages are.  
> >>
> >> I assume this is how you interpret our code-of-conduct
> >> to which you agreed?
> >>
> >> Watch your tongue, Carl Eugen  
> >
> > I don't know, you started with this. I only replied with the equivalent.  
> 
> While this does not sound true to me, 

> I wonder how it is related.

So do I. Maybe you could get back to the technical discussion instead
of this weird nonsense?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Deprecation of visual output devices

[Nicolas George]

Le sextidi 6 vendémiaire, an CCXXVI, Josh de Kock a écrit :
> I see no reason to bring parity to ffplay then.

Nobody asked you to do that.

Why do you want to remove these devices in the first place?

Regards,

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 19:08 GMT+02:00 wm4 :
>  Maybe you could get back to the technical discussion

I wish this were so easy with you:

You first wrote:
> That seems particularly pointless, since the user has
> to force the demuxers.

If I understand this sentence correctly, you agree with me
that it should be as easy as possible for users to receive
amrnb and amrwb streams.

It should be added here that the demuxer always has to be
forced - I don't know if auto-detecting amrnb and amrwb
could be done but it is not part of the patch. (But the patch
is a necessary prerequisite for this hypothetical auto-detection).
The question for the user is though: How to force the codec?

Then you wrote:
> Then maybe there should be a mechanism to force
> stream parameters

How does this not contradict your first statement?
It is probably (I did not immediately succeed) possible
to allow users to first force the amr demuxer and - in
addition - force a codec.
But as we - seemingly - agree above that users should
not have to force everything, I considered that actual
patch much more useful.

When you add the fact that you wrote that you refuse
to read a user report to the contradiction, you will
hopefully understand how futile it appears to have
this technical discussion with you.

> instead of this weird nonsense?

Adding personal insults to every single one of your
emails of course significantly strengthen above
reasoning.

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

[FFmpeg-devel] [PATCHv2] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[Jorge Ramirez-Ortiz]

Stopping the codec when no more input is available causes captured
buffers that might be ready to be invalidated.

This commit follows the V4L2 API more closely:

 1. when ffmpeg indicates EOS (NULL frame or packet size), the
 v4l2_m2m codec will send a dummy buffer to the driver with the
 V4L2_BUF_FLAG_LAST flag.

 2. the v4l2_m2m codec will then continue dequeuing captured buffers
 until EPIPE is raised by the driver (v4l2 EOF condition)

This makes the current timeout on dequeuing capture buffers while
draining unnecessary.
---
 libavcodec/v4l2_buffers.c |  18 +++
 libavcodec/v4l2_context.c | 132 ++
 2 files changed, 58 insertions(+), 92 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..26e7b12 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -255,6 +255,18 @@ static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, 
const uint8_t* data, i
 return 0;
 }
 
+static int v4l2_buffer_set_eos(V4L2Buffer* avbuf)
+{
+/* flag that we are draining to the v4l2_m2m context */
+buf_to_m2mctx(avbuf)->draining = 1;
+
+/* flag to the v4l2 driver - either of these two conditions (use both to 
be safe on old drivers) */
+avbuf->buf.m.planes[0].bytesused = 0;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;
+
+return 0;
+}
+
 /**
  *
  *  V4L2uffer interface
@@ -265,6 +277,9 @@ int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, 
V4L2Buffer* out)
 {
 int i, ret;
 
+if (!frame)
+return v4l2_buffer_set_eos(out);
+
 for(i = 0; i < out->num_planes; i++) {
 ret = v4l2_bufref_to_buf(out, i, frame->buf[i]->data, 
frame->buf[i]->size, frame->buf[i]);
 if (ret)
@@ -356,6 +371,9 @@ int ff_v4l2_buffer_avpkt_to_buf(const AVPacket *pkt, 
V4L2Buffer *out)
 {
 int ret;
 
+if (!pkt->size)
+return v4l2_buffer_set_eos(out);
+
 ret = v4l2_bufref_to_buf(out, 0, pkt->data, pkt->size, pkt->buf);
 if (ret)
 return ret;
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index d675c55..ef3d263 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -189,40 +189,6 @@ reinit_run:
 return 1;
 }
 
-static int v4l2_stop_decode(V4L2Context *ctx)
-{
-struct v4l2_decoder_cmd cmd = {
-.cmd = V4L2_DEC_CMD_STOP,
-};
-int ret;
-
-ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_DECODER_CMD, &cmd);
-if (ret) {
-/* DECODER_CMD is optional */
-if (errno == ENOTTY)
-return ff_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
-}
-
-return 0;
-}
-
-static int v4l2_stop_encode(V4L2Context *ctx)
-{
-struct v4l2_encoder_cmd cmd = {
-.cmd = V4L2_ENC_CMD_STOP,
-};
-int ret;
-
-ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_ENCODER_CMD, &cmd);
-if (ret) {
-/* ENCODER_CMD is optional */
-if (errno == ENOTTY)
-return ff_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
-}
-
-return 0;
-}
-
 static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, int timeout)
 {
 struct v4l2_plane planes[VIDEO_MAX_PLANES];
@@ -236,6 +202,13 @@ static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, 
int timeout)
 
 if (V4L2_TYPE_IS_OUTPUT(ctx->type))
 pfd.events =  POLLOUT | POLLWRNORM;
+else {
+/* on the capture queue */
+if (ctx_to_m2mctx(ctx)->draining) {
+/* ignore driver requests for more input and just wait for a valid 
frame */
+pfd.events = POLLIN | POLLRDNORM | POLLPRI;
+}
+}
 
 for (;;) {
 ret = poll(&pfd, 1, timeout);
@@ -243,50 +216,45 @@ static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, 
int timeout)
 break;
 if (errno == EINTR)
 continue;
-
-/* timeout is being used to indicate last valid bufer when draining */
-if (ctx_to_m2mctx(ctx)->draining)
-ctx->done = 1;
-
 return NULL;
 }
 
-/* 0. handle errors */
+/* handle errors */
 if (pfd.revents & POLLERR) {
 av_log(logger(ctx), AV_LOG_WARNING, "%s POLLERR\n", ctx->name);
 return NULL;
 }
 
-/* 1. handle resolution changes */
+/* handle resolution changes */
 if (pfd.revents & POLLPRI) {
 ret = v4l2_handle_event(ctx);
 if (ret < 0) {
 /* if re-init failed, abort */
-ctx->done = EINVAL;
+ctx->done = 1;
 return NULL;
 }
 if (ret) {
 /* if re-init was successfull drop the buffer (if there was one)
- * since we had to reconfigure capture (unmap all buffers)
- */
+ * since we had to reconfigure capture (unmap all buffers) */
 return NULL;
 }
 }
 
-/* 2. dequeue the buffer */
+/* dequeue the buffer or provide more input */
 if

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 19:22:37 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 19:08 GMT+02:00 wm4 :
> >  Maybe you could get back to the technical discussion  
> 
> I wish this were so easy with you:

Well, it certainly isn't with you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Ronald S. Bultje]

Hi guys,

On Wed, Sep 27, 2017 at 1:32 PM, wm4  wrote:

> On Wed, 27 Sep 2017 19:22:37 +0200
> Carl Eugen Hoyos  wrote:
>
> > 2017-09-27 19:08 GMT+02:00 wm4 :
> > >  Maybe you could get back to the technical discussion
> >
> > I wish this were so easy with you:
>
> Well, it certainly isn't with you.


OK, this discussion is over between you two, please stop it.

@Carl Eugen: I've read the bug report. It's intruiging that the existing
demuxer (as you mentioned, it expects a prefix) works with unicast but not
multicast input. Do you know what's causing this difference?

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 19:46 GMT+02:00 Ronald S. Bultje :

> @Carl Eugen: I've read the bug report.

Thank you; sorry that imo, this cannot help in this case;-(
The relevant issue is that live streams or truncated
amr files cannot be handled by the existing demuxer
although they work if the properties are forced with
the new demuxers.

The alternative is to allow forcing properties for the
existing demuxer, this has the disadvantage that it is
more difficult to use (and it would make hypothetical
auto-detection more messy).

> It's intruiging that the existing demuxer (as you mentioned,
> it expects a prefix) works with unicast but not
> multicast input.

I don't think this is correct (as in: "This is impossible") but
I may of course miss something ;-)

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 20:09 GMT+02:00 Carl Eugen Hoyos :
> 2017-09-27 19:46 GMT+02:00 Ronald S. Bultje :

>> It's intruiging that the existing demuxer (as you mentioned,
>> it expects a prefix) works with unicast but not
>> multicast input.
>
> I don't think this is correct (as in: "This is impossible") but
> I may of course miss something ;-)

It of course works if you start the listener first but this
doesn't count imo.

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

[FFmpeg-devel] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Carl Eugen Hoyos]

Hi!

No opinion here, this was reported twice on trac this week, I don't
know if there was really more than one user affected.

Please comment, Carl Eugen
From 256d46d2479b19103fab3f79f34f6ae597ae402c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Sep 2017 20:15:13 +0200
Subject: [PATCH] lavc/fdk-aacenc: Print an error if (e)ld is requested without
 signaling.

Related to ticket #6683.
---
 libavcodec/libfdk-aacenc.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 0e2051b..1477ad41 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -244,6 +244,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
  * implicit signaling if using ADTS. */
 if (s->signaling < 0)
 s->signaling = avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER ? 2 : 0;
+if (!s->signaling && (avctx->profile == FF_PROFILE_AAC_LD || avctx->profile == FF_PROFILE_AAC_ELD))
+av_log(avctx, AV_LOG_ERROR, "Signaling required for LD and ELD, initialization will fail.\n");
 
 if ((err = aacEncoder_SetParam(s->handle, AACENC_SIGNALING_MODE,
s->signaling)) != AACENC_OK) {
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 1/2] configure: disable libxcb dependent features if libxcb is not enabled

[James Almer]

---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index a4baeb3b2a..1676215146 100755
--- a/configure
+++ b/configure
@@ -6186,7 +6186,7 @@ if enabled libcdio; then
 die "ERROR: No usable libcdio/cdparanoia found"
 fi
 
-enabled libxcb && check_pkg_config "xcb >= 1.4" xcb/xcb.h xcb_connect || 
disable libxcb
+enabled libxcb && check_pkg_config "xcb >= 1.4" xcb/xcb.h xcb_connect || 
disable libxcb libxcb_shm libxcb_shape libxcb_xfixes
 
 if enabled libxcb; then
 
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/2] configure: simplify checks for libxcb dependent features

[James Almer]

---
 configure | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/configure b/configure
index 1676215146..5b3e2ecdbf 100755
--- a/configure
+++ b/configure
@@ -6189,13 +6189,9 @@ fi
 enabled libxcb && check_pkg_config "xcb >= 1.4" xcb/xcb.h xcb_connect || 
disable libxcb libxcb_shm libxcb_shape libxcb_xfixes
 
 if enabled libxcb; then
-
-enabled libxcb_shm&& check_pkg_config xcb-shmxcb/shm.h
xcb_shm_attach  || disable libxcb_shm
-enabled libxcb_shape  && check_pkg_config xcb-shape  xcb/shape.h  
xcb_shape_get_rectangles|| disable libxcb_shape
-enabled libxcb_xfixes && check_pkg_config xcb-xfixes xcb/xfixes.h 
xcb_xfixes_get_cursor_image || disable libxcb_xfixes
-
-add_cflags $xcb_cflags $xcb_shm_cflags $xcb_xfixes_cflags $xcb_shape_cflags
-add_extralibs $xcb_extralibs $xcb_shm_extralibs $xcb_xfixes_extralibs 
$xcb_shape_extralibs
+enabled libxcb_shm&& use_pkg_config xcb-shmxcb/shm.h
xcb_shm_attach  || disable libxcb_shm
+enabled libxcb_shape  && use_pkg_config xcb-shape  xcb/shape.h  
xcb_shape_get_rectangles|| disable libxcb_shape
+enabled libxcb_xfixes && use_pkg_config xcb-xfixes xcb/xfixes.h 
xcb_xfixes_get_cursor_image || disable libxcb_xfixes
 fi
 
 check_func_headers "windows.h" CreateDIBSection "$gdigrab_indev_extralibs"
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Ronald S. Bultje]

Hi,

On Wed, Sep 27, 2017 at 2:10 PM, Carl Eugen Hoyos 
wrote:

> 2017-09-27 20:09 GMT+02:00 Carl Eugen Hoyos :
> > 2017-09-27 19:46 GMT+02:00 Ronald S. Bultje :
>
> >> It's intruiging that the existing demuxer (as you mentioned,
> >> it expects a prefix) works with unicast but not
> >> multicast input.
> >
> > I don't think this is correct (as in: "This is impossible") but
> > I may of course miss something ;-)
>
> It of course works if you start the listener first but this
> doesn't count imo.


Ah, that indeed explains anything, thank you. (In terms of whether to
update the existing demuxer or add a new one, I have no preference.)

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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Anonymous Maarten]

>>* Hey,
** Building the static ffmpeg library using vcpkg is currently
broken [1][2].
*>>* This is mainly due to the fact that the built static libraries are .a files
*>>* with lib prefixes.
** The attached patch sets the lib prefix to "" and the lib suffix
to ".lib".
** Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
*>>* Edition on Windows 10.
*>>* The resu*lted libraries link correctly to my application.
>>
> Carl Eugen Hoyos:
> Did this work with older versions of any of the involved tools
(including FFmpeg)?

3.3.3 is the first version I have tried to build using vcpkg. [1]
I guess 'no' is the answer to your question.

> Hendrik Leppkes:
> This would break the workflow for everyone that is currently working with the 
> current names, however.

I would be equally happy if there would be a way (using configure
arguments?) to set these two parameters.

[1] 
https://github.com/Microsoft/vcpkg/blob/084b1afe9af1690916fab95bbb80c6891109f0fc/ports/ffmpeg/CONTROL


Thanks.

On 27 September 2017 at 16:43, Anonymous Maarten <
anonymous.maar...@gmail.com> wrote:

> Hey,
>
> Building the static ffmpeg library using vcpkg is currently broken [1][2].
> This is mainly due to the fact that the built static libraries are .a
> files with lib prefixes.
>
> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>
> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
> Edition on Windows 10.
> The resulted libraries link correctly to my application.
>
> [1] https://github.com/Microsoft/vcpkg/blob/084b1afe9af1690916fab95bbb80c6
> 891109f0fc/ports/ffmpeg/portfile.cmake#L1-L4
> [2] https://github.com/Microsoft/vcpkg/issues/1821
>
> Maarten,
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mips: preload data in hevc sao edge 45 degree filter msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 07:43:48AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thanks

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

No great genius has ever existed without some touch of madness. -- 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] avcodec/mips: Removed generic function call in avc intra msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 07:48:51AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc weighted mc msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 08:49:15AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thx

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

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



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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma vert mc msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 08:49:24AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thx

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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/mips: Improve avc put mc 20, 01 and 03 msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 11:56:20AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thx


 [..]
--
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] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Mateusz]

W dniu 2017-09-27 o 17:40, Hendrik Leppkes pisze:
> On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
>  wrote:
>> Hey,
>>
>> Building the static ffmpeg library using vcpkg is currently broken [1][2].
>> This is mainly due to the fact that the built static libraries are .a files
>> with lib prefixes.
>>
>> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>>
>> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
>> Edition on Windows 10.
>> The resulted libraries link correctly to my application.
>>
> This would break the workflow for everyone that is currently working
> with the current names, however.

For gcc it breaks nothing (it still makes lib...a files), for msvc it is 
improvement.
Is there any person happy with lib...a names for lib in msvc?

Mateusz


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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 10:11 PM, Mateusz  wrote:
> W dniu 2017-09-27 o 17:40, Hendrik Leppkes pisze:
>> On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
>>  wrote:
>>> Hey,
>>>
>>> Building the static ffmpeg library using vcpkg is currently broken [1][2].
>>> This is mainly due to the fact that the built static libraries are .a files
>>> with lib prefixes.
>>>
>>> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>>>
>>> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
>>> Edition on Windows 10.
>>> The resulted libraries link correctly to my application.
>>>
>> This would break the workflow for everyone that is currently working
>> with the current names, however.
>
> For gcc it breaks nothing (it still makes lib...a files), for msvc it is 
> improvement.
> Is there any person happy with lib...a names for lib in msvc?
>

It doesn't really matter if you're happy with it or not, if you change
it stuff will still break.

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

Re: [FFmpeg-devel] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 8:18 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> No opinion here, this was reported twice on trac this week, I don't
> know if there was really more than one user affected.

"Signaling" as a single word isn't very descriptive, and should
probably be expanded.

Additionally, if its on -1 (default/auto), it should probably
automatically use a mode that works with the requested profile.

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

Re: [FFmpeg-devel] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Carl Eugen Hoyos]

2017-09-27 22:30 GMT+02:00 Hendrik Leppkes :
> On Wed, Sep 27, 2017 at 8:18 PM, Carl Eugen Hoyos  wrote:

>> No opinion here, this was reported twice on trac this week, I don't
>> know if there was really more than one user affected.
>
> "Signaling" as a single word isn't very descriptive, and should
> probably be expanded.

I don't disagree, do you have a suggestion?

> Additionally, if its on -1 (default/auto), it should probably
> automatically use a mode that works with the requested profile.

Is that possible? fdk refuses explicit signaling here for (e)ld.

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

Re: [FFmpeg-devel] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 10:39 PM, Carl Eugen Hoyos  wrote:
> 2017-09-27 22:30 GMT+02:00 Hendrik Leppkes :
>> On Wed, Sep 27, 2017 at 8:18 PM, Carl Eugen Hoyos  wrote:
>
>>> No opinion here, this was reported twice on trac this week, I don't
>>> know if there was really more than one user affected.
>>
>> "Signaling" as a single word isn't very descriptive, and should
>> probably be expanded.
>
> I don't disagree, do you have a suggestion?
>
>> Additionally, if its on -1 (default/auto), it should probably
>> automatically use a mode that works with the requested profile.
>
> Is that possible? fdk refuses explicit signaling here for (e)ld.
>

You cannot put ELD into ADTS, so that combination is entirely
impossible, and maybe a better thing to check and error out on first.
And when you use "raw" mode with a global header, explicit signaling
should also work.

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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Anonymous Maarten]

The current situation is inconsistent.
It creates .lib/.dlls files for dynamic libraries and .a files for
static libraries.
This complicates e.g. detecting ffmpeg using cmake needlessly.
Changing this behavior would be a net gain.

I would also be happy if there would be a (configure) switch to
manually set the pre/suffix.

Maarten

On 27 September 2017 at 22:26, Hendrik Leppkes  wrote:
> On Wed, Sep 27, 2017 at 10:11 PM, Mateusz  wrote:
>> W dniu 2017-09-27 o 17:40, Hendrik Leppkes pisze:
>>> On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
>>>  wrote:
 Hey,

 Building the static ffmpeg library using vcpkg is currently broken [1][2].
 This is mainly due to the fact that the built static libraries are .a files
 with lib prefixes.

 The attached patch sets the lib prefix to "" and the lib suffix to ".lib".

 Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
 Edition on Windows 10.
 The resulted libraries link correctly to my application.

>>> This would break the workflow for everyone that is currently working
>>> with the current names, however.
>>
>> For gcc it breaks nothing (it still makes lib...a files), for msvc it is 
>> improvement.
>> Is there any person happy with lib...a names for lib in msvc?
>>
>
> It doesn't really matter if you're happy with it or not, if you change
> it stuff will still break.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] prores: Always assume limited range

[Vittorio Giovara]

As defined by the spcifications
---
 libavcodec/proresdec_lgpl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/proresdec_lgpl.c b/libavcodec/proresdec_lgpl.c
index bc5bdb5a4d..c86d433f50 100644
--- a/libavcodec/proresdec_lgpl.c
+++ b/libavcodec/proresdec_lgpl.c
@@ -177,6 +177,7 @@ static int decode_frame_header(ProresContext *ctx, const 
uint8_t *buf,
 avctx->color_primaries = buf[14];
 avctx->color_trc   = buf[15];
 avctx->colorspace  = buf[16];
+avctx->color_range = AVCOL_RANGE_MPEG;
 
 ctx->qmat_changed = 0;
 ptr   = buf + 20;
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] prores: Always assume limited range

[wm4]

On Wed, 27 Sep 2017 17:28:12 -0400
Vittorio Giovara  wrote:

> As defined by the spcifications
> ---
>  libavcodec/proresdec_lgpl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/proresdec_lgpl.c b/libavcodec/proresdec_lgpl.c
> index bc5bdb5a4d..c86d433f50 100644
> --- a/libavcodec/proresdec_lgpl.c
> +++ b/libavcodec/proresdec_lgpl.c
> @@ -177,6 +177,7 @@ static int decode_frame_header(ProresContext *ctx, const 
> uint8_t *buf,
>  avctx->color_primaries = buf[14];
>  avctx->color_trc   = buf[15];
>  avctx->colorspace  = buf[16];
> +avctx->color_range = AVCOL_RANGE_MPEG;
>  
>  ctx->qmat_changed = 0;
>  ptr   = buf + 20;

LGTM. (A bit disgusted at Prores...)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: fix profile search when disable exact profile match.

[Mark Thompson]

On 21/09/17 08:22, Jun Zhao wrote:
> From d7dc5c00692302e810412dea44ae3d2f122fb9a4 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 21 Sep 2017 02:44:42 -0400
> Subject: [PATCH 2/2] lavc/vaapi_decode: fix profile search when disable exact
>  profile match.
> 
> When disable exact profile match, alway use the profile found by
> codecid.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_decode.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index cf58aae4c6..98b00e3637 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -329,6 +329,10 @@ static int vaapi_decode_make_config(AVCodecContext 
> *avctx)
>  if (exact_match)
>  break;
>  alt_profile = vaapi_profile_map[i].codec_profile;
> +
> +if (avctx->hwaccel_flags &
> +AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH)
> +break;
>  }
>  }
>  av_freep(&profile_list);
> -- 
> 2.11.0
> 

An exact match might exist later in the list.  Consider an H.264 high input - 
this change can choose H.264 constrained baseline instead even if H.264 high is 
present.

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

Re: [FFmpeg-devel] [PATCH] [PATCH v7] Add support for RockChip Media Process Platform

[Mark Thompson]

On 24/09/17 06:39, LongChair . wrote:
> From: Lionel CHAZALLON 
> 
> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that 
> allows drm / dmabuf usage.
> Was tested on RK3288 (TinkerBoard) and RK3328.
> 
> Changes from Previous patch :
> - Frame colorspace info is now filled.
> - Frame interlacing is now filled (Note : currently had a bug in mpp which 
> will be fixed soon by rockchip, will set the to progressive).
> - hw_frame_context returns none as format for the rockchip specific 10 bits.
> - Added support for VP9 codec.
> - removed MPG4 codec : it seems that MPP doesn't handle properly all the 
> MPEG4 formats
> - removed MPEG2 : there is still an issue with MPEG2 decoder, this is being 
> investigated by RockChip.
> - the ION format has been kept for MPP init (rather than DRM) as this is the 
> only one working right, using DRM format will cause assertions upon close.
> - Other minor comments have been taken into account
> ---
>  Changelog  |   2 +-
>  configure  |  15 ++
>  libavcodec/Makefile|   4 +
>  libavcodec/allcodecs.c |   4 +
>  libavcodec/rkmppdec.c  | 591 
> +
>  5 files changed, 615 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/rkmppdec.c

Applied (with minor changes as discussed on IRC, version bump, and fixup for 
recent merge to configure).

Thanks,

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

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Marton Balint]

On Wed, 27 Sep 2017, Jeyapal, Karthick wrote:


Sorry for the late reply, the last was busy week. Here are some more
comments:


Thanks for your comments. Please find the updated patch attached with your 
comments incorporated.


Sorry, still not quite there... Here are some further comments:


From 9a572cb8b4ea599ee6bc1eedd6c7ca6868cfe0c6 Mon Sep 17 00:00:00 2001
From: Karthick J 
Date: Wed, 30 Aug 2017 11:43:16 +0530
Subject: [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from
 VANC

Signed-off-by: Karthick J 
---
 libavcodec/avcodec.h |   7 ++
 libavcodec/avpacket.c|   1 +
 libavcodec/version.h |   2 +-
 libavdevice/decklink_dec.cpp | 196 +++
 4 files changed, 188 insertions(+), 18 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 513236a..d4a458f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1600,6 +1600,13 @@ enum AVPacketSideDataType {
 AV_PKT_DATA_CONTENT_LIGHT_LEVEL,

 /**
+ * ATSC A53 Part 4 Closed Captions. This metadata should be associated with
+ * a video stream. A53 CC bitstream is stored as uint8_t in 
AVPacketSideData.data.
+ * The number of bytes of CC data is AVPacketSideData.size.
+ */
+AV_PKT_DATA_A53_CC,


I forgot to mention that you should also add a note about this to 
doc/APIChanges, sorry.


+
+/**
  * The number of side data elements (in fact a bit more than it).
  * This is not part of the public API/ABI in the sense that it may
  * change when new side data types are added.
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 5ce3228..a292b15 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -387,6 +387,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_MASTERING_DISPLAY_METADATA: return "Mastering display 
metadata";
 case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light level 
metadata";
 case AV_PKT_DATA_SPHERICAL:  return "Spherical Mapping";
+case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
 }
 return NULL;
 }
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 22cab7b..29cdb85 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@

 #define LIBAVCODEC_VERSION_MAJOR  57
 #define LIBAVCODEC_VERSION_MINOR 104
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101

 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 38e6bd8..a24f563 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -1,6 +1,7 @@
 /*
  * Blackmagic DeckLink input
  * Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
+ * Copyright (c) 2014 Rafaël Carré
  * Copyright (c) 2017 Akamai Technologies, Inc.
  *
  * This file is part of FFmpeg.
@@ -105,6 +106,42 @@ static int get_vanc_line_idx(BMDDisplayMode mode)
 return i - 1;
 }

+static inline uint16_t parity (uint16_t x)
+{
+uint16_t i;
+for (i = 4 * sizeof (x); i > 0; i /= 2)
+x ^= x >> i;
+return x & 1;
+}
+
+static inline void clear_parity_bits(uint16_t *buf, int len) {
+int i;
+for (i = 0; i < len; i++)
+buf[i] &= 0xff;
+}
+
+static int check_vanc_parity_checksum(uint16_t *buf, int len, uint16_t 
checksum) {
+int i;
+uint32_t vanc_sum;


uint16_t is enough, it does not matter if it overflows. Also don't forget to
initialize this to 0, the previous patch had that.


+for (i = 3; i < len - 1; i++) {
+uint16_t v = buf[i];
+int np = v >> 8;
+int p = parity(v & 0xff);
+if ((!!p ^ !!(v & 0x100)) || (np != 1 && np != 2)) {
+// Parity check failed
+return -1;
+}
+vanc_sum += v;
+}
+vanc_sum &= 0x1ff;
+vanc_sum |= ((~vanc_sum & 0x100) << 1);
+if (checksum != vanc_sum) {
+// Checksum verification failed
+return -1;
+}
+return 0;
+}
+
 /* The 10-bit VANC data is packed in V210, we only need the luma component. */
 static void extract_luma_from_v210(uint16_t *dst, const uint8_t *src, int 
width)
 {
@@ -232,19 +269,148 @@ static uint8_t* 
teletext_data_unit_from_ancillary_packet(uint16_t *py, uint16_t
 return tgt;
 }

-static uint8_t* teletext_data_unit_from_vanc_data(uint16_t *py, uint8_t *tgt, 
int64_t wanted_lines)
+uint8_t *vanc_to_cc(AVFormatContext *avctx, uint16_t *buf, size_t words,
+unsigned &cc_count)
 {
-uint16_t *pend = py + 1920;
+size_t i, len = (buf[5] & 0xff) + 6 + 1;
+uint8_t cdp_sum, rate;
+uint16_t hdr, ftr;
+uint8_t *cc;
+uint16_t *cdp = &buf[6]; // CDP follows
+if (cdp[0] != 0x96 || cdp[1] != 0x69) {
+av_log(avctx, AV_LOG_WARNING, "Invalid CDP header 0x%.2x 0x%.2x", 
cdp[0],

[FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: use AV_WB16 where possible

[Aman Gupta]

From: Aman Gupta 

additional changes to hevc patchset, as suggested on-list

if these look fine, I will squash into previous patchset and push it to
master.
---
 libavcodec/videotoolbox.c | 27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 078174cc61..c96200cbdb 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -165,10 +165,8 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
  ptlc.non_packed_constraint_flag << 5 |
  ptlc.frame_only_constraint_flag << 4);
 AV_W8(p + 7, 0);
-AV_W8(p + 8, 0);
-AV_W8(p + 9, 0);
-AV_W8(p + 10, 0);
-AV_W8(p + 11, 0);
+AV_WB16(p + 8, 0);
+AV_WB16(p + 10, 0);
 
 /* unsigned int(8) general_level_idc; */
 AV_W8(p + 12, ptlc.level_idc);
@@ -215,8 +213,7 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
 AV_W8(p + 18, (sps->bit_depth_chroma - 8) | 0xfc);
 
 /* bit(16) avgFrameRate; */
-AV_W8(p + 19, 0);
-AV_W8(p + 20, 0);
+AV_WB16(p + 19, 0);
 
 /*
  * bit(2) constantFrameRate;
@@ -242,11 +239,9 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
 AV_W8(p, 1 << 7 |
  HEVC_NAL_VPS & 0x3f);
 /* unsigned int(16) numNalus; */
-AV_W8(p + 1, 0);
-AV_W8(p + 2, 1);
+AV_WB16(p + 1, 1);
 /* unsigned int(16) nalUnitLength; */
-AV_W8(p + 3, vps->data_size >> 8);
-AV_W8(p + 4, vps->data_size & 0x);
+AV_WB16(p + 3, vps->data_size);
 /* bit(8*nalUnitLength) nalUnit; */
 memcpy(p + 5, vps->data, vps->data_size);
 p += 5 + vps->data_size;
@@ -254,24 +249,20 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
 /* sps */
 AV_W8(p, 1 << 7 |
  HEVC_NAL_SPS & 0x3f);
-AV_W8(p + 1, 0);
-AV_W8(p + 2, 1);
-AV_W8(p + 3, sps->data_size >> 8);
-AV_W8(p + 4, sps->data_size & 0x);
+AV_WB16(p + 1, 1);
+AV_WB16(p + 3, sps->data_size);
 memcpy(p + 5, sps->data, sps->data_size);
 p += 5 + sps->data_size;
 
 /* pps */
 AV_W8(p, 1 << 7 |
  HEVC_NAL_PPS & 0x3f);
-AV_W8(p + 1, num_pps >> 8);
-AV_W8(p + 2, num_pps & 0x);
+AV_WB16(p + 1, num_pps);
 p += 3;
 for (i = 0; i < MAX_PPS_COUNT; i++) {
 if (h->ps.pps_list[i]) {
 const HEVCPPS *pps = (const HEVCPPS *)h->ps.pps_list[i]->data;
-AV_W8(p + 0, pps->data_size >> 8);
-AV_W8(p + 1, pps->data_size & 0x);
+AV_WB16(p, pps->data_size);
 memcpy(p + 2, pps->data, pps->data_size);
 p += 2 + pps->data_size;
 }
-- 
2.13.5 (Apple Git-94)

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

[FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[Aman Gupta]

From: Aman Gupta 

---
 configure | 5 -
 libavcodec/videotoolbox.c | 4 
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index d353e9d824..aae23bf38f 100755
--- a/configure
+++ b/configure
@@ -2073,6 +2073,7 @@ TOOLCHAIN_FEATURES="
 
 TYPES_LIST="
 CONDITION_VARIABLE_Ptr
+kCMVideoCodecType_HEVC
 socklen_t
 struct_addrinfo
 struct_group_source_req
@@ -5809,8 +5810,10 @@ enabled avfoundation && {
 check_lib avfoundation CoreGraphics/CoreGraphics.h   
CGGetActiveDisplayList "-framework CoreGraphics" ||
 check_lib avfoundation ApplicationServices/ApplicationServices.h 
CGGetActiveDisplayList "-framework ApplicationServices"; }
 
-enabled videotoolbox &&
+enabled videotoolbox && {
 check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
"-framework CoreServices"
+check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_HEVC 
"-framework CoreMedia"
+}
 
 check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
 
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index c96200cbdb..e62452c078 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -40,6 +40,10 @@
 #  define kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder 
CFSTR("RequireHardwareAcceleratedVideoDecoder")
 #endif
 
+#if !HAVE_KCMVIDEOCODECTYPE_HEVC
+enum { kCMVideoCodecType_HEVC = 'hvc1' };
+#endif
+
 #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
 
 static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
-- 
2.13.5 (Apple Git-94)

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: use AV_WB16 where possible

[James Almer]

On 9/27/2017 7:19 PM, Aman Gupta wrote:
> From: Aman Gupta 
> 
> additional changes to hevc patchset, as suggested on-list
> 
> if these look fine, I will squash into previous patchset and push it to
> master.
> ---
>  libavcodec/videotoolbox.c | 27 +--
>  1 file changed, 9 insertions(+), 18 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 078174cc61..c96200cbdb 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -165,10 +165,8 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>   ptlc.non_packed_constraint_flag << 5 |
>   ptlc.frame_only_constraint_flag << 4);
>  AV_W8(p + 7, 0);
> -AV_W8(p + 8, 0);
> -AV_W8(p + 9, 0);
> -AV_W8(p + 10, 0);
> -AV_W8(p + 11, 0);
> +AV_WB16(p + 8, 0);
> +AV_WB16(p + 10, 0);

AV_WB32(p + 8, 0)

or even AV_WN32(p + 8, 0) since it's 0 and endianness doesn't matter.

>  
>  /* unsigned int(8) general_level_idc; */
>  AV_W8(p + 12, ptlc.level_idc);
> @@ -215,8 +213,7 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  AV_W8(p + 18, (sps->bit_depth_chroma - 8) | 0xfc);
>  
>  /* bit(16) avgFrameRate; */
> -AV_W8(p + 19, 0);
> -AV_W8(p + 20, 0);
> +AV_WB16(p + 19, 0);
>  
>  /*
>   * bit(2) constantFrameRate;
> @@ -242,11 +239,9 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  AV_W8(p, 1 << 7 |
>   HEVC_NAL_VPS & 0x3f);
>  /* unsigned int(16) numNalus; */
> -AV_W8(p + 1, 0);
> -AV_W8(p + 2, 1);
> +AV_WB16(p + 1, 1);
>  /* unsigned int(16) nalUnitLength; */
> -AV_W8(p + 3, vps->data_size >> 8);
> -AV_W8(p + 4, vps->data_size & 0x);
> +AV_WB16(p + 3, vps->data_size);
>  /* bit(8*nalUnitLength) nalUnit; */
>  memcpy(p + 5, vps->data, vps->data_size);
>  p += 5 + vps->data_size;
> @@ -254,24 +249,20 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  /* sps */
>  AV_W8(p, 1 << 7 |
>   HEVC_NAL_SPS & 0x3f);
> -AV_W8(p + 1, 0);
> -AV_W8(p + 2, 1);
> -AV_W8(p + 3, sps->data_size >> 8);
> -AV_W8(p + 4, sps->data_size & 0x);
> +AV_WB16(p + 1, 1);
> +AV_WB16(p + 3, sps->data_size);
>  memcpy(p + 5, sps->data, sps->data_size);
>  p += 5 + sps->data_size;
>  
>  /* pps */
>  AV_W8(p, 1 << 7 |
>   HEVC_NAL_PPS & 0x3f);
> -AV_W8(p + 1, num_pps >> 8);
> -AV_W8(p + 2, num_pps & 0x);
> +AV_WB16(p + 1, num_pps);
>  p += 3;
>  for (i = 0; i < MAX_PPS_COUNT; i++) {
>  if (h->ps.pps_list[i]) {
>  const HEVCPPS *pps = (const HEVCPPS *)h->ps.pps_list[i]->data;
> -AV_W8(p + 0, pps->data_size >> 8);
> -AV_W8(p + 1, pps->data_size & 0x);
> +AV_WB16(p, pps->data_size);
>  memcpy(p + 2, pps->data, pps->data_size);
>  p += 2 + pps->data_size;
>  }
> 

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

Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[James Almer]

On 9/27/2017 7:19 PM, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  configure | 5 -
>  libavcodec/videotoolbox.c | 4 
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index d353e9d824..aae23bf38f 100755
> --- a/configure
> +++ b/configure
> @@ -2073,6 +2073,7 @@ TOOLCHAIN_FEATURES="
>  
>  TYPES_LIST="
>  CONDITION_VARIABLE_Ptr
> +kCMVideoCodecType_HEVC

Remove this line and read below.

>  socklen_t
>  struct_addrinfo
>  struct_group_source_req
> @@ -5809,8 +5810,10 @@ enabled avfoundation && {
>  check_lib avfoundation CoreGraphics/CoreGraphics.h   
> CGGetActiveDisplayList "-framework CoreGraphics" ||
>  check_lib avfoundation ApplicationServices/ApplicationServices.h 
> CGGetActiveDisplayList "-framework ApplicationServices"; }
>  
> -enabled videotoolbox &&
> +enabled videotoolbox && {
>  check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
> "-framework CoreServices"
> +check_func_headers CoreMedia/CMFormatDescription.h 
> kCMVideoCodecType_HEVC "-framework CoreMedia"

Look how DXVA_PicParams_HEVC is checked and try to do the same instead.

> +}
>  
>  check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
>  
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index c96200cbdb..e62452c078 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -40,6 +40,10 @@
>  #  define 
> kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder 
> CFSTR("RequireHardwareAcceleratedVideoDecoder")
>  #endif
>  
> +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
> +enum { kCMVideoCodecType_HEVC = 'hvc1' };
> +#endif

The correct thing to do is adding kCMVideoCodecType_HEVC to
hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
that don't support it since, i assume, no computer with MacOS 10.8 will
be able to play hevc videos anyway.

> +
>  #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
>  
>  static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
> 

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

Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[Aman Gupta]

On Wed, Sep 27, 2017 at 3:52 PM, James Almer  wrote:

> On 9/27/2017 7:19 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  configure | 5 -
> >  libavcodec/videotoolbox.c | 4 
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index d353e9d824..aae23bf38f 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2073,6 +2073,7 @@ TOOLCHAIN_FEATURES="
> >
> >  TYPES_LIST="
> >  CONDITION_VARIABLE_Ptr
> > +kCMVideoCodecType_HEVC
>
> Remove this line and read below.
>
> >  socklen_t
> >  struct_addrinfo
> >  struct_group_source_req
> > @@ -5809,8 +5810,10 @@ enabled avfoundation && {
> >  check_lib avfoundation CoreGraphics/CoreGraphics.h
>  CGGetActiveDisplayList "-framework CoreGraphics" ||
> >  check_lib avfoundation ApplicationServices/ApplicationServices.h
> CGGetActiveDisplayList "-framework ApplicationServices"; }
> >
> > -enabled videotoolbox &&
> > +enabled videotoolbox && {
> >  check_lib coreservices CoreServices/CoreServices.h
> UTGetOSTypeFromString "-framework CoreServices"
> > +check_func_headers CoreMedia/CMFormatDescription.h
> kCMVideoCodecType_HEVC "-framework CoreMedia"
>
> Look how DXVA_PicParams_HEVC is checked and try to do the same instead.
>

I don't think check_type will work because kCMVideoCodecType_HEVC is
defined as an enum.


>
> > +}
> >
> >  check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
> >
> > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> > index c96200cbdb..e62452c078 100644
> > --- a/libavcodec/videotoolbox.c
> > +++ b/libavcodec/videotoolbox.c
> > @@ -40,6 +40,10 @@
> >  #  define 
> > kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
> CFSTR("RequireHardwareAcceleratedVideoDecoder")
> >  #endif
> >
> > +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
> > +enum { kCMVideoCodecType_HEVC = 'hvc1' };
> > +#endif
>
> The correct thing to do is adding kCMVideoCodecType_HEVC to
> hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
> that don't support it since, i assume, no computer with MacOS 10.8 will
> be able to play hevc videos anyway.
>

kCMVideoCodecType_HEVC is defined on 10.11 and 10.12, even though those
machines can't play hevc either. I don't think it should matter what mac
version you built ffmpeg on, only whether or not the machine where the
binary is being executed supports HEVC.

videotoolbox.c and videotoolboxenc.c both use runtime stubs for various
constants
like kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder
which are not defined consistently across different versions of macOS, so I
followed a similar pattern here.

That said, I don't have a strong preference and can make hevc_videotoolbox
depend on the symbol instead. My main goal is to allow binaries compiled on
10.12 to use HEVC on 10.13, and that will work with either configuration.


>
> > +
> >  #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
> >
> >  static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
> >
>
> ___
> 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] prores: Always assume limited range

[Kieran O Leary]

On Wed, Sep 27, 2017 at 10:28 PM, Vittorio Giovara
 wrote:
> As defined by the spcifications

Is this the paywalled SMPTE spec? I don't see any mention of it in the
openly available whitepaper,
https://images.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[wm4]

On Wed, 27 Sep 2017 19:52:13 -0300
James Almer  wrote:

> > +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
> > +enum { kCMVideoCodecType_HEVC = 'hvc1' };
> > +#endif  
> 
> The correct thing to do is adding kCMVideoCodecType_HEVC to
> hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
> that don't support it since, i assume, no computer with MacOS 10.8 will
> be able to play hevc videos anyway.

SDK version != OS you build on != target machine

So this has some justification.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: use AV_WB16 where possible

[wm4]

On Wed, 27 Sep 2017 19:45:23 -0300
James Almer  wrote:

> On 9/27/2017 7:19 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> > 
> > additional changes to hevc patchset, as suggested on-list
> > 
> > if these look fine, I will squash into previous patchset and push it to
> > master.
> > ---
> >  libavcodec/videotoolbox.c | 27 +--
> >  1 file changed, 9 insertions(+), 18 deletions(-)
> > 
> > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> > index 078174cc61..c96200cbdb 100644
> > --- a/libavcodec/videotoolbox.c
> > +++ b/libavcodec/videotoolbox.c
> > @@ -165,10 +165,8 @@ CFDataRef 
> > ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
> >   ptlc.non_packed_constraint_flag << 5 |
> >   ptlc.frame_only_constraint_flag << 4);
> >  AV_W8(p + 7, 0);
> > -AV_W8(p + 8, 0);
> > -AV_W8(p + 9, 0);
> > -AV_W8(p + 10, 0);
> > -AV_W8(p + 11, 0);
> > +AV_WB16(p + 8, 0);
> > +AV_WB16(p + 10, 0);  
> 
> AV_WB32(p + 8, 0)
> 
> or even AV_WN32(p + 8, 0) since it's 0 and endianness doesn't matter.

IMO it should reflect whatever bitstream elements these are. Ideally,
we'd have comments about what each element is too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[James Almer]

On 9/27/2017 8:11 PM, wm4 wrote:
> On Wed, 27 Sep 2017 19:52:13 -0300
> James Almer  wrote:
> 
>>> +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
>>> +enum { kCMVideoCodecType_HEVC = 'hvc1' };
>>> +#endif  
>>
>> The correct thing to do is adding kCMVideoCodecType_HEVC to
>> hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
>> that don't support it since, i assume, no computer with MacOS 10.8 will
>> be able to play hevc videos anyway.
> 
> SDK version != OS you build on != target machine
> 
> So this has some justification.

Neither is the case for dxva2 hevc and vp9, yet it's done like i
mentioned above.
Of course, those two require an entire header and not a single enum
value, so it probably explains the decision to make them dependencies.

I'm not going to block the patch for this, so implement it however you
prefer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel