Re: [FFmpeg-devel] Resending Patch for hlsenc.c fixes for https://trac.ffmpeg.org/ticket/7281
> On Aug 17, 2018, at 22:40, Steven Liu wrote:
>
>
>
>> On Aug 17, 2018, at 21:01, Ronak wrote:
>>
>> From 99e28c807a49cecf6ceb47ee44a85a3fdf78af64 Mon Sep 17 00:00:00 2001
>> From: "Ronak Patel"
>> Date: Thu, 2 Aug 2018 09:25:12 -0400
>> Subject: [PATCH v3] libavformat/hlsenc: Fix HLS Manifest Generation from an
>> N^2 algorithm to N.
>>
>> This fixes the creation of the hls manifest in hlsenc.c by writing the
>> entire manifest at the end for VOD playlists. Live & Event Playlists are
>> unaffected.
>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when
>> -hlsflags temp_file is specified, instead of always relying on use_rename,
>> which caused these problems.
>>
>> Files that would previously take over a week to fragment now take 1 minute
>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>>
>> Signed-off-by: Ronak Patel
>> ---
>> libavformat/hlsenc.c | 51 ---
>> 1 file changed, 36 insertions(+), 15 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index b5644f0..55983a1 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s,
>> AVFormatContext *oc)
>>return AVERROR(ENOMEM);
>>final_filename[len-4] = '\0';
>>ret = ff_rename(oc->url, final_filename, s);
>> -oc->url[len-4] = '\0';
>>av_freep(&final_filename);
>>return ret;
>> }
>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last,
>> VariantStream *vs)
>>char temp_filename[1024];
>>int64_t sequence = FFMAX(hls->start_sequence, vs->sequence -
>> vs->nb_entries);
>>const char *proto = avio_find_protocol_name(s->url);
>> -int use_rename = proto && !strcmp(proto, "file");
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
>> HLS_TEMP_FILE);
>>static unsigned warned_non_file;
>>char *key_uri = NULL;
>>char *iv_string = NULL;
>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int last,
>> VariantStream *vs)
>>hls->version = 7;
>>}
>>
>> -if (!use_rename && !warned_non_file++)
>> +if (!use_temp_file && !warned_non_file++)
>>av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this
>> may lead to races and temporary partial files\n");
>>
>>set_http_options(s, &options, hls);
>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" :
>> "%s", vs->m3u8_name);
>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp"
>> : "%s", vs->m3u8_name);
>>if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) <
>> 0)
>>goto fail;
>>
>> @@ -1472,8 +1471,8 @@ fail:
>>av_dict_free(&options);
>>hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>> -if (ret >= 0 && use_rename)
>> -ff_rename(temp_filename, vs->m3u8_name, s);
>> +if (use_temp_file)
>> +ff_rename(temp_filename, vs->m3u8_name, s);
>>
>>if (ret >= 0 && hls->master_pl_name)
>>if (create_master_playlist(s, vs) < 0)
>> @@ -1488,6 +1487,8 @@ static int hls_start(AVFormatContext *s, VariantStream
>> *vs)
>>AVFormatContext *oc = vs->avf;
>>AVFormatContext *vtt_oc = vs->vtt_avf;
>>AVDictionary *options = NULL;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
>> HLS_TEMP_FILE);
>>char *filename, iv_string[KEYSIZE*2 + 1];
>>int err = 0;
>>
>> @@ -1583,7 +1584,7 @@ static int hls_start(AVFormatContext *s, VariantStream
>> *vs)
>>
>>set_http_options(s, &options, c);
>>
>> -if (c->flags & HLS_TEMP_FILE) {
>> +if (use_temp_file) {
>>char *new_name = av_asprintf("%s.tmp", oc->url);
>>if (!new_name)
>>return AVERROR(ENOMEM);
>> @@ -2145,6 +2146,8 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>int ret = 0, can_split = 1, i, j;
>>int stream_index = 0;
>>int range_length = 0;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
>> HLS_TEMP_FILE);
>>uint8_t *buffer = NULL;
>>VariantStream *vs = NULL;
>>AVDictionary *options = NULL;
>> @@ -2214,10 +2217,10 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>
>>}
>>
>> +char *old_filename = NULL;
>>if (vs->packets_written && can_split && av_compare_ts(pkt->pts -
>> vs->start_pts, st->time_base,
>> end_pts,
>> AV_TIME_BASE_Q) >= 0) {
>>int64_t new_start_pos;
>> -char *old_filename = NULL;
>>int byterange_mode = (hls->flags & HLS_SINGLE_FILE) ||
>> (hls->max_seg_size > 0);
>>
>>av_write_frame(vs->avf, NULL); /* Flu
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Sat, Aug 18, 2018 at 02:10:21PM +0300, Sergey Lavrushkin wrote: > 2018-08-17 23:28 GMT+03:00 Michael Niedermayer : > > > On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote: > > > On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > > > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > > > >>> > > > >>> Just use av_clipf instead of FFMIN/FFMAX. > > > >> > > > >> > > > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > > > > > > > will apply > > > > > > > > thanks > > > > > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be > > > tested for bitexact output. The gbrpf32 ones aren't, for example. > > > http://fate.ffmpeg.org/report.cgi?time=20180816131312&slot= > > x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx > > > > h > > i remember i had tested this locally on 32bit > > can something be slightly adjusted (like an offset or factor) to avoid any > > values becoming close to 0.5 and rounding differently on platforms ? > > If not the tests should skip float pixel formats or try the nearest > > neighbor scaler > > > > Can it really be the problem with scaler? Do all these failed test use > scaling? > Is not it the problem, that different platforms can give slightly different > results for > floating-point operations? Does input for the float format is somehow > generated > for these tests, so the input conversion is tested? Maybe it uses output > conversion first? > If it is the problem of different floating-point operations results on > different platforms, > maybe it is possible to use precomputed LUT for output conversion, so it I dont think we should change the "algorithm" to achive "bitexactness" we could of course but it feels like the wrong reason to make such a change. How its done should be choosen based on what is fast (and to a lesser extend clean, simple and maintainable) > will give > the same results? Or is it possible to modify tests for the float format, > so it will > check if pixels of the result are just close to some reference. Its possible to compare to a reference, we do this in some other tests, but thats surely more work than just disabling teh specific tests or trying to nudge them a little to see if that makes nothing fall too close to n + 0.5 > > > > Sergey, can you look into this (its your patch) ? (just asking to make sure > > not eevryone thinks someone else will work on this) > > > > Yes, I can, just need to know, what is possible to do to fix this issue, > besides skipping the tests. most things are possible > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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/dashdec: Fix strlen(rep_id_val) with it being NULL
On Sat, Aug 18, 2018 at 09:19:10AM +0800, Steven Liu wrote:
>
>
> > On Aug 18, 2018, at 09:14, Michael Niedermayer
> > wrote:
> >
> > Fixes: dash-crash-da39a3ee5e6b4b0d3255bfef95601890afd80709.xml
> >
> > Found-by: Paul Ch
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/dashdec.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index f851bbf981..c6dddeb98f 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -857,7 +857,9 @@ static int
> > parse_manifest_representation(AVFormatContext *s, const char *url,
> > baseurl_nodes[3] = representation_baseurl_node;
> >
> > ret = resolve_content_path(s, url, &c->max_url_size, baseurl_nodes,
> > 4);
> > -c->max_url_size = aligned(c->max_url_size + strlen(rep_id_val) +
> > strlen(rep_bandwidth_val));
> > +c->max_url_size = aligned(c->max_url_size
> > + + (rep_id_val ? strlen(rep_id_val) : 0)
> > + + (rep_bandwidth_val ?
> > strlen(rep_bandwidth_val) : 0));
> > if (ret == AVERROR(ENOMEM) || ret == 0) {
> > goto end;
> > }
> > --
> > 2.18.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC] [PATCH 1/2] lavfi/vf_colorconstancy: adding weighted_ greyedge
Am 14.08.18 um 21:00 schrieb Thilo Borgmann: > Am 13.08.18 um 02:01 schrieb Mina: >> Hi, >> >> This patch introduces a new improved color constancy algorithm based on >> previously implemented greyedge algorithm. > > LGTM since I looked at this during GSoC. I would appreciate someone to have a > second look. Ping. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/tls_schannel: Fix use of uninitialized variable
Am 17.08.18 um 14:51 schrieb Carl Eugen Hoyos:
> 2018-08-17 14:36 GMT+02:00, Hendrik Leppkes :
>> On Fri, Aug 17, 2018 at 12:05 PM Paweł Wegner
>> wrote:
>>>
>>> Yes, it will work.
>>>
>>> Fixes: runtime error: passing uninitialized value to FreeContextBuffer
>>> causes a crash
>>>
>>> Signed-off-by: Paweł Wegner
>>> ---
>>> libavformat/tls_schannel.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
>>> index f41b007773..4f0badcb8d 100644
>>> --- a/libavformat/tls_schannel.c
>>> +++ b/libavformat/tls_schannel.c
>>> @@ -148,7 +148,7 @@ static int tls_client_handshake_loop(URLContext *h,
>>> int initial)
>>> TLSContext *c = h->priv_data;
>>> TLSShared *s = &c->tls_shared;
>>> SECURITY_STATUS sspi_ret;
>>> -SecBuffer outbuf[3];
>>> +SecBuffer outbuf[3] = { 0 };
>>> SecBufferDesc outbuf_desc;
>>> SecBuffer inbuf[2];
>>> SecBufferDesc inbuf_desc;
>>> --
>>> 2.17.1
>>>
>>
>> LGTM.
>
> Then please commit.
Pushed.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Resending Patch for hlsenc.c fixes for https://trac.ffmpeg.org/ticket/7281
> On Aug 17, 2018, at 10:40 AM, Steven Liu wrote:
>
>
>
>> On Aug 17, 2018, at 21:01, Ronak wrote:
>>
>> From 99e28c807a49cecf6ceb47ee44a85a3fdf78af64 Mon Sep 17 00:00:00 2001
>> From: "Ronak Patel"
>> Date: Thu, 2 Aug 2018 09:25:12 -0400
>> Subject: [PATCH v3] libavformat/hlsenc: Fix HLS Manifest Generation from an
>> N^2 algorithm to N.
>>
>> This fixes the creation of the hls manifest in hlsenc.c by writing the
>> entire manifest at the end for VOD playlists. Live & Event Playlists are
>> unaffected.
>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when
>> -hlsflags temp_file is specified, instead of always relying on use_rename,
>> which caused these problems.
>>
>> Files that would previously take over a week to fragment now take 1 minute
>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>>
>> Signed-off-by: Ronak Patel
>> ---
>> libavformat/hlsenc.c | 51 ---
>> 1 file changed, 36 insertions(+), 15 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index b5644f0..55983a1 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s,
>> AVFormatContext *oc)
>>return AVERROR(ENOMEM);
>>final_filename[len-4] = '\0';
>>ret = ff_rename(oc->url, final_filename, s);
>> -oc->url[len-4] = '\0';
>>av_freep(&final_filename);
>>return ret;
>> }
>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last,
>> VariantStream *vs)
>>char temp_filename[1024];
>>int64_t sequence = FFMAX(hls->start_sequence, vs->sequence -
>> vs->nb_entries);
>>const char *proto = avio_find_protocol_name(s->url);
>> -int use_rename = proto && !strcmp(proto, "file");
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
>> HLS_TEMP_FILE);
>>static unsigned warned_non_file;
>>char *key_uri = NULL;
>>char *iv_string = NULL;
>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int last,
>> VariantStream *vs)
>>hls->version = 7;
>>}
>>
>> -if (!use_rename && !warned_non_file++)
>> +if (!use_temp_file && !warned_non_file++)
>>av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this
>> may lead to races and temporary partial files\n");
>>
>>set_http_options(s, &options, hls);
>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" :
>> "%s", vs->m3u8_name);
>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp"
>> : "%s", vs->m3u8_name);
>>if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) <
>> 0)
>>goto fail;
>>
>> @@ -1472,8 +1471,8 @@ fail:
>>av_dict_free(&options);
>>hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>> -if (ret >= 0 && use_rename)
>> -ff_rename(temp_filename, vs->m3u8_name, s);
>> +if (use_temp_file)
>> +ff_rename(temp_filename, vs->m3u8_name, s);
>>
>>if (ret >= 0 && hls->master_pl_name)
>>if (create_master_playlist(s, vs) < 0)
>> @@ -1488,6 +1487,8 @@ static int hls_start(AVFormatContext *s, VariantStream
>> *vs)
>>AVFormatContext *oc = vs->avf;
>>AVFormatContext *vtt_oc = vs->vtt_avf;
>>AVDictionary *options = NULL;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
>> HLS_TEMP_FILE);
>>char *filename, iv_string[KEYSIZE*2 + 1];
>>int err = 0;
>>
>> @@ -1583,7 +1584,7 @@ static int hls_start(AVFormatContext *s, VariantStream
>> *vs)
>>
>>set_http_options(s, &options, c);
>>
>> -if (c->flags & HLS_TEMP_FILE) {
>> +if (use_temp_file) {
>>char *new_name = av_asprintf("%s.tmp", oc->url);
>>if (!new_name)
>>return AVERROR(ENOMEM);
>> @@ -2145,6 +2146,8 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>int ret = 0, can_split = 1, i, j;
>>int stream_index = 0;
>>int range_length = 0;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags &
>> HLS_TEMP_FILE);
>>uint8_t *buffer = NULL;
>>VariantStream *vs = NULL;
>>AVDictionary *options = NULL;
>> @@ -2214,10 +2217,10 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>
>>}
>>
>> +char *old_filename = NULL;
>>if (vs->packets_written && can_split && av_compare_ts(pkt->pts -
>> vs->start_pts, st->time_base,
>> end_pts,
>> AV_TIME_BASE_Q) >= 0) {
>>int64_t new_start_pos;
>> -char *old_filename = NULL;
>>int byterange_mode = (hls->flags & HLS_SINGLE_FILE) ||
>> (hls->max_seg_size > 0);
>>
>>av_write_frame(vs->avf, NULL); /* F
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On 8/17/2018 9:52 AM, Carl Eugen Hoyos wrote: > 2018-08-17 14:21 GMT+02:00, Sergey Lavrushkin : >> пт, 17 авг. 2018 г., 6:47 James Almer : >> >>> On 8/14/2018 1:23 PM, Michael Niedermayer wrote: On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: >> >> Just use av_clipf instead of FFMIN/FFMAX. > > > Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. will apply thanks >>> >>> This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be >>> tested for bitexact output. The gbrpf32 ones aren't, for example. >>> >>> http://fate.ffmpeg.org/report.cgi?time=20180816131312&slot=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx >> >> >> If I am not mistaken, gbrpf32 formats are not supported in libswscale >> [because of that] > > I sincerely hope that this is not true... > >> and not tested because of that. >> >>> >>> Was a float gray pixfmt needed for this filter? Gray16 was not an option? >>> >> >> All calculations in neural network are done using floats. >> >> What can I do to fix this issue? > > Reverting to doing the conversion in the filter comes to mind... > > Carl Eugen We asked him to remove the conversions from the filter, so we're not going to tell him to roll everything back... ___ 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-17 23:28 GMT+03:00 Michael Niedermayer : > On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote: > > On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > > >>> > > >>> Just use av_clipf instead of FFMIN/FFMAX. > > >> > > >> > > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > > > > > will apply > > > > > > thanks > > > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be > > tested for bitexact output. The gbrpf32 ones aren't, for example. > > http://fate.ffmpeg.org/report.cgi?time=20180816131312&slot= > x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx > > h > i remember i had tested this locally on 32bit > can something be slightly adjusted (like an offset or factor) to avoid any > values becoming close to 0.5 and rounding differently on platforms ? If not the tests should skip float pixel formats or try the nearest > neighbor scaler > Can it really be the problem with scaler? Do all these failed test use scaling? Is not it the problem, that different platforms can give slightly different results for floating-point operations? Does input for the float format is somehow generated for these tests, so the input conversion is tested? Maybe it uses output conversion first? If it is the problem of different floating-point operations results on different platforms, maybe it is possible to use precomputed LUT for output conversion, so it will give the same results? Or is it possible to modify tests for the float format, so it will check if pixels of the result are just close to some reference. > Sergey, can you look into this (its your patch) ? (just asking to make sure > not eevryone thinks someone else will work on this) > Yes, I can, just need to know, what is possible to do to fix this issue, besides skipping the tests. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] docs/filters: add documentation to all existing OpenCL filters
Hi Danil,
Except overlay and the topic of format requirements, rest LGTM.
On 15-08-2018 05:30 PM, Danil Iashchenko wrote:
docs/filters: add documentation to all existing OpenCL filters
Added general instruction for format conversion in the start of overall section
and separatly for overlay_opencl.
As far as I understand, different format conversion depends on which formats
are supported by hwupload/hwdownload.
So maybe it is better to clarify what formats are supported by them in
hwupload/hwdownload section, since it is used not only by OpenCL and show set
of possible input formats which do not need the conversion. All other
unexpected formats should be converted by format filter.
+Format conversion depends on format of the INPUT, on which logo is overlaying
on.
+
+These are examples of different format conversions:
+@example
+if the formats of INPUT and LOGO are the same, no conversion is required. For
example yuv420p is overlaying on yuv420p.
+@end example
+@example
+if initial planes match, but the overlay has additional alpha plane, this case
requires conversion to matching format. For example if the INPUT is yuv420p,
LOGO should be yuva420p.
+@end example
+@example
+if INPUT and LOGO has same-plane alpha, same layout and different but mathing
format. For example RGBA is overlaying on RGB0.
+@end example
+Insert a JPG logo in the top-left corner of the mp4 INPUT. No conversion
needed.
+@example
+-i INPUT -i LOGO -filter_complex "[0:v]hwupload[a], [1:v]hwupload[b],
[a][b]overlay_opencl, hwdownload" OUTPUT
I tried to overlay a 4:4:4 JPG on a 4:2:0 video, using
ffmpeg -i video.mp4 -i image.jpg
-init_hw_device opencl=gpu:0.0 -filter_hw_device gpu
-filter_complex "[0]hwupload@m[m];[1]hwupload@o[o];
[m][o]overlay_opencl=100:100,hwdownload"
-t 1 -an -y test.mp4
This "succeeded", but the colors are, obviously, wrong. It works
correctly with format=yuv420p before hwupload for the JPG. It also
"works" with format=rgba, but the colors are again wrong.
Shouldn't there be validation of the matching of pixel formats within
the filter?
+Insert a PNG logo in the top-left corner of the mp4 INPUT. Explicit format
conversion is a must.
+@example
+-i INPUT -i LOGO -filter_complex "[0:v]hwupload[a], [1:v]format=yuva420p,
hwupload[b], [a][b]overlay_opencl, hwdownload" OUTPUT
I tried to overlay a RGBA input on a 4:2:0 video, using
ffmpeg -i video.mp4 -i image.png
-init_hw_device opencl=gpu:0.0 -filter_hw_device gpu
-filter_complex "[0]hwupload@m[m];
[1]format=yuva420p,hwupload@o[o];
[m][o]overlay_opencl=100:100,hwdownload"
-t 1 -an -y test.mp4
This failed with
[hwupload @ 06ee5e80] Failed to allocate frame to upload to.
Error while filtering: Cannot allocate memory
Failed to inject frame into filter network: Cannot allocate memory
Error while processing the decoded data for stream #1:0
If I skip format, I get
[AVHWDeviceContext @ 02983700] OpenCL error: Invalid memory
object.
[Parsed_overlay_opencl_3 @ 07125f00] Failed to set kernel
argument 3: error -38.
If I use instead format=rgb24, it "works" but with a weird result.
Again, validation?
If I insert format with arg yuva420p before both video and image, I get
[hwdownload @ 06ce14c0] Invalid output format yuv420p for
hwframe download.
[Parsed_hwdownload_5 @ 06efb040] Failed to configure output
pad on Parsed_hwdownload_5
Adding format=yuv420p after hwdownload, I get
[hwdownload @ 06f2b440] Invalid output format yuv420p for
hwframe download.
[Parsed_hwdownload_5 @ 070148c0] Failed to configure output pad
on Parsed_hwdownload_5
Adding instead format=yuva420p after hwdownload, I get
[hwupload @ 06aaf2c0] Failed to allocate frame to upload to.
If I change both input formats to rgba *and* output format to rgba, it
works but the image's alpha is ignored, with the result being a straight
overlay of the image RGB components.
In overlay_opencl, I see
if (main_planes == overlay_planes) {
if (main_desc->nb_components == overlay_desc->nb_components)
kernel = "overlay_no_alpha";
else
kernel = "overlay_internal_alpha";
ctx->alpha_separate = 0;
} else {
kernel = "overlay_external_alpha";
ctx->alpha_separate = 1;
}
This looks wrong to me. For the purposes of overlay, only the presence
of alpha on the 2nd input matters and should be handled when present.
All tests performed with on-die Intel HD / OpenCL runtime 1.2 on Win 7
x64. My driver looks to be 3 years old.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
