Re: [FFmpeg-devel] [PATCH v2] avformat/movenc: implicitly enable negative CTS offsets for ismv

2018-08-04 Thread Jan Ekström 
On 7/29/18, Jan Ekström  wrote:
> ISMV lacks any sort of edit list support, as well as tfxd is
> effectively the PTS of the fragment for most intents and purposes.
>
> Thus, if b-frames are requested without negative CTS offsets you
> end up with N frames' worth of delay (tfxd PTS plus the CTS offset
> of the first sample). Negative CTS offsets enable the first sample
> to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
> is avoided.

Hi,

Since this fixes b-frames in ISMV by not adding a double-delay (tfxd
PTS + positive CTS offset), unless someone has any comments I will
push this tonight (JST).

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

[FFmpeg-devel] [PATCH 2/2] avcodec/scpr: Check for min > max in decompress_p()

2018-08-04 Thread Michael Niedermayer 
Fixes: Timeout
Fixes: 
9342/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-4795990841229312

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/scpr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
index 72f59d5917..d1e47b09ac 100644
--- a/libavcodec/scpr.c
+++ b/libavcodec/scpr.c
@@ -525,6 +525,9 @@ static int decompress_p(AVCodecContext *avctx,
 if (ret < 0)
 return ret;
 
+if (min > max)
+return AVERROR_INVALIDDATA;
+
 max += temp << 8;
 memset(s->blocks, 0, sizeof(*s->blocks) * s->nbcount);
 
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 1/2] avcodec/vp9: Check in decode_tiles() if there is data remaining

2018-08-04 Thread Michael Niedermayer 
Fixes: Timeout
Fixes: 
9330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5707345857347584

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp9.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index b1178c9c0c..4ca51ec108 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1302,6 +1302,9 @@ static int decode_tiles(AVCodecContext *avctx,
 memset(lflvl_ptr->mask, 0, sizeof(lflvl_ptr->mask));
 }
 
+if (td->c->end <= td->c->buffer && td->c->bits >= 0) {
+return AVERROR_INVALIDDATA;
+}
 if (s->pass == 2) {
 decode_sb_mem(td, row, col, lflvl_ptr,
   yoff2, uvoff2, BL_64X64);
-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH] lavfi: add lumakey_opencl filter

2018-08-04 Thread Mark Thompson 
On 25/07/18 13:13, Danil Iashchenko wrote:
> Add lumakey_opencl filter. Behaves like existing lumakey filter.
> 
> ---
>  configure   |   1 +
>  libavfilter/Makefile|   2 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/opencl/lumakey.cl   |  43 +++
>  libavfilter/opencl_source.h |   1 +
>  libavfilter/vf_lumakey_opencl.c | 243 
> 
>  6 files changed, 291 insertions(+)
>  create mode 100644 libavfilter/opencl/lumakey.cl
>  create mode 100644 libavfilter/vf_lumakey_opencl.c


I think you need a bit more configuration to make this work without needing to 
force the formats externally.  I guess you did something like 
'format=yuv420p,hwupload,lumakey_opencl,hwdownload,format=yuva420p'?

It should probably be able to work with something like:

./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device 
opencl=cl@va -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device va -i 
in1.mp4 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device va -i 
in2.mp4 -an -filter_hw_device cl -filter_complex 
'[0:v]scale_vaapi=format=yuv420p,hwmap,lumakey_opencl[a]; 
[1:v]scale_vaapi=format=yuv420p,hwmap[b]; 
[a][b]overlay_opencl,hwmap=derive_device=vaapi:reverse=1,scale_vaapi=format=nv12'
 -c:v h264_vaapi out.mp4

to composite two videos together keyed by the luma of the first (I'm not sure 
that command-line is exactly right, but something like that).  In this case 
there isn't any way to make the output format implicitly do the right thing, so 
the filter needs to deal with the formats internally.  (And extra points if you 
can avoid the yuv420p conversion :)


Everything else in the patch looks fine.

Thanks,

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

[FFmpeg-devel] [PATCH] http: only set filesize for 206 content-range

2018-08-04 Thread Robert Nagy 
Growing files will return 416 with a current file size in content-range.
However, FFmpeg incorrectly assumes this is the final file size.
Fix this by only setting file size for 206 responses.
---
 libavformat/http.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 668cd51986..3bd89780c3 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -617,7 +617,7 @@ static void parse_content_range(URLContext *h, const
char *p)
 HTTPContext *s = h->priv_data;
 const char *slash;

-if (!strncmp(p, "bytes ", 6)) {
+if (!strncmp(p, "bytes ", 6) && s->http_code == 206) {
 p += 6;
 s->off = strtoull(p, NULL, 10);
 if ((slash = strchr(p, '/')) && strlen(slash) > 0)
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

2018-08-04 Thread Mark Thompson 
On 04/08/18 01:40, Lukas Rusak wrote:
> This allows for a zero-copy output by exporting the v4l2 buffer then wrapping 
> that buffer
> in the AVDRMFrameDescriptor like it is done in rkmpp.
> 
> This has been in use for quite some time with great success on many platforms 
> including:
>  - Amlogic S905
>  - Raspberry Pi
>  - i.MX6
>  - Dragonboard 410c
> 
> This was developed in conjunction with Kodi to allow handling the zero-copy 
> buffer rendering.
> A simply utility for testing is also available here: 
> https://github.com/BayLibre/ffmpeg-drm
> 
> todo:
>  - allow selecting pixel format output from decoder
>  - allow configuring amount of output and capture buffers
> 
> V2:
>  - allow selecting AV_PIX_FMT_DRM_PRIME
> 
> V3:
>  - use get_format to select AV_PIX_FMT_DRM_PRIME
>  - use hw_configs
>  - add handling of AV_PIX_FMT_YUV420P format (for raspberry pi)
>  - add handling of AV_PIX_FMT_YUYV422 format (for i.MX6 coda decoder)
> ---
>  libavcodec/v4l2_buffers.c | 216 --
>  libavcodec/v4l2_buffers.h |   4 +
>  libavcodec/v4l2_context.c |  40 ++-
>  libavcodec/v4l2_m2m.c |   4 +-
>  libavcodec/v4l2_m2m.h |   3 +
>  libavcodec/v4l2_m2m_dec.c |  23 
>  6 files changed, 253 insertions(+), 37 deletions(-)

The v4l2_m2m decoders need to depend on libdrm in configure for this.  (And if 
you don't want that as a hard dependency then you'll need #ifdefs everywhere.)

> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index aef911f3bb..e5c46ac81e 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -21,6 +21,7 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  
> +#include 

Don't include the outer path, pkg-config deals with it.  (The path you've 
picked is wrong for a default install of current libdrm.)

>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,7 @@
>  #include 
>  #include "libavcodec/avcodec.h"
>  #include "libavcodec/internal.h"
> +#include "libavutil/hwcontext.h"
>  #include "v4l2_context.h"
>  #include "v4l2_buffers.h"
>  #include "v4l2_m2m.h"
> @@ -203,7 +205,79 @@ static enum AVColorTransferCharacteristic 
> v4l2_get_color_trc(V4L2Buffer *buf)
>  return AVCOL_TRC_UNSPECIFIED;
>  }
>  
> -static void v4l2_free_buffer(void *opaque, uint8_t *unused)
> +static uint8_t * v4l2_get_drm_frame(V4L2Buffer *avbuf)
> +{
> +AVDRMFrameDescriptor *drm_desc = >drm_frame;
> +AVDRMLayerDescriptor *layer;
> +
> +/* fill the DRM frame descriptor */
> +drm_desc->nb_objects = avbuf->num_planes;
> +drm_desc->nb_layers = 1;
> +
> +layer = _desc->layers[0];
> +layer->nb_planes = avbuf->num_planes;
> +
> +for (int i = 0; i < avbuf->num_planes; i++) {
> +layer->planes[i].object_index = i;
> +layer->planes[i].offset = 0;
> +layer->planes[i].pitch = avbuf->plane_info[i].bytesperline;
> +}
> +
> +switch (avbuf->context->av_pix_fmt) {
> +case AV_PIX_FMT_YUYV422:
> +
> +layer->format = DRM_FORMAT_YUYV;
> +layer->nb_planes = 1;
> +
> +break;
> +
> +case AV_PIX_FMT_NV12:
> +case AV_PIX_FMT_NV21:
> +
> +layer->format = avbuf->context->av_pix_fmt == AV_PIX_FMT_NV12 ?
> +DRM_FORMAT_NV12 : DRM_FORMAT_NV21;
> +
> +if (avbuf->num_planes > 1)
> +break;
> +
> +layer->nb_planes = 2;
> +
> +layer->planes[1].object_index = 0;
> +layer->planes[1].offset = avbuf->plane_info[0].bytesperline *
> +avbuf->context->format.fmt.pix.height;
> +layer->planes[1].pitch = avbuf->plane_info[0].bytesperline;

To confirm, it's necessarily true that there is no padding at all between the 
luma and chroma planes here?

> +break;
> +
> +case AV_PIX_FMT_YUV420P:
> +
> +layer->format = DRM_FORMAT_YUV420;
> +
> +if (avbuf->num_planes > 1)
> +break;
> +
> +layer->nb_planes = 3;
> +
> +layer->planes[1].object_index = 0;
> +layer->planes[1].offset = avbuf->plane_info[0].bytesperline *
> +avbuf->context->format.fmt.pix.height;
> +layer->planes[1].pitch = avbuf->plane_info[0].bytesperline >> 1;
> +
> +layer->planes[2].object_index = 0;
> +layer->planes[2].offset = layer->planes[1].offset +
> +((avbuf->plane_info[0].bytesperline *
> +  avbuf->context->format.fmt.pix.height) >> 2);
> +layer->planes[2].pitch = avbuf->plane_info[0].bytesperline >> 1;
> +break;
> +
> +default:
> +drm_desc->nb_layers = 0;
> +break;
> +}
> +
> +return (uint8_t *) drm_desc;
> +}
> +
> +static void v4l2_free_buffer(void *opaque, uint8_t *data)
>  {
>  V4L2Buffer* avbuf = opaque;
>  V4L2m2mContext *s = buf_to_m2mctx(avbuf);
> @@ -227,27 +301,47 @@ static void v4l2_free_buffer(void *opaque, uint8_t 
> *unused)
>  }
>  }
>  
> -static int v4l2_buf_to_bufref(V4L2Buffer *in, int

Re: [FFmpeg-devel] [PATCH 1/4] libavcodec: v4l2m2m: fix indentation and add M2MDEC_CLASS

2018-08-04 Thread Mark Thompson 
On 04/08/18 01:40, Lukas Rusak wrote:
> This just makes the M2MDEC_CLASS similar to how it is done in rkmpp. It looks
> clean and has proper indentation
> ---
>  libavcodec/v4l2_m2m_dec.c | 46 ---
>  1 file changed, 24 insertions(+), 22 deletions(-)
> 
> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index 710e40efd8..7926e25efa 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/libavcodec/v4l2_m2m_dec.c
> @@ -205,29 +205,31 @@ static const AVOption options[] = {
>  { NULL},
>  };
>  
> +#define M2MDEC_CLASS(NAME) \
> +static const AVClass v4l2_m2m_ ## NAME ## _dec_class = { \
> +.class_name = #NAME "_v4l2_m2m_decoder", \
> +.item_name  = av_default_item_name, \
> +.option = options, \
> +.version= LIBAVUTIL_VERSION_INT, \
> +};
> +
>  #define M2MDEC(NAME, LONGNAME, CODEC, bsf_name) \
> -static const AVClass v4l2_m2m_ ## NAME ## _dec_class = {\
> -.class_name = #NAME "_v4l2_m2m_decoder",\
> -.item_name  = av_default_item_name,\
> -.option = options,\
> -.version= LIBAVUTIL_VERSION_INT,\
> -};\
> -\
> -AVCodec ff_ ## NAME ## _v4l2m2m_decoder = { \
> -.name   = #NAME "_v4l2m2m" ,\
> -.long_name  = NULL_IF_CONFIG_SMALL("V4L2 mem2mem " LONGNAME " 
> decoder wrapper"),\
> -.type   = AVMEDIA_TYPE_VIDEO,\
> -.id = CODEC ,\
> -.priv_data_size = sizeof(V4L2m2mPriv),\
> -.priv_class = _m2m_ ## NAME ## _dec_class,\
> -.init   = v4l2_decode_init,\
> -.receive_frame  = v4l2_receive_frame,\
> -.close  = ff_v4l2_m2m_codec_end,\
> -.bsfs   = bsf_name, \
> -.capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY | \
> -  AV_CODEC_CAP_AVOID_PROBING, \
> -.wrapper_name   = "v4l2m2m", \
> -};
> +M2MDEC_CLASS(NAME) \
> +AVCodec ff_ ## NAME ## _v4l2m2m_decoder = { \
> +.name   = #NAME "_v4l2m2m" , \
> +.long_name  = NULL_IF_CONFIG_SMALL("V4L2 mem2mem " LONGNAME " 
> decoder wrapper"), \
> +.type   = AVMEDIA_TYPE_VIDEO, \
> +.id = CODEC , \
> +.priv_data_size = sizeof(V4L2m2mPriv), \
> +.priv_class = _m2m_ ## NAME ## _dec_class, \
> +.init   = v4l2_decode_init, \
> +.receive_frame  = v4l2_receive_frame, \
> +.close  = ff_v4l2_m2m_codec_end, \
> +.bsfs   = bsf_name, \
> +.capabilities   = AV_CODEC_CAP_HARDWARE | AV_CODEC_CAP_DELAY, \

 Not a comma!  ^

(This gives you a load of compiler warnings, please do make sure you aren't 
introducing new warnings with patches.)

> +   AV_CODEC_CAP_AVOID_PROBING, \
> +.wrapper_name   = "v4l2m2m", \
> +};
>  
>  M2MDEC(h264,  "H.264", AV_CODEC_ID_H264,   "h264_mp4toannexb");
>  M2MDEC(hevc,  "HEVC",  AV_CODEC_ID_HEVC,   "hevc_mp4toannexb");
> 

Otherwise LGTM.

Thanks,

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

[FFmpeg-devel] [PATCH] fix memory leak in frame_thread_encoder: occurs when close encoder without sending eof and receiving to end

2018-08-04 Thread lee ju 
---
 libavcodec/frame_thread_encoder.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libavcodec/frame_thread_encoder.c 
b/libavcodec/frame_thread_encoder.c
index 5ff3f7863c..55756c4c54 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -251,6 +251,23 @@ void ff_frame_thread_encoder_free(AVCodecContext *avctx){
  pthread_join(c->worker[i], NULL);
 }
 
+while (av_fifo_size(c->task_fifo) > 0) {
+Task task;
+AVFrame *frame;
+av_fifo_generic_read(c->task_fifo, , sizeof(task), NULL);
+frame = task.indata;
+av_frame_free();
+task.indata = NULL;
+}
+
+for (i=0; ifinished_tasks[i].outdata != NULL) {
+AVPacket *pkt = c->finished_tasks[i].outdata;
+av_packet_free();
+c->finished_tasks[i].outdata = NULL;
+}
+}
+
 pthread_mutex_destroy(>task_fifo_mutex);
 pthread_mutex_destroy(>finished_task_mutex);
 pthread_mutex_destroy(>buffer_mutex);
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/aacpsdsp_template: Fix integer overflow in ps_stereo_interpolate_c()

2018-08-04 Thread Michael Niedermayer 
On Sat, Jul 28, 2018 at 02:32:29PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -1813244069 + -1407981383 cannot be 
> represented in type 'int'
> Fixes: 
> 8823/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5643295618236416
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/aacpsdsp_template.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

will apply patchset

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Check audio packet size

2018-08-04 Thread Michael Niedermayer 
On Sat, Jul 28, 2018 at 03:16:09PM +0200, Michael Niedermayer wrote:
> Fixes: Assertion failure
> Fixes: assert_flvenc.c:941_1.swf
> 
> Found-by: #CHEN HONGXU# 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/flvenc.c | 5 +
>  1 file changed, 5 insertions(+)

will apply

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

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


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

Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

2018-08-04 Thread Michael Niedermayer 
Hi

On Sat, Aug 04, 2018 at 01:17:53AM +0300, Sergey Lavrushkin wrote:
> 2018-08-04 0:11 GMT+03:00 Michael Niedermayer :
> 
> > On Fri, Aug 03, 2018 at 10:33:00PM +0300, Sergey Lavrushkin wrote:
> > > 2018-08-03 16:07 GMT+03:00 Michael Niedermayer :
> > >
> > > > On Thu, Aug 02, 2018 at 09:52:45PM +0300, Sergey Lavrushkin wrote:
> > > > > This patch adds two floating-point gray formats to use them in sr
> > filter
> > > > for
> > > > > conversion with libswscale. I added conversion from uint gray to
> > float
> > > > and
> > > > > backwards in swscale_unscaled.c, that is enough for sr filter. But
> > for
> > > > > proper format addition, should I add anything else?
> > > > >
> > > > > ---
> > > > >  libavutil/pixdesc.c   | 22 ++
> > > > >  libavutil/pixfmt.h|  5 
> > > > >  libswscale/swscale_internal.h |  7 ++
> > > > >  libswscale/swscale_unscaled.c | 54 ++
> > > > +++--
> > > > >  libswscale/utils.c|  5 +++-
> > > >
> > > > please split this in a patch or libavutil and one for libswscale
> > > > they also need some version.h bump
> > > >
> > >
> > > Ok.
> > >
> > > also fate tests need an update, (make fate) fails otherwise, the update
> > > > should
> > > > be part of the patch that causes the failure otherwise
> > >
> > >
> > > In one test for these formats I get:
> > >
> > > filter-pixfmts-scale
> > > grayf32be   grayf32le   monob
> > >  f01cb0b623357387827902d9d0963435
> > >
> > > I guess, it is because I only implemented conversion in swscale_unscaled.
> > > What can I do to fix it? Should I implement conversion for scaling or
> > maybe
> > > change something in the test, so it would not check these formats (if it
> > is
> > > possible).
> > > Anyway, I need to know what changes should I do and where.
> >
> > well, swscale shouldnt really have formats only half supported
> > so for any supported format in and out it should work with any
> > width / height in / out
> >
> > Theres a wide range of possibilities how to implement this.
> > The correct / ideal way is of course to implement a full floating point
> > path
> > for scaling along side the integer code.
> > a simpler aprouch would be to convert from/to float to/from  integers and
> > use
> > the existing code. (this of course has the disadvantage of loosing
> > precission)
> >
> 
> Well, I want to implement simpler approach, as I still have to finish
> correcting sr filter.
> But I need some explanations regarding what I should add. If I understand
> correcly,

> I need to add conversion from float to the ff_sws_init_input_funcs function
> in libswscale/input.c
> and conversion to float to the ff_sws_init_output_funcs function in
> libswscale/output.c
> If I am not mistaken, in the first case I need to provide c->lumToYV12 and
> in the second case -
> yuv2plane1 and yuv2planeX.

yes that sounds correct


> So, in the first case, to what format should I
> add
> conversion, specifically what number of bits per pixel should be used? As I
> look through other
> conversion functions, it seems that somewhere uint8 is used and somewhere -
> uint16.

you should try to maintain as many bits as possible, so a path similar to
what 16bit formats use would be best


> Is it somehow determined later during scaling? If I am going to convert to
> uint8 from
> my float format, should I define it somewhere, that I am converting to
> uint8?
> And in the second case, I don't completely understand, what these two
> functions are
> doing, especially tha last one with filters. Is it also just simple
> conversions or
> these functions also cover something else? And in their descriptions it is
> written, that:
> 
>  * @param src scaled source data, 15 bits for 8-10-bit output,
>  *19 bits for 16-bit output (in int32_t)
>  * @param destpointer to the output plane. For >8-bit
>  *output, this is in uint16_t

also see doc/swscale.txt
note this text is IIRC older than the current swscale code so it
may be missing some things but the general architecture should be correct

also if you notice any errors or omissions in the documentation then
patches improving it are certainly welcome!


> 
> In my case, the output is 32-bit. Does this mean, that float type,
> basically, is not
> supported and I also have to modify something in scaling? If so, what
> should I add?

when input gets converted to the internal integer format and that gets
convverted back to floats at output then scaling should be fine as it
wouldnt "know" there are floats outside

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

2018-08-04 Thread Reto Kromer 
Sergey Lavrushkin wrote:

>2018-08-03 16:07 GMT+03:00 Michael Niedermayer
>:

[...]

>>division is slow. This should either be a multiplication with
>>the inverse or a LUT with 8bit index changing to float.
>>
>>The faster of them should be used
>
>LUT seems to be faster.

I am not surprised. In my experience, LUTs are often the faster
solution.

Best regards, Reto

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