Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input formats correctly.

2018-11-07 Thread Song, Ruiling
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Li, Zhong > Sent: Wednesday, November 7, 2018 2:58 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input > formats

Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input formats correctly.

2018-11-07 Thread Li, Zhong
> > > > -Original Message- > > > > From: Song, Ruiling > > > > Sent: Monday, October 29, 2018 1:18 PM > > > > To: ffmpeg-devel@ffmpeg.org > > > > Cc: Song, Ruiling > > > > Subject: [PATCH 2/4] lavfi/opencl: Handle overlay input formats > correctly. > > > > > > > > The main input may have a

Re: [FFmpeg-devel] [PATCH] Optimize libavformat/metadata.c

2018-11-07 Thread Shlomi Fish
On Wed, 4 Jul 2018 23:10:46 +0300 Shlomi Fish wrote: Ping/bump! Can this patch be reviewed already? -- - Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/bits/facts/Emma-Watson/ The Zeroth Rule of Fig

Re: [FFmpeg-devel] [PATCH] Optimize libavformat/metadata.c

2018-11-07 Thread Marton Balint
On Wed, 7 Nov 2018, Shlomi Fish wrote: On Wed, 4 Jul 2018 23:10:46 +0300 Shlomi Fish wrote: Ping/bump! Can this patch be reviewed already? Does your patch has any measureable speed difference for some streams? It seems like a very micro optimialization, because ff_metadata_conv bails out

Re: [FFmpeg-devel] [PATCH] libavformat/http.c: add the protection about the http seek implement

2018-11-07 Thread 沈启超
what about the progress of this patch ? At 2018-10-30 10:01:27, "shenqichao" wrote: >If a http resource is not streamed, it can seek to the end of this resouce. > >I add the detail information at https://trac.ffmpeg.org/ticket/6885 > >Fixes ticket #6885. > >Signed-off-by: shenqichao >---

Re: [FFmpeg-devel] [PATCH] round-robin like scheduling for multichannel inputs. Important in case of capture devices. Else the first channel is preferred always.

2018-11-07 Thread Michael Niedermayer
On Tue, Nov 06, 2018 at 01:15:10PM +0100, Roman Sidler wrote: > --- > fftools/ffmpeg.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index da4259a9a8..fa54421d73 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c brea

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: add initial bayer and sub image support

2018-11-07 Thread Paul B Mahol
On 11/1/18, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavcodec/tiff.c | 162 ++ > libavcodec/tiff.h | 6 +- > 2 files changed, 156 insertions(+), 12 deletions(-) Will apply if there are no comments.

Re: [FFmpeg-devel] [PATCH] libavformat/ffmetadec: use dynamic allocation for line buffer

2018-11-07 Thread François Revol
Le 07/11/2018 à 14:34, François Revol a écrit : > When adding thumbnails to OGG files, the line can easily go up to 100kB. > > We thus try to allocate the file size or SIZE_MAX to avoid truncation. [...] > +if (line_size < 1 || line_size > SIZE_MAX) > + line_size = SIZE_MAX; Maybe a low

[FFmpeg-devel] [PATCH] libavformat/ffmetadec: use dynamic allocation for line buffer

2018-11-07 Thread François Revol
When adding thumbnails to OGG files, the line can easily go up to 100kB. We thus try to allocate the file size or SIZE_MAX to avoid truncation. --- libavformat/ffmetadec.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/libavformat/ffmetadec.c b/libavfor

Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input formats correctly.

2018-11-07 Thread Song, Ruiling
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Li, Zhong > Sent: Wednesday, November 7, 2018 4:37 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input > formats

Re: [FFmpeg-devel] [PATCH] lavf/isom: add "dvhe" fourCC for HEVC

2018-11-07 Thread Jan Ekström
On Tue, Nov 6, 2018 at 11:56 PM Carl Eugen Hoyos wrote: > > Since the patch doesn't change default muxing behaviour, it could > be committed for the time being, please mention ticket #7347. > Maybe print a warning if not reading the additional information > can be an issue. > > Carl Eugen I will

[FFmpeg-devel] [PATCH v2] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-11-07 Thread Jan Ekström
From: Rodger Combs These are registered identifiers at the MPEG-4 RA, which are defined as to be utilized for Dolby Vision AVC/HEVC streams that are not correctly presentable by standards-compliant AVC/HEVC players. According to the Dolby Vision specification for ISOBMFF, these sample entry code

Re: [FFmpeg-devel] [PATCH] lavf/isom: add "dvhe" fourCC for HEVC

2018-11-07 Thread Carl Eugen Hoyos
2018-11-07 23:41 GMT+01:00, Jan Ekström : > On Tue, Nov 6, 2018 at 11:56 PM Carl Eugen Hoyos wrote: >> >> Since the patch doesn't change default muxing behaviour, it could >> be committed for the time being, please mention ticket #7347. >> Maybe print a warning if not reading the additional inform

Re: [FFmpeg-devel] [PATCH v2] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-11-07 Thread Carl Eugen Hoyos
2018-11-08 0:11 GMT+01:00, Jan Ekström : > +{ AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', '1') }, /* HEVC-based Dolby > Vision derived from hvc1 */ As said before, this breaks real-world files, the patch is therefore not ok. (And as said before, the authority hasn't done their homework.) Carl Eug

Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input formats correctly.

2018-11-07 Thread Li, Zhong
> > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Li, Zhong > > Sent: Wednesday, November 7, 2018 4:37 PM > > To: FFmpeg development discussions and patches > > > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay

Re: [FFmpeg-devel] [PATCH] lavf/isom: add "dvhe" fourCC for HEVC

2018-11-07 Thread Jan Ekström
On Thu, Nov 8, 2018, 03:38 Carl Eugen Hoyos > Apart from "please see archives": > Why can't we do it like the last decade and fix files that don't work > instead of creating patches that apparently are impossible to test? > > Carl Eugen > We have something that: a) has a specification (albeit by