Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input formats correctly.
> -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 correctly. > > > > -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 alpha channel, we just ignore it. > > > Also add some checks for incompatible input formats. > > > > > > Signed-off-by: Ruiling Song > LGTM. > BTW, could the main input with alpha case be supported? I am not sure what kind of support do you mean? I simply ignore the alpha channel of the main input, and do the alpha blending using the overlay alpha. Before this patch, the filter will do it wrong if the main input has alpha channel. Now it works with this patch. Thanks! Ruiling > ___ > 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 2/4] lavfi/opencl: Handle overlay input formats correctly.
> > > > -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 alpha channel, we just ignore it. > > > > Also add some checks for incompatible input formats. > > > > > > > > Signed-off-by: Ruiling Song > > LGTM. > > BTW, could the main input with alpha case be supported? > > I am not sure what kind of support do you mean? > I simply ignore the alpha channel of the main input, and do the alpha > blending using the overlay alpha. > Before this patch, the filter will do it wrong if the main input has alpha > channel. Now it works with this patch. > > Thanks! > Ruiling I mean support alpha blending with alpha channel of main input when no overlay alpha. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Optimize libavformat/metadata.c
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 Fight Club is that Chuck Norris can talk about Fight Club. No one tells Chuck Norris what not to do. — http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Optimize libavformat/metadata.c
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 early as well. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/http.c: add the protection about the http seek implement
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 >--- > libavformat/http.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/libavformat/http.c b/libavformat/http.c >index 3a35bc7eac..9401a5c63e 100644 >--- a/libavformat/http.c >+++ b/libavformat/http.c >@@ -1669,7 +1669,7 @@ static int64_t http_seek_internal(URLContext *h, int64_t >off, int whence, int fo > int old_buf_size, ret; > AVDictionary *options = NULL; > >-if (whence == AVSEEK_SIZE) >+if (whence == AVSEEK_SIZE || (h->is_streamed == 0 && whence == SEEK_SET >&& off == s->filesize)) > return s->filesize; > else if (!force_reconnect && > ((whence == SEEK_CUR && off == 0) || >-- >2.19.0 > > >___ >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] round-robin like scheduling for multichannel inputs. Important in case of capture devices. Else the first channel is preferred always.
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 breaks fate and looks hackish [...] -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: add initial bayer and sub image support
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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/ffmetadec: use dynamic allocation for line buffer
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 lower bound would be enough though, I don't expect 2GB JPEG files as thumbnails… François. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/ffmetadec: use dynamic allocation for line buffer
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/libavformat/ffmetadec.c
index 3290b3b7bc..ccbff51c03 100644
--- a/libavformat/ffmetadec.c
+++ b/libavformat/ffmetadec.c
@@ -128,16 +128,26 @@ static int read_tag(const uint8_t *line, AVDictionary **m)
static int read_header(AVFormatContext *s)
{
AVDictionary **m = &s->metadata;
-uint8_t line[1024];
+int64_t line_size = avio_size(s->pb);
+uint8_t *line;
+
+if (line_size < 1 || line_size > SIZE_MAX)
+ line_size = SIZE_MAX;
+
+line = av_malloc(line_size);
+if (!line)
+return AVERROR(ENOMEM);
while(!avio_feof(s->pb)) {
-get_line(s->pb, line, sizeof(line));
+get_line(s->pb, line, line_size);
if (!memcmp(line, ID_STREAM, strlen(ID_STREAM))) {
AVStream *st = avformat_new_stream(s, NULL);
-if (!st)
+if (!st) {
+av_free(line);
return AVERROR(ENOMEM);
+}
st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
st->codecpar->codec_id = AV_CODEC_ID_FFMETADATA;
@@ -146,8 +156,10 @@ static int read_header(AVFormatContext *s)
} else if (!memcmp(line, ID_CHAPTER, strlen(ID_CHAPTER))) {
AVChapter *ch = read_chapter(s);
-if (!ch)
+if (!ch) {
+av_free(line);
return AVERROR(ENOMEM);
+}
m = &ch->metadata;
} else
@@ -160,6 +172,7 @@ static int read_header(AVFormatContext *s)
s->chapters[s->nb_chapters - 1]->time_base,
AV_TIME_BASE_Q);
+av_free(line);
return 0;
}
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input formats correctly.
> -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 correctly. > > > > > > -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 alpha channel, we just ignore it. > > > > > Also add some checks for incompatible input formats. > > > > > > > > > > Signed-off-by: Ruiling Song > > > LGTM. > > > BTW, could the main input with alpha case be supported? > > > > I am not sure what kind of support do you mean? > > I simply ignore the alpha channel of the main input, and do the alpha > > blending using the overlay alpha. > > Before this patch, the filter will do it wrong if the main input has alpha > > channel. Now it works with this patch. > > > > Thanks! > > Ruiling > > I mean support alpha blending with alpha channel of main input when no overlay > alpha. I think I got your idea, this patch aims to fix the issues reported by Gyan. If people really want it (blending using alpha of main input) be supported, we can add it later. I am not sure whether this sounds ok? Thanks! Ruiling > ___ > 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/isom: add "dvhe" fourCC for HEVC
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 post a v2 in a moment which contains all of the AVC and HEVC
identifiers specified in that Dolby specification and which are
registered at the MPEG-4 registration authority (they have two AVC and
two HEVC ones).
After looking at the relevant specs:
* These custom registered identifiers should only be utilized when the
stream cannot be played as-is by a standards-compliant AVC/HEVC
player. In other words, no color metadata is (supposed) to be left in
the video stream, and a custom DOVIConfigurationBox is required to be
parsed in order for the application to be able to interpret the actual
contents of the stream (YCbCr vs ICtCp('ish), HDR or SDR, base layer
or enhancement layer etc).
* These sample entries all contain the standardized configuration box,
which means that they should always be decode'able. Thus I am for
adding these identifiers to the demuxer, even if the actual content
cannot be interpreted without additional parsing.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
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 codes are specified to have the standard AVC or HEVC decoder
configuration box in addition to the Dolby custom DOVIConfigurationBox.
This is what enables us to decode the streams without custom parsing.
For correct presentation information from the DOVIConfigurationBox
is required (YCbCr or ICtCP, SDR or HDR, base or enhancement layer).
---
libavformat/isom.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index ca9d22e4f7..a7bd657b63 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -163,6 +163,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
{ AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which
indicates parameter sets may be in ES */
{ AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which
indicates parameter sets shall not be in ES */
+{ AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby
Vision derived from hev1 */
+{ AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', '1') }, /* HEVC-based Dolby
Vision derived from hvc1 */
{ AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
{ AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
@@ -185,6 +187,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
{ AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */
{ AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422 produced
by FCP */
{ AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2 AVC-LongG
*/
+{ AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby Vision
derived from avc1 */
+{ AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby Vision
derived from avc3 */
{ AV_CODEC_ID_VP8, MKTAG('v', 'p', '0', '8') }, /* VP8 */
{ AV_CODEC_ID_VP9, MKTAG('v', 'p', '0', '9') }, /* VP9 */
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/isom: add "dvhe" fourCC for HEVC
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 information >> can be an issue. >> >> Carl Eugen > > I will post a v2 in a moment which contains all of the AVC and HEVC > identifiers specified in that Dolby specification and which are > registered at the MPEG-4 registration authority 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
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 Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] lavfi/opencl: Handle overlay input formats correctly.
> > -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 correctly. > > > > > > > > -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 alpha channel, we just ignore it. > > > > > > Also add some checks for incompatible input formats. > > > > > > > > > > > > Signed-off-by: Ruiling Song > > > > LGTM. > > > > BTW, could the main input with alpha case be supported? > > > > > > I am not sure what kind of support do you mean? > > > I simply ignore the alpha channel of the main input, and do the > > > alpha blending using the overlay alpha. > > > Before this patch, the filter will do it wrong if the main input has > > > alpha channel. Now it works with this patch. > > > > > > Thanks! > > > Ruiling > > > > I mean support alpha blending with alpha channel of main input when no > > overlay alpha. > I think I got your idea, this patch aims to fix the issues reported by Gyan. > If people really want it (blending using alpha of main input) be supported, we > can add it later. > I am not sure whether this sounds ok? > > Thanks! > Ruiling Sure, sound good. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/isom: add "dvhe" fourCC for HEVC
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 Dolby, which we all can have our opinions on, but still a specification). b) has the identifiers registered to itself by mpeg-4 ra When looking into something that is specified, wouldn't you go through it and enable what it mentions if you notice that there were actually more things than you originally thought?! I'm pretty sure this way of going through it has nothing special regarding it compared to the "last decade". Generally picking up values from samples happens when there are no specifications, or if there's a specific agenda from the side of FFmpeg to prefer one identifier to the other. Or if someone just forgot to look at a specification during initial implementation. Or the specification changed. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
