Re: [FFmpeg-devel] null metadata for the first decoded video frame

[Alexander Ivash]

2018-05-21 21:02 GMT+03:00 Aman Gupta :
> On Mon, May 21, 2018 at 10:29 AM Alexander Ivash  wrote:
>
>> I'm not injecting metadata, but reading it! Here:
>>
>> https://github.com/ElderOrb/qctools/blob/master/Source/Core/VideoStats.cpp#L287
>> This function is being called for every frame. The issue is that the
>> first frame returns null.
>
>
> If you're talking about cropdetect metadata then it's because of this:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_cropdetect.c#L170
>

No, I meant 'idet' filter (beg pardon for not mentioning this in the
first place). Taking into account ffpobe does work with that video,
seems like there is an issue with how filtering pipeline is used in
QCTools.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Tuesday, May 22, 2018 8:19 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
> 
> On 21/05/18 07:50, Ruiling Song wrote:
> > This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping.
> >
> > An example command to use this filter with vaapi codecs:
> > FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \
> > opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \
> > vaapi -i INPUT -filter_hw_device ocl -filter_complex \
> > '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \
> > [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2
> OUTPUT
> >
> > Signed-off-by: Ruiling Song 
> > ---
> 
> I assume you're testing with Beignet for this sort of mapping to work?  I 
> tried it
> with Beignet on Coffee Lake with 10-bit videos and it looks sensible, though 
> it is
> rather hard to tell whether it is in some sense "correct".
> 
> Given a non-P010 input video it fails with build errors when compling the 
> kernels:
> 
> [Parsed_tonemap_opencl_1 @ 0x55b700e51540] Failed to build program: -11.
> [Parsed_tonemap_opencl_1 @ 0x55b700e51540] Build log:
> /home/mrt/video/ffmpeg/opencl/libavfilter/opencl/colorspace_basic.cl:125:19:
> error: use of undeclared identifier 'null'; did you mean 'all'?
> stringInput.cl:7:21: note: expanded from macro 'rgb_matrix'
> 
> That case should probably be caught earlier and rejected with a clear message.
Will fix it.

> 
> 
> On Mali:
> 
> $ ./ffmpeg_g -v 55 -y -i ~/test/The\ World\ in\ HDR.mkv -init_hw_device opencl
> -filter_hw_device opencl0 -an -vf
> 'format=p010,hwupload,tonemap_opencl=t=bt2020:tonemap=linear:format=p0
> 10,hwdownload,format=p010' -c:v libx264 out.mp4
> ...
> [tonemap_opencl @ 0x8201d7c0] Filter input: opencl, 3840x2160 (0).
> [Parsed_tonemap_opencl_2 @ 0x8201d760] Failed to enqueue kernel: -5.
The error seems map to OpenCL error CL_OUT_OF_RESOURCES. I don't have any idea 
yet.
May be some limitation in the driver not queried?

> 
> That's an RK3288 with a Mali T760, clinfo: , full 
> log:
> .
> 
> (The Rockchip hardware decoder can do H.265 Main 10, but the output format
> isn't P010 so it's easier to use VP9 here.)
Not p010? Then which format? Planar?
And I don't quite understand here. What the relationship of format with VP9?

> 
> 
> Some more thoughts below, I haven't read through all of it carefully.
Thanks for your comments. Answers inline.

> 
> Thanks,
> 
> - Mark
> 
> 
> >  configure  |   1 +
> >  libavfilter/Makefile   |   2 +
> >  libavfilter/allfilters.c   |   1 +
> >  libavfilter/colorspace_basic.c |  89 ++
> >  libavfilter/colorspace_basic.h |  40 +++
> >  libavfilter/opencl/colorspace_basic.cl | 179 +++
> >  libavfilter/opencl/tonemap.cl  | 258 +++
> >  libavfilter/opencl_source.h|   2 +
> >  libavfilter/vf_tonemap_opencl.c| 560
> +
> >  9 files changed, 1132 insertions(+)
> >  create mode 100644 libavfilter/colorspace_basic.c
> >  create mode 100644 libavfilter/colorspace_basic.h
> >  create mode 100644 libavfilter/opencl/colorspace_basic.cl
> >  create mode 100644 libavfilter/opencl/tonemap.cl
> >  create mode 100644 libavfilter/vf_tonemap_opencl.c
> >
> > ...
> > diff --git a/libavfilter/opencl/tonemap.cl b/libavfilter/opencl/tonemap.cl
> > new file mode 100644
> > index 000..03cf3e2
> > --- /dev/null
> > +++ b/libavfilter/opencl/tonemap.cl
> > @@ -0,0 +1,258 @@
> > +/*
> > + * 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
> > + */
> > +
> > +#define REFERENCE_WHITE 100.0f
> > +extern float3 lrgb2yuv(float3);
> > +extern float3 yuv2lrgb(float3);
> > +extern float3 lrgb2lrgb(float3);
> > +extern float get_luma_src(float3);
> > +extern float get_luma_dst(float3);
> > +extern float3 ootf(float3);
> > +extern float3 inverse_ootf(float3);
> > +struct detection_result {
> > +float peak;
> > +float average;
> > +};
>

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Niklas Haas
> Sent: Tuesday, May 22, 2018 10:28 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Mark Thompson 
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
> 
> On Tue, 22 May 2018 01:18:30 +0100, Mark Thompson  wrote:
> > On 21/05/18 07:50, Ruiling Song wrote:
> > > This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping.
> > >
> > > An example command to use this filter with vaapi codecs:
> > > FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \
> > > opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format
> \
> > > vaapi -i INPUT -filter_hw_device ocl -filter_complex \
> > > '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1];
> \
> > > [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2
> OUTPUT
> > >
> > > Signed-off-by: Ruiling Song 
> > > ---
> >
> > I assume you're testing with Beignet for this sort of mapping to work?  I 
> > tried it
> with Beignet on Coffee Lake with 10-bit videos and it looks sensible, though 
> it is
> rather hard to tell whether it is in some sense "correct".
> 
> It's also rather hard to define whether it is in some sense "correct".
> The methodology employed here is generally based on ITU-R
> recommendations, however the ITU-R advises multiple possible ways of
> doing tone-mapping. They also highlight their own curve function, which
> we don't use (for performance/simplicity reasons - iirc I gave it a try
> and the result was not visually dissimilar enough from the hable
> function, but my memory could be wrong). There's nothing resembling an
> official "standard" way to tone-map defined by the ITU-R.
> 
> This algorithm is also generally based on the results obtained from the
> "official" ACES implementation of HDR->SDR tone mapping (obtainable
> here: https://github.com/ampas/aces-dev), with the key difference that
> we do chroma-invariant tone mapping whereas hollywood tends to use
> channel-independent tone mapping. I think the latter distorts the colors
> too much for taste and generally results in a worse looking image. The
> only important bit to make chroma-invariant tone mapping work well,
> however, is the need for a good desaturation algorithm. This one is
> based on original research and experimentation. The desaturation
> strength with a parameter of 1.0 is comparable to the one achieved by
> the ACES algorithm, although I pick a lower strength by default (0.5),
> because I found it too damaging for some types of sources (particularly
> bright skies) as a result of the chroma-invariant nature.
> 
> In addition to the desaturation step, the other key innovation which I
> cannot find mentioned in ITU-R literature is the importance of adjusting
> the overall average brightness before tone mapping. I suspect the reason
> this isn't considered by the ITU-R is because the ITU-R assumes that HDR
> sources actually follow their standards, which in practice none seem to
> do. In theory, HDR material isn't supposed to have a significantly
> higher average brightness than SDR material. Apart from the addition of
> isolated super-highlights, nothing should have changed about the image
> appearance. In practice, HDR directors like to point their expensive
> cameras at very bright objects (e.g. the sun) and blind viewers' eyes by
> failing to adjust the brightness during the mastering step. Our
> algorithm compensates for this by essentially "correcting" the bad
> mastering in real-time. [1] Of course, the result here is not as good as
> doing it ahead of time by a human, but unfortunately we don't have a say
> in this matter.
> 
> As long as the implementation is correct, I'd be confident in assuming
> that this produces pleasurable results for all the sources I've thrown
> at it, often even exceeding in quality the "official" SDR-mapped blu-ray
> versions of the same sources on the same scenes. (Partially due to the
> preserved higher color gamut)
> 
> In order to ascertain whether or not the implementation is correct, you
> could compare it to results obtained by latest `mpv` (might need git
> master) or `libplacebo`, both of which implement the same algorithm.
> 
> 
> [1] The algorithm I use in mpv and libplacebo does this with one frame
> of latency, because I don't want to round-trip through an intermediate
> buffer in my processing chain, and there's no other way to communicate
> back the measured frame statistics to the rest of the kernels in
> OpenGL/Vulkan land. I do this because of my realtime requirements as
> well as the structure of my processing chain.
> 
> Since you are implementing an offline filter and neither of these
> restrictions apply to you, I would recommend changing the implementation
> to separate the peak measurement step from the tone mapping step, so
> that the former completes first and then the second runs from scratch
> and can use the results 

Re: [FFmpeg-devel] [PATCH 2/5] avformat/bintext: Reduce detection for random .bin files as it more likely is not a multimedia related file

[Michael Niedermayer]

On Sat, May 12, 2018 at 06:33:26PM +0200, Michael Niedermayer wrote:
> Iam not sure if this is a good idea or not but it may make some
> attacks harder. So throwing this out for discussions ...
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/bintext.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply this

[...]
-- 
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

[Mark Thompson]

On 22/05/18 09:48, Song, Ruiling wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Tuesday, May 22, 2018 8:19 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
>>
>> On 21/05/18 07:50, Ruiling Song wrote:
>>> This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping.
>>>
>>> An example command to use this filter with vaapi codecs:
>>> FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \
>>> opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \
>>> vaapi -i INPUT -filter_hw_device ocl -filter_complex \
>>> '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \
>>> [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2
>> OUTPUT
>>>
>>> Signed-off-by: Ruiling Song 
>>> ---
>>
>> ...
>>
>>
>> On Mali:
>>
>> $ ./ffmpeg_g -v 55 -y -i ~/test/The\ World\ in\ HDR.mkv -init_hw_device 
>> opencl
>> -filter_hw_device opencl0 -an -vf
>> 'format=p010,hwupload,tonemap_opencl=t=bt2020:tonemap=linear:format=p0
>> 10,hwdownload,format=p010' -c:v libx264 out.mp4
>> ...
>> [tonemap_opencl @ 0x8201d7c0] Filter input: opencl, 3840x2160 (0).
>> [Parsed_tonemap_opencl_2 @ 0x8201d760] Failed to enqueue kernel: -5.
> The error seems map to OpenCL error CL_OUT_OF_RESOURCES. I don't have any 
> idea yet.
> May be some limitation in the driver not queried?
> 
>>
>> That's an RK3288 with a Mali T760, clinfo: , full 
>> log:
>> .
>>
>> (The Rockchip hardware decoder can do H.265 Main 10, but the output format
>> isn't P010 so it's easier to use VP9 here.)
> Not p010? Then which format? Planar?

It's two-plane like P010, but with the samples packed together to minimise the 
memory use - I think it uses all the bits to give you four (4 x 10 = 40 bits) 
luma samples (or two times two component chroma samples) in each five bytes (5 
x 8 = 40 bits).  This form probably isn't usable directly by anything generic 
like OpenCL without more magic, though Rockchip's KMS and related processing 
code can handle it.

> And I don't quite understand here. What the relationship of format with VP9?

Oh, sorry - that's coming from the mostly-unrelated point that VP9 has much 
better software decode support in libavcodec.  Irrelevant, really - H.265 will 
also work.


>>> ...
>>> +
>>> +// detect peak/average signal of a frame, the algorithm was ported from:
>>> +// libplacebo (https://github.com/haasn/libplacebo)
>>> +struct detection_result
>>> +detect_peak_avg(global uint *util_buf, __local uint *sum_wg,
>>> +float signal, float peak) {
>>> +global uint *avg_buf = util_buf;
>>> +global uint *peak_buf = avg_buf + DETECTION_FRAMES + 1;
>>> +global uint *counter_wg_p = peak_buf + DETECTION_FRAMES + 1;
>>> +global uint *max_total_p = counter_wg_p + 1;
>>> +global uint *avg_total_p = max_total_p + 1;
>>> +global uint *frame_idx_p = avg_total_p + 1;
>>> +global uint *scene_frame_num_p = frame_idx_p + 1;
>>> +
>>> +uint frame_idx = *frame_idx_p;
>>> +uint scene_frame_num = *scene_frame_num_p;
>>> +
>>> +size_t lidx = get_local_id(0);
>>> +size_t lidy = get_local_id(1);
>>> +size_t lsizex = get_local_size(0);
>>> +size_t lsizey = get_local_size(1);
>>> +uint num_wg = get_num_groups(0) * get_num_groups(1);
>>> +size_t group_idx = get_group_id(0);
>>> +size_t group_idy = get_group_id(1);
>>> +struct detection_result r = {peak, sdr_avg};
>>> +*sum_wg = 0;
>>
>> This is technically a data race - maybe set it in only the first workitem?
> When writing same value to it, this may be fine, we should still get correct 
> result.
> But I agree it is better to only ask the first work-item to do the 
> initialization.

C/C++ make it undefined behaviour, so even if when it's benign like this 
(writing the same value) I would prefer to avoid it.

>>> +barrier(CLK_LOCAL_MEM_FENCE);
>>> +
>>> +// update workgroup sum
>>> +atomic_add(sum_wg, (uint)(signal * REFERENCE_WHITE));
>>
>> I think the numbers you're adding together here sum to at most something like
>> 16 * 16 * 100 * 1023?  Can you make sure this can't overflow and add a
>> comment on that.
> Niklas also pointed this out. It is 16 * 16 * 1 at max. so, no overflow 
> here.
> 
>>
>>> +barrier(CLK_LOCAL_MEM_FENCE);
>>> +
>>> +// update frame peak/avg using work-group-average.
>>> +if (lidx == 0 && lidy == 0) {
>>> +uint avg_wg = *sum_wg / (lsizex * lsizey);
>>> +atomic_max(&peak_buf[frame_idx], avg_wg);
>>> +atomic_add(&avg_buf[frame_idx], avg_wg);
>>
>> Similarly this one?  (width/16 * height/16 * 100 * 1023, I think, which might
>> overflow for 8K?)
>>
>>> +}
>>> +
>>> +if (scene_frame_num > 0) {
>>> +float peak = (float)*max_total_p / (REFERENCE_WHITE *
>> scene_frame_num);
>>> +float avg = (flo

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

[Niklas Haas]

On Tue, 22 May 2018 08:56:37 +, "Song, Ruiling"  
wrote:
> Yes, your idea sounds reasonable. But it may need much effort to re-structure 
> the code to make it (that would launch two kernels, and we may need a wait 
> between them) and evaluate the performance.

Actually, a brute force solution to solve the missing peak problem would
be to filter the first frame twice and discard the first result. (After
that, you only need to filter each frame once, so the overall
performance characteristic is unchanged for videos)

That requires minimal code change, and it still allows it to work for
single-frame video sources. It also prevents an initial flash of the
wrong brightness level for transcoded videos.

Also, performnace wise, I'm not sure how this works in OpenCL land, but
in OpenGL/Vulkan, you'd just need to emit a pipeline barrier. That
allows the kernels to synchronize without having to stall the pipeline
by doing a CPU wait. (And, in general, you'd need a pipeline barrier
even if you *are* running glFinish() afterwards - the pipeline barrier
isn't just for timing, it's also for flushing the appropriate caches. In
general, write visibility on storage buffers requires a pipeline
barrier. Are you sure this is not the case for OpenCL as well?)

> Although we are developing offline filter, I think that performance is still 
> very important as well as quality.
> Given that the current implementation does well for video transcoding. I 
> would leave it in my TODO list. Sounds ok?

ACK. It's not my decision, I'm just offering advice.

> Are you talking about display-referred HLG? I didn't update frame side 
> channel data.
> I am not sure when do I need to update it. I thought all HLG should be 
> scene-referred, seems not?
> Could you tell me more about display-referred HLG?

There's no such thing as "display-referred HLG". HLG by definition is
encoded as scene-referred, but the OOTF to convert from scene-referred
to display-referred is part of the EOTF (also by definition).

So the HLG EOTF inputs scene-referred and outputs display-referred. When
you apply the EOTF (including the OOTF) as part of your processing
chain, you're turning it into a linear light display referred signal.
The tone mapping then happens on this signal (in display light), and
then to turn it back to HLG after you're done tone-mapping you apply the
inverse OOTF + OETF, thus turning it back into scene referred light.

The HLG OOTF (and therefore the EOTF) is parametrized by the display
peak. Even though the HLG signal is stored in the range 0.0 - 12.0
(scene referred), the output range depends on how you tuned the EOTF. If
you tuned it for the 1000 cd/m^2 reference display, then an input of
12.0 will get turned into an output value of 1000 cd/m^2.

If we then tone-map this to a brightness of 500 cd/m^2, and pass it back
through the same OOTF, it would get turned into 6.0 rather than the
12.0. While this may ultimately reproduce the correct result on-screen
(assuming the end user of the video file also uses a peak of 1000 cd/m^2
to decode the file), it's a suboptimal use of the encoding range and
also not how HLG is designed to operate. (For example, it would affect
the "SDR backwards compatibility" property of HLG, which is the whole
reason for the peak-dependent encoding)

That's why the correct thing to do would be to re-encode the file using
an inverse OOTF tuned for 500 cd/m², thus taking our tone mapped value
in question back to the (scene-referred) value of 12.0, and update the
tagged peak to also read 500 cd/m². Now a spec-conforming implementation
of a video player (e.g. mpv or VLC) that plays this file would use the
same tuned EOTF to decode it back to the value of 500 cd/m², thus
ensuring it round trips correctly.

> I don't find anything about it. What metadata in HEVC indicate 
> display-referred?
> Any display-referred HLG video sample?

As mentioned, the HLG EOTF by definition requires transforming to
display-referred space. The mastering display metadata *is* what
describes how this (definitively display-referred) space behaves. So
when decoding HLG, you use the tagged mastering metadata's peak as the
parametrization for the EOTF. (This is what e.g. mpv and VLC do)

For a better explanation of this (admittedly confusing) topic, see Annex
1 of ITU-R Recommendation BT.2100.

Here is a relevant excerpt: http://0x0.st/se7O.png
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] libavformat/mov: recognize udta name tag as the stream title

[Michael Niedermayer]

On Mon, May 21, 2018 at 12:14:03PM -0700, Nik Johnson wrote:
> Some muxers write the stream title in a udta atom with the tag 'name'.
> Recognize 'name' tags as the stream title instead of an unknown tag.
> 
> Signed-off-by: Nik Johnson 
> ---
> [v2: Add raw = 1]
> 
>  libavformat/mov.c | 1 +
>  1 file changed, 1 insertion(+)

a fate testcase for this would be a usefull i think unless there is no
small sample

thx

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

[FFmpeg-devel] [PATCH][ticket #5522] lavc/cfhd: interlaced frame decoding added

[Gagandeep Singh]

ticket #5522 output of given samples significantly improved
---
 libavcodec/cfhd.c | 181 +++---
 libavcodec/cfhd.h |   9 +++
 2 files changed, 155 insertions(+), 35 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 7ceb803595..051d210355 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -49,12 +49,15 @@ enum CFHDParam {
 SubbandNumber=  48,
 Quantization =  53,
 ChannelNumber=  62,
+SampleFlags  =  68,
 BitsPerComponent = 101,
 ChannelWidth = 104,
 ChannelHeight= 105,
 PrescaleShift= 109,
 };
 
+
+
 static av_cold int cfhd_init(AVCodecContext *avctx)
 {
 CFHDContext *s = avctx->priv_data;
@@ -72,6 +75,13 @@ static void init_plane_defaults(CFHDContext *s)
 s->subband_num_actual = 0;
 }
 
+static void init_peak_table_defaults(CFHDContext *s)
+{
+s->peak.level  = 0;
+s->peak.offset = 0;
+s->peak.base   = NULL;
+}
+
 static void init_frame_defaults(CFHDContext *s)
 {
 s->coded_width   = 0;
@@ -86,15 +96,44 @@ static void init_frame_defaults(CFHDContext *s)
 s->wavelet_depth = 3;
 s->pshift= 1;
 s->codebook  = 0;
+s->difference_coding = 0;
+s->progressive   = 0;
 init_plane_defaults(s);
+init_peak_table_defaults(s);
 }
 
 /* TODO: merge with VLC tables or use LUT */
-static inline int dequant_and_decompand(int level, int quantisation)
+static inline int dequant_and_decompand(int level, int quantisation, int 
codebook)
+{
+if (codebook == 0 || codebook == 1) {
+int64_t abslevel = abs(level);
+if (level < 264)
+return (abslevel + ((768 * abslevel * abslevel * abslevel) / (255 
* 255 * 255))) *
+   FFSIGN(level) * quantisation;
+else
+return level * quantisation;
+} else
+return level * quantisation;
+}
+
+static inline void difference_coding(int16_t *band, int width, int height)
+{
+
+int i,j;
+for (i = 0; i < height; i++) {
+for (j = 1; j < width; j++) {
+  band[j] += band[j-1];
+}
+band += width;
+}
+}
+
+static inline void peak_table(int16_t *band, Peak *peak, int length)
 {
-int64_t abslevel = abs(level);
-return (abslevel + ((768 * abslevel * abslevel * abslevel) / (255 * 255 * 
255))) *
-   FFSIGN(level) * quantisation;
+int i;
+for (i = 0; i < length; i++)
+if (abs(band[i]) > peak->level)
+band[i] = *(peak->base++);
 }
 
 static inline void process_alpha(int16_t *alpha, int width)
@@ -154,6 +193,18 @@ static inline void filter(int16_t *output, ptrdiff_t 
out_stride,
 }
 }
 
+static inline void interlaced_vertical_filter(int16_t *output, int16_t *low, 
int16_t *high,
+ int width, int linesize, int plane)
+{
+int i;
+int16_t even, odd;
+for (i = 0; i < width; i++) {
+even = (low[i] - high[i])/2;
+odd  = (low[i] + high[i])/2;
+output[i]= av_clip_uintp2(even, 10);
+output[i + linesize] = av_clip_uintp2(odd, 10);
+}
+}
 static void horiz_filter(int16_t *output, int16_t *low, int16_t *high,
  int width)
 {
@@ -295,6 +346,9 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 uint16_t data   = bytestream2_get_be16(&gb);
 if (abs_tag8 >= 0x60 && abs_tag8 <= 0x6f) {
 av_log(avctx, AV_LOG_DEBUG, "large len %x\n", ((tagu & 0xff) << 
16) | data);
+} else if (tag == SampleFlags) {
+av_log(avctx, AV_LOG_DEBUG, "Progressive?%"PRIu16"\n", data);
+s->progressive = data & 0x0001;
 } else if (tag == ImageWidth) {
 av_log(avctx, AV_LOG_DEBUG, "Width %"PRIu16"\n", data);
 s->coded_width = data;
@@ -393,6 +447,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 }
 av_log(avctx, AV_LOG_DEBUG, "Transform-type? %"PRIu16"\n", data);
 } else if (abstag >= 0x4000 && abstag <= 0x40ff) {
+if (abstag == 0x4001)
+s->peak.level = 0;
 av_log(avctx, AV_LOG_DEBUG, "Small chunk length %d %s\n", data * 
4, tag < 0 ? "optional" : "required");
 bytestream2_skipu(&gb, data * 4);
 } else if (tag == 23) {
@@ -450,7 +506,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 s->codebook = data;
 av_log(avctx, AV_LOG_DEBUG, "Codebook %i\n", s->codebook);
 } else if (tag == 72) {
-s->codebook = data;
+s->codebook = data & 0xf;
+s->difference_coding = (data >> 4) & 1;
 av_log(avctx, AV_LOG_DEBUG, "Other codebook? %i\n", s->codebook);
 } else if (tag == 70) {
 av_log(avctx, AV_LOG_DEBUG, "Subsampling or bit-depth flag? %i\n", 
data);
@@ -477,6 +534,19 @@ static int cfhd_decode(AVCodecContext *avctx, void *da

Re: [FFmpeg-devel] [PATCH] avformat/hls: Properly expose intercepted ID3 tags to the API.

[Richard Shaffer]

I just wanted to send a reminder about this patch...

wm4 had some concerns about publishing a metadata update on each timestamp
(which would essentially be on each segment). I updated it to not set the
metadata updated event flag in those cases, although it will still add that
metadata to the dictionary. I'm not sure if this is exactly the compromise
he had in mind. Any comments on this would be appreciated.

Of course, if anyone else has an opinion or can take the time to review
this, that would be great, too.

Much thanks,

-Richard

On Thu, May 17, 2018 at 8:49 PM,  wrote:

> From: Richard Shaffer 
>
> The HLS demuxer will process any ID3 tags at the beginning of a segment in
> order to obtain timestamp data. However, when this data was parsed on a
> second
> or subsequent segment, the updated metadata would be discarded. This change
> preserves the data and also sets the AVSTREAM_EVENT_FLAG_METADATA_UPDATED
> event flag when appropriate.
> ---
>  libavformat/hls.c | 34 +++---
>  1 file changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3d4f7f2647..3e2edb3484 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -982,18 +982,8 @@ static void parse_id3(AVFormatContext *s, AVIOContext
> *pb,
>  }
>
>  /* Check if the ID3 metadata contents have changed */
> -static int id3_has_changed_values(struct playlist *pls, AVDictionary
> *metadata,
> -  ID3v2ExtraMetaAPIC *apic)
> +static int id3_has_changed_values(struct playlist *pls,
> ID3v2ExtraMetaAPIC *apic)
>  {
> -AVDictionaryEntry *entry = NULL;
> -AVDictionaryEntry *oldentry;
> -/* check that no keys have changed values */
> -while ((entry = av_dict_get(metadata, "", entry,
> AV_DICT_IGNORE_SUFFIX))) {
> -oldentry = av_dict_get(pls->id3_initial, entry->key, NULL,
> AV_DICT_MATCH_CASE);
> -if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
> -return 1;
> -}
> -
>  /* check if apic appeared */
>  if (apic && (pls->ctx->nb_streams != 2 || !pls->ctx->streams[1]->
> attached_pic.data))
>  return 1;
> @@ -1019,6 +1009,15 @@ static void handle_id3(AVIOContext *pb, struct
> playlist *pls)
>  int64_t timestamp = AV_NOPTS_VALUE;
>
>  parse_id3(pls->ctx, pb, &metadata, ×tamp, &apic, &extra_meta);
> +ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> +av_dict_copy(&pls->ctx->metadata, metadata, 0);
> +/*
> + * If we've handled any ID3 metadata here, it's not going to be seen
> by the
> + * sub-demuxer. In the case that we got here because of an IO call
> during
> + * hls_read_header, this will be cleared. Otherwise, it provides the
> + * necessary hint to hls_read_packet that there is new metadata.
> + */
> +pls->ctx->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
>
>  if (timestamp != AV_NOPTS_VALUE) {
>  pls->id3_mpegts_timestamp = timestamp;
> @@ -1037,12 +1036,10 @@ static void handle_id3(AVIOContext *pb, struct
> playlist *pls)
>  /* demuxer not yet opened, defer picture attachment */
>  pls->id3_deferred_extra = extra_meta;
>
> -ff_id3v2_parse_priv_dict(&metadata, &extra_meta);
> -av_dict_copy(&pls->ctx->metadata, metadata, 0);
>  pls->id3_initial = metadata;
>
>  } else {
> -if (!pls->id3_changed && id3_has_changed_values(pls, metadata,
> apic)) {
> +if (!pls->id3_changed && id3_has_changed_values(pls, apic)) {
>  avpriv_report_missing_feature(pls->ctx, "Changing ID3
> metadata in HLS audio elementary stream");
>  pls->id3_changed = 1;
>  }
> @@ -1939,8 +1936,15 @@ static int hls_read_header(AVFormatContext *s)
>   * Copy any metadata from playlist to main streams, but do not set
>   * event flags.
>   */
> -if (pls->n_main_streams)
> +if (pls->n_main_streams) {
>  av_dict_copy(&pls->main_streams[0]->metadata,
> pls->ctx->metadata, 0);
> +/*
> + * If we've intercepted metadata, we will have set this event
> flag.
> + * Clear it to avoid confusion, since otherwise we will flag
> it as
> + * new metadata on the next call to hls_read_packet.
> + */
> +pls->ctx->event_flags = ~AVFMT_EVENT_FLAG_METADATA_UPDATED;
> +}
>
>  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_AUDIO);
>  add_metadata_from_renditions(s, pls, AVMEDIA_TYPE_VIDEO);
> --
> 2.15.1 (Apple Git-101)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] libavformat/mov: recognize udta name tag as the stream title

[Michael Niedermayer]

On Mon, May 21, 2018 at 12:14:03PM -0700, Nik Johnson wrote:
> Some muxers write the stream title in a udta atom with the tag 'name'.
> Recognize 'name' tags as the stream title instead of an unknown tag.
> 
> Signed-off-by: Nik Johnson 
> ---
> [v2: Add raw = 1]
> 
>  libavformat/mov.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 5332d48eb1..09e3096a06 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -340,6 +340,7 @@ static int mov_read_udta_string(MOVContext *c, 
> AVIOContext *pb, MOVAtom atom)
>  return mov_metadata_loci(c, pb, atom.size);
>  case MKTAG( 'm','a','n','u'): key = "make"; break;
>  case MKTAG( 'm','o','d','l'): key = "model"; break;
> +case MKTAG( 'n','a','m','e'): key = "title"; raw = 1; break;
>  case MKTAG( 'p','c','s','t'): key = "podcast";
>  parse = mov_metadata_int8_no_padding; break;
>  case MKTAG( 'p','g','a','p'): key = "gapless_playback";

for
./ffmpeg -i ~/tickets/4938/2014-11-30\ 23.59.04-hb.mp4
file should be linked at https://trac.ffmpeg.org/ticket/4938

this produces:
 
 title   : Mono
 
is this intended ?


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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

[FFmpeg-devel] [PATCH] libavformat/mxfenc: Add some () to attempt to workaround build issue on osx

[Michael Niedermayer]

May fix ticket7209

Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 44425bf6c9..77f60f5874 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1149,23 +1149,23 @@ static int get_trc(UID ul, enum 
AVColorTransferCharacteristic trc)
 switch (trc){
 case AVCOL_TRC_GAMMA28   :
 case AVCOL_TRC_GAMMA22   :
-memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x01,0x00,0x00},
 16);
+memcpy(ul, 
((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x01,0x00,0x00}),
 16);
 return 0;
 case AVCOL_TRC_BT709 :
 case AVCOL_TRC_SMPTE170M :
-memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x02,0x00,0x00},
 16);
+memcpy(ul, 
((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x02,0x00,0x00}),
 16);
 return 0;
 case AVCOL_TRC_SMPTE240M :
-memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x03,0x00,0x00},
 16);
+memcpy(ul, 
((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x03,0x00,0x00}),
 16);
 return 0;
 case AVCOL_TRC_BT1361_ECG:
-memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x05,0x00,0x00},
 16);
+memcpy(ul, 
((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x05,0x00,0x00}),
 16);
 return 0;
 case AVCOL_TRC_LINEAR:
-memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x06,0x00,0x00},
 16);
+memcpy(ul, 
((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x06,0x00,0x00}),
 16);
 return 0;
 case AVCOL_TRC_SMPTE428  :
-memcpy(ul, 
(UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x08,0x04,0x01,0x01,0x01,0x01,0x07,0x00,0x00},
 16);
+memcpy(ul, 
((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x08,0x04,0x01,0x01,0x01,0x01,0x07,0x00,0x00}),
 16);
 return 0;
 default:
 return -1;
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: replace a value error by clipping into valid range in mov_read_stsc()

[Michael Niedermayer]

On Mon, May 21, 2018 at 03:16:58AM +0200, Michael Niedermayer wrote:
> Fixes: #7165
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mov.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)

will apply


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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

[FFmpeg-devel] [PATCH] avformat/mov: Discard redundant and invalid STSC entries

[Michael Niedermayer]

This reduces the amount of log message noise for files that contain
many such redundant entries

Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index f2a540ad50..b555c8cb7f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2638,6 +2638,13 @@ static int mov_read_stsc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 sc->stsc_data[i].first = avio_rb32(pb);
 sc->stsc_data[i].count = avio_rb32(pb);
 sc->stsc_data[i].id = avio_rb32(pb);
+if (i &&
+sc->stsc_data[i].count == sc->stsc_data[i-1].count &&
+sc->stsc_data[i].id== sc->stsc_data[i-1].id &&
+sc->stsc_data[i].first >= sc->stsc_data[i-1].first) {
+i --;
+entries --;
+}
 }
 
 sc->stsc_count = i;
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH][ticket #5522] lavc/cfhd: interlaced frame decoding added

[Carl Eugen Hoyos]

2018-05-22 17:40 GMT+02:00, Gagandeep Singh :

> +low= s->plane[plane].subband[0];
> +high   = s->plane[plane].subband[8];
> +output = s->plane[plane].l_h[6];
> +for (i = 0; i < lowpass_width; i++) {
> +vert_filter(output, lowpass_width, low, lowpass_width,
> high, highpass_stride, lowpass_height);
> +low++;
> +high++;
> +output++;
> +}
>
> -low= s->plane[plane].subband[0];
> -high   = s->plane[plane].subband[8];
> -output = s->plane[plane].l_h[6];
> -for (i = 0; i < lowpass_width; i++) {
> -vert_filter(output, lowpass_width, low, lowpass_width, high,
> highpass_stride, lowpass_height);
> -low++;
> -high++;
> -output++;
> -}

The patch will get much more readable (and easier to review)
if you do not re-indent, instead send a second patch with the
cosmetic changes only.

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

Re: [FFmpeg-devel] [PATCH] [WIP] libopusdec: Enable FEC/PLC

[Steinar H. Gunderson]

On Tue, May 15, 2018 at 12:35:45AM +0200, Steinar H. Gunderson wrote:
> Whenever we detect a discontinuity in the incoming stream, ask libopus
> to make up intermediate frames based on the first one we actually have
> after the discontinuity. If the stream contains FEC data (basically a
> low-quality side stream that is delayed by one packet), libopus will
> decode that. If not, it will activate PLC (packet loss concealment),
> which tries to synthesize some reasonable-sounding frame based on the
> previous audio. It will usually be audible, but it's much better than
> just playing silence.

Anyone interested in picking up this?

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Add some () to attempt to workaround build issue on osx

[James Almer]

On 5/22/2018 3:57 PM, Michael Niedermayer wrote:
> May fix ticket7209
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfenc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 44425bf6c9..77f60f5874 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -1149,23 +1149,23 @@ static int get_trc(UID ul, enum 
> AVColorTransferCharacteristic trc)
>  switch (trc){
>  case AVCOL_TRC_GAMMA28   :
>  case AVCOL_TRC_GAMMA22   :
> -memcpy(ul, 
> (UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x01,0x00,0x00},
>  16);
> +memcpy(ul, 
> ((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x01,0x00,0x00}),
>  16);
>  return 0;
>  case AVCOL_TRC_BT709 :
>  case AVCOL_TRC_SMPTE170M :
> -memcpy(ul, 
> (UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x02,0x00,0x00},
>  16);
> +memcpy(ul, 
> ((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x02,0x00,0x00}),
>  16);
>  return 0;
>  case AVCOL_TRC_SMPTE240M :
> -memcpy(ul, 
> (UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x03,0x00,0x00},
>  16);
> +memcpy(ul, 
> ((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x03,0x00,0x00}),
>  16);
>  return 0;
>  case AVCOL_TRC_BT1361_ECG:
> -memcpy(ul, 
> (UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x05,0x00,0x00},
>  16);
> +memcpy(ul, 
> ((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x05,0x00,0x00}),
>  16);
>  return 0;
>  case AVCOL_TRC_LINEAR:
> -memcpy(ul, 
> (UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x06,0x00,0x00},
>  16);
> +memcpy(ul, 
> ((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x06,0x00,0x00}),
>  16);
>  return 0;
>  case AVCOL_TRC_SMPTE428  :
> -memcpy(ul, 
> (UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x08,0x04,0x01,0x01,0x01,0x01,0x07,0x00,0x00},
>  16);
> +memcpy(ul, 
> ((UID){0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x08,0x04,0x01,0x01,0x01,0x01,0x07,0x00,0x00}),
>  16);
>  return 0;
>  default:
>  return -1;

Why not just declare these as static const like mxf_mpeg2_codec_uls or
the descriptor keys right above this function?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Patrick Keroulas]

- Original Message -
> From: "Rostislav Pehlivanov" 
> To: "FFmpeg development discussions and patches" 
> Sent: Friday, May 18, 2018 5:28:42 PM
> Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets 
> with top/bottom field

> On 18 May 2018 at 22:17, wm4  wrote:



> > But I think a new side data type would be much saner. We could even
> > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > something. It's apparently just packet data which somehow couldn't go
> > into the packet data.


> I agree, a generic ancillary side data type sounds better. It would have to
> be handled the same way as mastering metadata (e.g. to allocate it you'd
> need to use a separate function), since the size of the data struct can't
> be part of the API if we intend to add fields later.
> Patrick, if you're okay with that you should submit a patch which bases
> such side data on libavutil/mastering_display_metadata.h/.c

No problem for transmitting field flags through side data. But the given
example (libavutil/mastering_display_metadata.h/.c) attaches data to
AVFrame, not AVPacket, so I'm not sure where to place this separate
allocator function. Do you recommend to create a new 
libavcodec/ancillary.c/h utility?

> ___
> 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][ticket #5522] lavc/cfhd: interlaced frame decoding added

[Hendrik Leppkes]

On Tue, May 22, 2018 at 10:35 PM, Carl Eugen Hoyos  wrote:
> 2018-05-22 17:40 GMT+02:00, Gagandeep Singh :
>
>> +low= s->plane[plane].subband[0];
>> +high   = s->plane[plane].subband[8];
>> +output = s->plane[plane].l_h[6];
>> +for (i = 0; i < lowpass_width; i++) {
>> +vert_filter(output, lowpass_width, low, lowpass_width,
>> high, highpass_stride, lowpass_height);
>> +low++;
>> +high++;
>> +output++;
>> +}
>>
>> -low= s->plane[plane].subband[0];
>> -high   = s->plane[plane].subband[8];
>> -output = s->plane[plane].l_h[6];
>> -for (i = 0; i < lowpass_width; i++) {
>> -vert_filter(output, lowpass_width, low, lowpass_width, high,
>> highpass_stride, lowpass_height);
>> -low++;
>> -high++;
>> -output++;
>> -}
>
> The patch will get much more readable (and easier to review)
> if you do not re-indent, instead send a second patch with the
> cosmetic changes only.
>

Except, no sane developer works like that. In fact many editors will
even indent for you automatically if you add new blocks, so splitting
this is a really annoying task to perform.
Instead, may I suggest a proper patch viewer which can ignore
whitespace changes? It makes reading patches with indent changes
trivial.

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

Re: [FFmpeg-devel] [PATCH][ticket #5522] lavc/cfhd: interlaced frame decoding added

[Carl Eugen Hoyos]

2018-05-23 0:21 GMT+02:00, Hendrik Leppkes :
> On Tue, May 22, 2018 at 10:35 PM, Carl Eugen Hoyos 
> wrote:
>> 2018-05-22 17:40 GMT+02:00, Gagandeep Singh :
>>
>>> +low= s->plane[plane].subband[0];
>>> +high   = s->plane[plane].subband[8];
>>> +output = s->plane[plane].l_h[6];
>>> +for (i = 0; i < lowpass_width; i++) {
>>> +vert_filter(output, lowpass_width, low, lowpass_width,
>>> high, highpass_stride, lowpass_height);
>>> +low++;
>>> +high++;
>>> +output++;
>>> +}
>>>
>>> -low= s->plane[plane].subband[0];
>>> -high   = s->plane[plane].subband[8];
>>> -output = s->plane[plane].l_h[6];
>>> -for (i = 0; i < lowpass_width; i++) {
>>> -vert_filter(output, lowpass_width, low, lowpass_width, high,
>>> highpass_stride, lowpass_height);
>>> -low++;
>>> -high++;
>>> -output++;
>>> -}
>>
>> The patch will get much more readable (and easier to review)
>> if you do not re-indent, instead send a second patch with the
>> cosmetic changes only.
>>
>
> Except, no sane developer works like that.

It's great to know that you are so much smarter than most developers,
I will forward the next regression directly to you to fix it.

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

Re: [FFmpeg-devel] [PATCH]configure: Support libxml2 on systems without pkg-config

[Carl Eugen Hoyos]

2018-05-18 12:16 GMT+02:00, Nicolas George :
> Carl Eugen Hoyos (2018-05-14):
>> No, you have many times refused to allow them being solved.
>
> I have opposer your solutions because I think they are bad solutions and
> I can see a better one.

Sadly, no user shares your opinion.

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

[FFmpeg-devel] [PATCH] ffmpeg.c: allow ffmpeg to output stats for each video stream

[Wang Cao]

- Make ffmpeg to output stats for each video/audio streams and each ouptut file 
ffmpeg output log in print_report.
- The report of video/audio sizes is clear as previously all output
video/audio sizes were combined to report and it is unclear such stats
is for one output files or aggregates for all output files.

Signed-off-by: Wang Cao 
---
 fftools/ffmpeg.c | 65 
 1 file changed, 44 insertions(+), 21 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5a19a09d9a..0b98521852 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1526,17 +1526,28 @@ static int reap_filters(int flush)
 return 0;
 }
 
-static void print_final_stats(int64_t total_size)
+static void print_final_stats()
 {
 uint64_t video_size = 0, audio_size = 0, extra_size = 0, other_size = 0;
 uint64_t subtitle_size = 0;
 uint64_t data_size = 0;
+int64_t total_size;
 float percent = -1.0;
 int i, j;
 int pass1_used = 1;
+AVFormatContext *oc;
 
 for (i = 0; i < nb_output_streams; i++) {
 OutputStream *ost = output_streams[i];
+if (i > 0 && ost->file_index != output_streams[i-1]->file_index) {
+video_size = 0;
+audio_size = 0;
+extra_size = 0;
+other_size = 0;
+subtitle_size = 0;
+data_size = 0;
+}
+
 switch (ost->enc_ctx->codec_type) {
 case AVMEDIA_TYPE_VIDEO: video_size += ost->data_size; break;
 case AVMEDIA_TYPE_AUDIO: audio_size += ost->data_size; break;
@@ -1545,25 +1556,37 @@ static void print_final_stats(int64_t total_size)
 }
 extra_size += ost->enc_ctx->extradata_size;
 data_size  += ost->data_size;
+
 if (   (ost->enc_ctx->flags & (AV_CODEC_FLAG_PASS1 | 
AV_CODEC_FLAG_PASS2))
 != AV_CODEC_FLAG_PASS1)
 pass1_used = 0;
-}
-
+
+// Print stats for each output file.
+if (i == nb_output_streams-1 || ost->file_index != 
output_streams[i+1]->file_index) {
+oc = output_files[ost->file_index]->ctx; 
+total_size =  avio_size(oc->pb);
+if (total_size <= 0) // FIXME improve avio_size() so it works with 
non seekable output too
+total_size = avio_tell(oc->pb);
+
 if (data_size && total_size>0 && total_size >= data_size)
 percent = 100.0 * (total_size - data_size) / data_size;
-
+
 av_log(NULL, AV_LOG_INFO, "video:%1.0fkB audio:%1.0fkB subtitle:%1.0fkB 
other streams:%1.0fkB global headers:%1.0fkB muxing overhead: ",
video_size / 1024.0,
audio_size / 1024.0,
subtitle_size / 1024.0,
other_size / 1024.0,
extra_size / 1024.0);
+   
 if (percent >= 0.0)
 av_log(NULL, AV_LOG_INFO, "%f%%", percent);
 else
 av_log(NULL, AV_LOG_INFO, "unknown");
 av_log(NULL, AV_LOG_INFO, "\n");
+}
+}
+
+
 
 /* print verbose per-stream stats */
 for (i = 0; i < nb_input_files; i++) {
@@ -1676,13 +1699,6 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 
 t = (cur_time-timer_start) / 100.0;
 
-
-oc = output_files[0]->ctx;
-
-total_size = avio_size(oc->pb);
-if (total_size <= 0) // FIXME improve avio_size() so it works with non 
seekable output too
-total_size = avio_tell(oc->pb);
-
 vid = 0;
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
 av_bprint_init(&buf_script, 0, 1);
@@ -1693,12 +1709,13 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 if (!ost->stream_copy)
 q = ost->quality / (float) FF_QP2LAMBDA;
 
-if (vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report && vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
 av_bprintf(&buf, "q=%2.1f ", q);
 av_bprintf(&buf_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
 }
-if (!vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report || !is_last_report && !vid) {
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
 float fps;
 
 frame_number = ost->frame_number;
@@ -1750,14 +1767,16 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
ost->file_index, ost->index, p);
 }
 vid = 1;
-}
+}
+
 /* compute min output value */
 if (av_stream_get_end_pts(ost->st) != AV_NOPTS_VALUE)
 pts = FFMAX(pts, av_rescale_q(av_stream_get_end_pts(ost->st),
-  ost->st->time_base, AV_TIME_BASE_Q));
+  ost->st->time_base, AV_TIME_BASE_Q));
 if (is_last_report)
 nb_frames_drop += ost->last_dropped;
-}
+
+   

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Reino Wijnsma]

On 22-4-2018 14:47, Thomas Volkert  wrote:
> +enabled mbedtls   && { check_pkg_config mbedtls mbedtls 
> mbedtls/x509_crt.h mbedtls_x509_crt_init ||
> +   check_pkg_config mbedtls mbedtls 
> mbedtls/ssl.h mbedtls_ssl_init ||
> +   check_lib mbedtls mbedtls/ssl.h 
> mbedtls_ssl_init -lmbedtls ||
> +   die "ERROR: mbedTLS not found"; }
Now that James Almer has pushed this patch I decided to have a look as well. I 
wanted to see if mbedtls would work for me too.
I haven't made a FFmpeg build yet to test, because the excerpt above (in 
'configure') doesn't look right and configuring FFmpeg returns lots of 
undefined references.

First of all, there's no pkg-config file at all. Almost 3 years ago someone 
requested it (https://github.com/ARMmbed/mbedtls/issues/228), but as far as I 
can see it hasn't been implemented yet. So, I really don't understand why you 
added the 2 check_pkg_config lines.
Secondly, the check_lib line also needs -lmbedx509 and -lmbedcrypto!

-lmbedtls, the most important one obviously, prevents a "undefined reference to 
`mbedtls_ssl_init'", but...
-lmbedx509 is also needed, because otherwise you'd get "undefined reference to 
`mbedtls_x509_crt_init'" and several "undefined reference to 
`mbedtls_x509_crt_[...]'".
-lmbedcrypto is also needed, because otherwise you'd get LOTS of "undefined 
reference to `mbedtls_[...]'"; from "undefined reference to 
`mbedtls_sha256_init'" to "undefined reference to `mbedtls_pem_init'"!

The following patch works for me:

diff --git a/configure b/configure
index 09ff0c5..6014e03 100755
--- a/configure
+++ b/configure
@@ -6111,9 +6111,7 @@ enabled libzvbi   && require_pkg_config libzvbi 
zvbi-0.2 libzvbi.h vbi_d
  { test_cpp_condition libzvbi.h "VBI_VERSION_MAJOR 
> 0 || VBI_VERSION_MINOR > 2 || VBI_VERSION_MINOR == 2 && VBI_VERSION_MICRO >= 
28" ||
enabled gpl || die "ERROR: libzvbi requires 
version 0.2.28 or --enable-gpl."; }
 enabled libxml2   && require_pkg_config libxml2 libxml-2.0 
libxml2/libxml/xmlversion.h xmlCheckVersion
-enabled mbedtls   && { check_pkg_config mbedtls mbedtls 
mbedtls/x509_crt.h mbedtls_x509_crt_init ||
-   check_pkg_config mbedtls mbedtls mbedtls/ssl.h 
mbedtls_ssl_init ||
-   check_lib mbedtls mbedtls/ssl.h 
mbedtls_ssl_init -lmbedtls ||
+enabled mbedtls   && { check_lib mbedtls mbedtls/ssl.h 
mbedtls_ssl_init -lmbedtls -lmbedx509 -lmbedcrypto ||
die "ERROR: mbedTLS not found"; }
 enabled mediacodec&& { enabled jni || die "ERROR: mediacodec requires 
--enable-jni"; }
 enabled mmal  && { check_lib mmal interface/mmal/mmal.h 
mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host ||

Also note that the order is important, because with -lmbedtls -lmbedcrypto 
-lmbedx509 you'd get: "undefined reference to `mbedtls_pk_parse_subpubkey'" and 
"undefined reference to `mbedtls_pk_load_file'".

(If it matters, I'm cross-compiling on Windows using Cygwin, MinGW and GCC).

-- Reino

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

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: Use the colour properties from the input stream when doing transcode

[Michael Niedermayer]

On Mon, May 21, 2018 at 11:07:34PM +0100, Mark Thompson wrote:
> On 16/05/18 08:19, Haihao Xiang wrote:
> > In lavc/hevec_vaapi, colour properties in AVCodecContext are needed to
> > write the sequence header
> > 
> > Tested by the command below:
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
> > -hwaccel_output_format vaapi -i input-with-hdr.mkv -c:v hevc_vaapi
> > -profile:v main10 output.h265
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  fftools/ffmpeg.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 5a19a09d9a..80b5441f8f 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -3298,6 +3298,10 @@ static int init_output_stream_encode(OutputStream 
> > *ost)
> >  dec_ctx = ist->dec_ctx;
> >  
> >  enc_ctx->chroma_sample_location = dec_ctx->chroma_sample_location;
> > +enc_ctx->color_range= dec_ctx->color_range;
> > +enc_ctx->color_primaries= dec_ctx->color_primaries;
> > +enc_ctx->color_trc  = dec_ctx->color_trc;
> > +enc_ctx->colorspace = dec_ctx->colorspace;
> >  } else {
> >  for (j = 0; j < oc->nb_streams; j++) {
> >  AVStream *st = oc->streams[j];
> > 
> 
> There are outstanding patches passing color_range through the filter chain 
> (see ), 
> and that would be the right solution for the rest of these properties as 
> well, but it would require significantly more work.
> 
> I think hacking it like this is ok for now?  It's not worse than before since 
> a change during filtering wasn't visible anyway, and the manual options do 
> still work to override it.  I think the commit message could be a little 
> clearer about the problem (really, that this colour information doesn't pass 
> through filtering) and its limitations (requires a single input matched to 
> the output; will write the wrong thing if filtering changes anything) though, 
> or maybe that could be explained in a comment.
> 
> Does anyone else have any thoughts on this?  If there are no objections then 
> I would apply it updated with a clearer explanation.

I think the key question is
Does this change "Unknown" to incorrect values
if so it is IMHO not a good idea as we would create broken files where we did
previously just create files that lacked some metadata


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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH][ticket #5522] lavc/cfhd: interlaced frame decoding added

[Gagandeep Singh]

On Wed, 23 May 2018, 04:05 Carl Eugen Hoyos,  wrote:

> 2018-05-23 0:21 GMT+02:00, Hendrik Leppkes :
> > On Tue, May 22, 2018 at 10:35 PM, Carl Eugen Hoyos 
> > wrote:
> >> 2018-05-22 17:40 GMT+02:00, Gagandeep Singh  >:
> >>
> >>> +low= s->plane[plane].subband[0];
> >>> +high   = s->plane[plane].subband[8];
> >>> +output = s->plane[plane].l_h[6];
> >>> +for (i = 0; i < lowpass_width; i++) {
> >>> +vert_filter(output, lowpass_width, low, lowpass_width,
> >>> high, highpass_stride, lowpass_height);
> >>> +low++;
> >>> +high++;
> >>> +output++;
> >>> +}
> >>>
> >>> -low= s->plane[plane].subband[0];
> >>> -high   = s->plane[plane].subband[8];
> >>> -output = s->plane[plane].l_h[6];
> >>> -for (i = 0; i < lowpass_width; i++) {
> >>> -vert_filter(output, lowpass_width, low, lowpass_width,
> high,
> >>> highpass_stride, lowpass_height);
> >>> -low++;
> >>> -high++;
> >>> -output++;
> >>> -}
> >>
> >> The patch will get much more readable (and easier to review)
> >> if you do not re-indent, instead send a second patch with the
> >> cosmetic changes only.
> >>
> >
> > Except, no sane developer works like that.
>
> It's great to know that you are so much smarter than most developers,
> I will forward the next regression directly to you to fix it.
>
> Thank you, Carl Eugen
>

I will keep the cosmetic patch also in mind next time

Gagandeep Singh

> ___
> 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 v2 2/2] libavformat/mov: recognize udta name tag as the stream title

[Nik Johnson]

That's intended. I inspected the file with exiftool -v3 to check the 
tags and verify that's correct behavior.


  | | UserData (SubDirectory) -->
  | | - Tag 'udta' (12 bytes):
  | |   503e39: 00 00 00 0c 6e 61 6d 65 4d 6f 6e 6f 
[nameMono]

  | | + [UserData directory]
  | | | Track2Name = Mono
  | | | - Tag 'Track2name' (4 bytes):
  | | |   503e41: 4d 6f 6e 6f [Mono]

I'm also working on putting together a fate test and generate a tiny 
sample to include with this per your ask.


-- Original Message --
From: "Michael Niedermayer" 
To: "FFmpeg development discussions and patches" 


Sent: 5/22/2018 11:28:29 AM
Subject: Re: [FFmpeg-devel] [PATCH v2 2/2] libavformat/mov: recognize 
udta name tag as the stream title



On Mon, May 21, 2018 at 12:14:03PM -0700, Nik Johnson wrote:

Some muxers write the stream title in a udta atom with the tag 'name'.
Recognize 'name' tags as the stream title instead of an unknown tag.

Signed-off-by: Nik Johnson 
---
[v2: Add raw = 1]

libavformat/mov.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5332d48eb1..09e3096a06 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -340,6 +340,7 @@ static int mov_read_udta_string(MOVContext *c, 
AVIOContext *pb, MOVAtom atom)

return mov_metadata_loci(c, pb, atom.size);
case MKTAG( 'm','a','n','u'): key = "make"; break;
case MKTAG( 'm','o','d','l'): key = "model"; break;
+ case MKTAG( 'n','a','m','e'): key = "title"; raw = 1; break;
case MKTAG( 'p','c','s','t'): key = "podcast";
parse = mov_metadata_int8_no_padding; break;
case MKTAG( 'p','g','a','p'): key = "gapless_playback";


for
./ffmpeg -i ~/tickets/4938/2014-11-30\ 23.59.04-hb.mp4
file should be linked at https://trac.ffmpeg.org/ticket/4938

this produces:

title : Mono

is this intended ?


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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus

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

Re: [FFmpeg-devel] [PATCH v4 4/8] lavfi: add common Vulkan filtering code

[James Almer]

On 5/22/2018 1:28 AM, Rostislav Pehlivanov wrote:
> This commit adds a common code for use in Vulkan filters. It attempts
> to ease the burden of writing Vulkan image filtering to a minimum,
> which is pretty much a requirement considering how verbose the API is.
> 
> It supports both compute and graphic pipelines and manages to abstract
> the API to such a level there's no need to call any Vulkan functions
> inside the init path of the code. Handling shader descriptors is probably
> the bulk of the code, and despite the abstraction, it loses none of the
> features for describing shader IO.
> 
> In order to produce linkable shaders, it depends on the libshaderc
> library (and depends on the latest stable version of it). This allows
> for greater performance and flexibility than static built-in shaders
> and also eliminates the cumbersome process of interfacing with glslang
> to compile GLSL to SPIR-V.
> 
> It's based off of the common opencl and provides similar interfaces for
> filter pad init and config, with the addition that it also supports
> in-place filtering.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  configure|   12 +-
>  libavfilter/vulkan.c | 1190 ++
>  libavfilter/vulkan.h |  223 
>  3 files changed, 1423 insertions(+), 2 deletions(-)
>  create mode 100644 libavfilter/vulkan.c
>  create mode 100644 libavfilter/vulkan.h
> 
> diff --git a/configure b/configure
> index 5f4407b753..abcfe32625 100755
> --- a/configure
> +++ b/configure
> @@ -252,6 +252,7 @@ External library support:
>--enable-librsvg enable SVG rasterization via librsvg [no]
>--enable-librubberband   enable rubberband needed for rubberband filter 
> [no]
>--enable-librtmp enable RTMP[E] support via librtmp [no]
> +  --enable-libshaderc  enable GLSL->SPIRV compilation via libshaderc [no]
>--enable-libshineenable fixed-point MP3 encoding via libshine [no]
>--enable-libsmbclientenable Samba protocol via libsmbclient [no]
>--enable-libsnappy   enable Snappy compression, needed for hap 
> encoding [no]
> @@ -1707,6 +1708,7 @@ EXTERNAL_LIBRARY_LIST="
>  libpulse
>  librsvg
>  librtmp
> +libshaderc
>  libshine
>  libsmbclient
>  libsnappy
> @@ -2225,6 +2227,7 @@ HAVE_LIST="
>  opencl_dxva2
>  opencl_vaapi_beignet
>  opencl_vaapi_intel_media
> +shaderc_opt_perf
>  vulkan_drm_mod
>  perl
>  pod2man
> @@ -3456,12 +3459,12 @@ avcodec_select="null_bsf"
>  avdevice_deps="avformat avcodec avutil"
>  avdevice_suggest="libm"
>  avfilter_deps="avutil"
> -avfilter_suggest="libm"
> +avfilter_suggest="libm libshaderc"

If libavfiler/vulkan.c (which i assume uses libshaderc methods) is only
going to be built if one or more of the filters is also built, then this
is unnecessary. The libshaderc dep on each filter is enough.

>  avformat_deps="avcodec avutil"
>  avformat_suggest="libm network zlib"
>  avresample_deps="avutil"
>  avresample_suggest="libm"
> -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 
> vaapi videotoolbox corefoundation corevideo coremedia bcrypt"
> +avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl vulkan 
> user32 vaapi videotoolbox corefoundation corevideo coremedia bcrypt"

This one belongs in patch 3/8, otherwise hwcontext_vulkan will fail to link.

>  postproc_deps="avutil gpl"
>  postproc_suggest="libm"
>  swresample_deps="avutil"
> @@ -6050,6 +6053,7 @@ enabled libpulse  && require_pkg_config 
> libpulse libpulse pulse/pulseaud
>  enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
> librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
>  enabled librtmp   && require_pkg_config librtmp librtmp 
> librtmp/rtmp.h RTMP_Socket
>  enabled librubberband && require_pkg_config librubberband "rubberband >= 
> 1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
> librubberband_extralibs "-lstdc++"
> +enabled libshaderc&& require libshaderc shaderc/shaderc.h 
> shaderc_compiler_initialize -lshaderc_shared
>  enabled libshine  && require_pkg_config libshine shine 
> shine/layer3.h shine_encode_buffer
>  enabled libsmbclient  && { check_pkg_config libsmbclient smbclient 
> libsmbclient.h smbc_init ||
> require libsmbclient libsmbclient.h smbc_init 
> -lsmbclient; }
> @@ -6355,6 +6359,10 @@ enabled crystalhd && check_lib crystalhd "stdint.h 
> libcrystalhd/libcrystalhd_if.
>  enabled vulkan &&
>  require_pkg_config vulkan "vulkan >= 1.1.73" "vulkan/vulkan.h" 
> vkCreateInstance
>  
> +if enabled_all vulkan libshaderc ; then
> +check_cc shaderc_opt_perf shaderc/shaderc.h "int t = 
> shaderc_optimization_level_performance"
> +fi
> +
>  if enabled_all vulkan libdrm ; then
>  check_cpp_condition vulkan_drm_mod vulkan/vulkan.h "defined 
> VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME"
>  fi

Should be good oth

Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Niklas Haas
> Sent: Tuesday, May 22, 2018 8:54 PM
> To: Song, Ruiling 
> Cc: Mark Thompson ; FFmpeg development discussions and
> patches 
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
> 
> On Tue, 22 May 2018 08:56:37 +, "Song, Ruiling" 
> wrote:
> > Yes, your idea sounds reasonable. But it may need much effort to 
> > re-structure
> the code to make it (that would launch two kernels, and we may need a wait
> between them) and evaluate the performance.
> 
> Actually, a brute force solution to solve the missing peak problem would
> be to filter the first frame twice and discard the first result. (After
> that, you only need to filter each frame once, so the overall
> performance characteristic is unchanged for videos)
> 
> That requires minimal code change, and it still allows it to work for
> single-frame video sources. It also prevents an initial flash of the
> wrong brightness level for transcoded videos.
For the single frame video, do you mean still image?
I am not sure whether current OpenCL acceleration well designed for that?
My feeling is that people mainly use OpenCL for video acceleration,
esp. interop with hardware-accelerated codecs. Welcome to correct me on this.

For the very first frame, I think it is not easy to notice a flash.
Because a default peak value was used for the first frame which is 100 for PQ,
we would just get the first frame a little dimmer.

> 
> Also, performnace wise, I'm not sure how this works in OpenCL land, but
> in OpenGL/Vulkan, you'd just need to emit a pipeline barrier. That
> allows the kernels to synchronize without having to stall the pipeline
> by doing a CPU wait. (And, in general, you'd need a pipeline barrier
> even if you *are* running glFinish() afterwards - the pipeline barrier
> isn't just for timing, it's also for flushing the appropriate caches. In
> general, write visibility on storage buffers requires a pipeline
> barrier. Are you sure this is not the case for OpenCL as well?)
I think it again, the two OpenCL kernel launch needs no wait. It is just two 
kernel launched from host.
The performance I said is we need to read the image twice, which is obviously 
not as efficient as read once.
> 
> > Although we are developing offline filter, I think that performance is 
> > still very
> important as well as quality.
> > Given that the current implementation does well for video transcoding. I
> would leave it in my TODO list. Sounds ok?
> 
> ACK. It's not my decision, I'm just offering advice.
> 
> > Are you talking about display-referred HLG? I didn't update frame side 
> > channel
> data.
> > I am not sure when do I need to update it. I thought all HLG should be 
> > scene-
> referred, seems not?
> > Could you tell me more about display-referred HLG?
> 
> There's no such thing as "display-referred HLG". HLG by definition is
> encoded as scene-referred, but the OOTF to convert from scene-referred
> to display-referred is part of the EOTF (also by definition).
> 
> So the HLG EOTF inputs scene-referred and outputs display-referred. When
> you apply the EOTF (including the OOTF) as part of your processing
> chain, you're turning it into a linear light display referred signal.
> The tone mapping then happens on this signal (in display light), and
> then to turn it back to HLG after you're done tone-mapping you apply the
> inverse OOTF + OETF, thus turning it back into scene referred light.
> 
> The HLG OOTF (and therefore the EOTF) is parametrized by the display
> peak. Even though the HLG signal is stored in the range 0.0 - 12.0
> (scene referred), the output range depends on how you tuned the EOTF. If
> you tuned it for the 1000 cd/m^2 reference display, then an input of
> 12.0 will get turned into an output value of 1000 cd/m^2.
> 
> If we then tone-map this to a brightness of 500 cd/m^2, and pass it back
> through the same OOTF, it would get turned into 6.0 rather than the
> 12.0. While this may ultimately reproduce the correct result on-screen
> (assuming the end user of the video file also uses a peak of 1000 cd/m^2
> to decode the file), it's a suboptimal use of the encoding range and
> also not how HLG is designed to operate. (For example, it would affect
> the "SDR backwards compatibility" property of HLG, which is the whole
> reason for the peak-dependent encoding)
> 
> That's why the correct thing to do would be to re-encode the file using
> an inverse OOTF tuned for 500 cd/m², thus taking our tone mapped value
> in question back to the (scene-referred) value of 12.0, and update the
> tagged peak to also read 500 cd/m². Now a spec-conforming implementation
> of a video player (e.g. mpv or VLC) that plays this file would use the
> same tuned EOTF to decode it back to the value of 500 cd/m², thus
> ensuring it round trips correctly.
> 
> > I don't find anything about it. What metadata in HEVC indicate 
> > display-