Re: [FFmpeg-devel] [PATCH] avfilter/extractplanes: add support for 12-bit YUVA formats

[Carl Eugen Hoyos]

2019-01-17 10:47 GMT+01:00, Gyan :
> Fixes alpha extraction for sample at
>
> https://08488297638989341201.googlegroups.com/attach/85d30cd6b8095/Circle%20Ink%20Bleed_10.mov
>
> as seen in
>
>  ffplay -i in -vf alphaextract

> At present, 16-bit auto-scaled format results in incorrect alpha
> extraction.

Does that mean that there is an unreported bug in the colour
space conversion?

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

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

[Carl Eugen Hoyos]

2019-01-18 15:24 GMT+01:00, Derek Buitenhuis :

> To that end, I've opened a bug with oss-fuzz for some guidance:
>
> https://github.com/google/oss-fuzz/issues/2095

You are late to this party...

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

Re: [FFmpeg-devel] [PATCH] avfilter/extractplanes: add support for 12-bit YUVA formats

[Gyan]

On 19-01-2019 06:21 PM, Carl Eugen Hoyos wrote:



At present, 16-bit auto-scaled format results in incorrect alpha
extraction.

Does that mean that there is an unreported bug in the colour
space conversion?
Forcing a manual conversion to the same output format as the auto-scaler 
avoids the error, so looks like a config error rather than the 
conversion itself


I don't have time to trace it at present. Only wanted to get the 
immediate use-case fixed.


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

[FFmpeg-devel] [PATCH] avformat/hcom: Fix "set but not used" warnings

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/hcom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hcom.c b/libavformat/hcom.c
index 35515cc5b2..6d3d726fa5 100644
--- a/libavformat/hcom.c
+++ b/libavformat/hcom.c
@@ -38,7 +38,7 @@ static int hcom_probe(AVProbeData *p)
 static int hcom_read_header(AVFormatContext *s)
 {
 AVStream *st;
-unsigned data_size, rsrc_size, huffcount;
+av_unused unsigned data_size, rsrc_size, huffcount;
 unsigned compresstype, divisor;
 unsigned dict_entries;
 int ret;
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH] avformat/hcom: Fix "set but not used" warnings

[James Almer]

On 1/19/2019 3:50 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/hcom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hcom.c b/libavformat/hcom.c
> index 35515cc5b2..6d3d726fa5 100644
> --- a/libavformat/hcom.c
> +++ b/libavformat/hcom.c
> @@ -38,7 +38,7 @@ static int hcom_probe(AVProbeData *p)
>  static int hcom_read_header(AVFormatContext *s)
>  {
>  AVStream *st;
> -unsigned data_size, rsrc_size, huffcount;
> +av_unused unsigned data_size, rsrc_size, huffcount;
>  unsigned compresstype, divisor;
>  unsigned dict_entries;
>  int ret;

No, they should be removed and the relevant avio_rb32() replaced with
avio_skip() alongside a comment to document what those bytes represent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hcom: Fix "set but not used" warnings

[Michael Niedermayer]

On Sat, Jan 19, 2019 at 03:53:55PM -0300, James Almer wrote:
> On 1/19/2019 3:50 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/hcom.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/hcom.c b/libavformat/hcom.c
> > index 35515cc5b2..6d3d726fa5 100644
> > --- a/libavformat/hcom.c
> > +++ b/libavformat/hcom.c
> > @@ -38,7 +38,7 @@ static int hcom_probe(AVProbeData *p)
> >  static int hcom_read_header(AVFormatContext *s)
> >  {
> >  AVStream *st;
> > -unsigned data_size, rsrc_size, huffcount;
> > +av_unused unsigned data_size, rsrc_size, huffcount;
> >  unsigned compresstype, divisor;
> >  unsigned dict_entries;
> >  int ret;
> 
> No, they should be removed and the relevant avio_rb32() replaced with
> avio_skip() alongside a comment to document what those bytes represent.

I thought there might be some future code or checks that will use these
but if thats not the case then sure i can remove them

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

Re: [FFmpeg-devel] [PATCH] avformat/hcom: Fix "set but not used" warnings

[James Almer]

On 1/19/2019 4:08 PM, Michael Niedermayer wrote:
> On Sat, Jan 19, 2019 at 03:53:55PM -0300, James Almer wrote:
>> On 1/19/2019 3:50 PM, Michael Niedermayer wrote:
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavformat/hcom.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/hcom.c b/libavformat/hcom.c
>>> index 35515cc5b2..6d3d726fa5 100644
>>> --- a/libavformat/hcom.c
>>> +++ b/libavformat/hcom.c
>>> @@ -38,7 +38,7 @@ static int hcom_probe(AVProbeData *p)
>>>  static int hcom_read_header(AVFormatContext *s)
>>>  {
>>>  AVStream *st;
>>> -unsigned data_size, rsrc_size, huffcount;
>>> +av_unused unsigned data_size, rsrc_size, huffcount;
>>>  unsigned compresstype, divisor;
>>>  unsigned dict_entries;
>>>  int ret;
>>
>> No, they should be removed and the relevant avio_rb32() replaced with
>> avio_skip() alongside a comment to document what those bytes represent.
> 
> I thought there might be some future code or checks that will use these
> but if thats not the case then sure i can remove them
> 
> thx

data_size could i guess be used to set stream duration, but i doubt this
demuxer will get much more development than what's already done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] flush segments to guarantuee atomic single file hls

[Moritz Barsnick]

> Subject: flush segments to guarantuee atomic single file hls
 ^ nit no. 1: guarantee

Nit no. 2: Please use a commit line something like:

avformat/hlsenc: flush segments to guarantee atomic single file hls

(I'm not sure I agree with the wording, but I'm no HLS expert.)

Does this fix some known bug worth mentioning?

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

Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

[Moritz Barsnick]

On Wed, Jan 16, 2019 at 11:54:42 -0800, Mohammad Izadi wrote:

> Subject: Support HDR dynamic metdata (HDR10+) in HEVC decoder.
   ^ Nit no. 1: metadata

Nit no. 2: Preferred format:
avcodec/hevcdec: add support for HDR dynamic metadata (HDR10+)

> +if (((rows < 2) && (rows > 25)) || ((cols < 2) && (cols > 25))) {

Have you confused something? How can rows be smaller than 2 and larger
than 25 at the same time?

This should probably be
if ((rows < 2) || (rows > 25) || (cols < 2) || (cols > 25)) {

> +av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they 
> must [2, 25] for targeted_system_display_actual_peak_luminance\n", rows, 
> cols);

> +if (((rows < 2) && (rows > 25)) || ((cols < 2) && (cols > 25))) {
> +av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they 
> must be in [2, 25] for mastering_display_actual_peak_luminance\n", rows, 
> cols);

Same here. And the wording is slightly different, "be in" is missing in
the first one.

> +typedef struct HEVCSEIDynamicHDRPlus{
 " {"

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

Re: [FFmpeg-devel] [PATCH]lavu/frame: Try to improve the documentation wording

[Michael Niedermayer]

On Fri, Jan 18, 2019 at 12:38:20PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch tries to improve the ROI documentation wording, C
> structs cannot return errors.
> 
> Please comment, Carl Eugen

>  frame.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 888a2470d43113b08b0ef3ddd03bda528f873ccc  
> 0001-lavu-frame-Try-to-improve-the-documentation-wording.patch
> From 4abd545e7ab463c97bf816b270544eee25c4755b Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Fri, 18 Jan 2019 12:35:44 +0100
> Subject: [PATCH] lavu/frame: Try to improve the documentation wording.
> 
> C structs cannot return errors.
> ---
>  libavutil/frame.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 8aa3e88..1990320 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -218,8 +218,8 @@ typedef struct AVFrameSideData {
>   * if the codec requires an alignment.
>   * If the regions overlap, the last value in the list will be used.
>   *
> - * qoffset is quant offset, and base rule here:
> - * returns EINVAL if AVRational.den is zero.
> + * qoffset is quantization offset:
> + * Encoders will return EINVAL if qoffset.den is zero.
>   * the value (num/den) range is [-1.0, 1.0], clamp to +-1.0 if out of range.
>   * 0 means no picture quality change,
>   * negative offset asks for better quality (and the best with value -1.0),

The field specific documentation should be added to each of the fields using
correct doxygen syntax.

About EINVAL, i would tend to document what is valid and what is not
instead of documenting  what some code will do with invalid values.
The user has no reason to ever use invalid values so that information
should have no value. And just has some chance to be incorrect now or later

Also the wording of the unchanged parts sound funky, some native english
speaker should check and reword more of this i think.

thanks

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCHv2 4/4] avformat/concatdec: always re-calculate start time and duration

[Marton Balint]

On Fri, 4 Jan 2019, Marton Balint wrote:




On Fri, 4 Jan 2019, Nicolas George wrote:


Marton Balint (12018-12-30):

This allows the underlying files to change their duration on subsequent
avformat context opens.

An example use case where this matters:

ffconcat version 1.0
file dummy.mxf
file dummy.mxf

ffmpeg -re -stream_loop -1 -i dummy.ffconcat -f sdl2 none

The user can seamlessly change the input by atomically replacing 

dummy.mxf.


v2: Set ConcatFile duration in read_header for all segments with known
durations because from now on we always recalculate the start time in
open_file, and an instant seek could have caused unset ConcatFile 

durations.


Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)


I am sorry, but it still feels like a fragile solution, and I think it
can leave the context in an inconsistent state. Maybe it works now, but
it is a bad surprise left for somebody who wants to extend this demuxer
in another way later.

Also, I think the duration detected from the file should never override
the duration provided by the script.


Agreed, and this is how it should work even after the patch. user_duration 
which is the duration specified in the ffconcat file always have priority 
because get_best_effort_duration always considers that first. So it does 
not matter that we assign ConcatFile->duration again and again, because we 
will just reassing the same value.


Given that, I don't think an inconsitent state is possible because seeking 
is only allowed if the durations are known (if they are all set in 
the ffconcat file). On the other hand, if generic seeking is not allowed, 
then start_time will never be invalid because we always recalculate it for 
the next file when we open it.


Does this relax your concern?



Ping.

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

Re: [FFmpeg-devel] [PATCH 1/4] zmbvenc: don't sum the entropy when blocks are equal

[Matthew Fearnley]

On Tue, 25 Dec 2018 at 09:35, Tomas Härdin  wrote:

> lör 2018-12-22 klockan 15:32 + skrev Matthew Fearnley:
> > > > >
> > > > Note that bw,bh aren't guaranteed to equal ZMBV_BLOCK, so
> `histogram[0] ==
> > > > bw*bh` would have to be used to guard against those (literal) edge
> cases.
> > >
> > > Right, yes. But if we have block sizes other than ZMBV_BLOCK^2 then we
> > > need score tables for those sizes too.
> >
> > I’ve thought about that a bit. I wondered if it would be worth it given:
> > - the extra code, memory and logic needed
>
> If you have a huge amount of DOS captures to optimize then it might be
> worth it, else probably questionable
>
> > - it would only improve the edge blocks
>
> I imagine large blocks would be good for scenes with mostly global
> motion. You cut down on the number of MVs and thus the amount of data
> zlib has to compress, if the block size is a good fit.
>
> > - the existing score table isn’t catastrophically bad for short blocks,
> and would still favour blocks with more common pixels.
> >
> > It would be better from a correctness perspective though, and effects on
> running time should be negligible.
>
> Good point. There's also no telling whether the current model is
> actually an accurate prediction of how zlib behaves :)
>
>
Hi.  Just to say, I tried setting up additional score_tabs for the
bottom/right partial blocks.  Unfortunately, after implementing it and
ironing out the bugs, the new score tables actually caused a slight
increase in file size!
After a little informal investigation with a couple of videos, my findings
were that increasing the divisor - '(i / (double)(ZMBV_BLOCK * ZMBV_BLOCK *
some_factor))' - would generally lead to slight compression improvements.
Given the score table is still "valid" for smaller blocks, and given the
extra complexity of adding the score tables, plus the fact that it may
generally hurt the compression, I'm inclined to leave it with the one score
table.  But there may be potential to improve the current compression
method in future, by somehow tuning the divisor for better results
generally.

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

[FFmpeg-devel] [PATCH] avcodec/motion_est: remove duplicate function

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavcodec/motion_est.c  |  4 +--
 libavcodec/motion_est_template.c | 62 +---
 2 files changed, 3 insertions(+), 63 deletions(-)

diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
index 8b5ce2117a..759eea479d 100644
--- a/libavcodec/motion_est.c
+++ b/libavcodec/motion_est.c
@@ -633,7 +633,7 @@ static inline int h263_mv4_search(MpegEncContext *s, int 
mx, int my, int shift)
 if(P[i][1] > (c->ymax>shift);
+dmin4 = epzs_motion_search2(s, &mx4, &my4, P, block, block, 
s->p_mv_table, (1<<16)>>shift, 1);
 
 dmin4= c->sub_motion_search(s, &mx4, &my4, dmin4, block, block, size, 
h);
 
@@ -795,7 +795,7 @@ static int interlaced_search(MpegEncContext *s, int 
ref_index,
 P_MV1[0]= mx; //FIXME not correct if block != field_select
 P_MV1[1]= my / 2;
 
-dmin = epzs_motion_search2(s, &mx_i, &my_i, P, block, 
field_select+ref_index, mv_table, (1<<16)>>1);
+dmin = epzs_motion_search2(s, &mx_i, &my_i, P, block, 
field_select+ref_index, mv_table, (1<<16)>>1, 0);
 
 dmin= c->sub_motion_search(s, &mx_i, &my_i, dmin, block, 
field_select+ref_index, size, h);
 
diff --git a/libavcodec/motion_est_template.c b/libavcodec/motion_est_template.c
index 0c21bbfe1a..014038e54f 100644
--- a/libavcodec/motion_est_template.c
+++ b/libavcodec/motion_est_template.c
@@ -989,76 +989,16 @@ int ff_epzs_motion_search(MpegEncContext *s, int *mx_ptr, 
int *my_ptr,
 }
 }
 
-static int epzs_motion_search4(MpegEncContext * s,
- int *mx_ptr, int *my_ptr, int P[10][2],
- int src_index, int ref_index, int16_t 
(*last_mv)[2],
- int ref_mv_scale)
-{
-MotionEstContext * const c= &s->me;
-int best[2]={0, 0};
-int d, dmin;
-unsigned map_generation;
-const int penalty_factor= c->penalty_factor;
-const int size=1;
-const int h=8;
-const int ref_mv_stride= s->mb_stride;
-const int ref_mv_xy= s->mb_x + s->mb_y *ref_mv_stride;
-me_cmp_func cmpf, chroma_cmpf;
-LOAD_COMMON
-int flags= c->flags;
-LOAD_COMMON2
-
-cmpf= s->mecc.me_cmp[size];
-chroma_cmpf = s->mecc.me_cmp[size + 1];
-
-map_generation= update_map_generation(c);
-
-dmin = 100;
-
-/* first line */
-if (s->first_slice_line) {
-CHECK_MV(P_LEFT[0]>>shift, P_LEFT[1]>>shift)
-CHECK_CLIPPED_MV((last_mv[ref_mv_xy][0]*ref_mv_scale + (1<<15))>>16,
-(last_mv[ref_mv_xy][1]*ref_mv_scale + (1<<15))>>16)
-CHECK_MV(P_MV1[0]>>shift, P_MV1[1]>>shift)
-}else{
-CHECK_MV(P_MV1[0]>>shift, P_MV1[1]>>shift)
-//FIXME try some early stop
-CHECK_MV(P_MEDIAN[0]>>shift, P_MEDIAN[1]>>shift)
-CHECK_MV(P_LEFT[0]>>shift, P_LEFT[1]>>shift)
-CHECK_MV(P_TOP[0]>>shift, P_TOP[1]>>shift)
-CHECK_MV(P_TOPRIGHT[0]>>shift, P_TOPRIGHT[1]>>shift)
-CHECK_CLIPPED_MV((last_mv[ref_mv_xy][0]*ref_mv_scale + (1<<15))>>16,
-(last_mv[ref_mv_xy][1]*ref_mv_scale + (1<<15))>>16)
-}
-if(dmin>64*4){
-CHECK_CLIPPED_MV((last_mv[ref_mv_xy+1][0]*ref_mv_scale + (1<<15))>>16,
-(last_mv[ref_mv_xy+1][1]*ref_mv_scale + (1<<15))>>16)
-if(s->mb_y+1end_mb_y)  //FIXME replace at least with 
last_slice_line
-CHECK_CLIPPED_MV((last_mv[ref_mv_xy+ref_mv_stride][0]*ref_mv_scale 
+ (1<<15))>>16,
-(last_mv[ref_mv_xy+ref_mv_stride][1]*ref_mv_scale 
+ (1<<15))>>16)
-}
-
-dmin= diamond_search(s, best, dmin, src_index, ref_index, penalty_factor, 
size, h, flags);
-
-*mx_ptr= best[0];
-*my_ptr= best[1];
-
-return dmin;
-}
-
-//try to merge with above FIXME (needs PSNR test)
 static int epzs_motion_search2(MpegEncContext * s,
  int *mx_ptr, int *my_ptr, int P[10][2],
  int src_index, int ref_index, int16_t 
(*last_mv)[2],
- int ref_mv_scale)
+ int ref_mv_scale, const int size)
 {
 MotionEstContext * const c= &s->me;
 int best[2]={0, 0};
 int d, dmin;
 unsigned map_generation;
 const int penalty_factor= c->penalty_factor;
-const int size=0; //FIXME pass as arg
 const int h=8;
 const int ref_mv_stride= s->mb_stride;
 const int ref_mv_xy= s->mb_x + s->mb_y *ref_mv_stride;
-- 
2.16.4

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

Re: [FFmpeg-devel] [PATCH] avformat/hcom: Fix "set but not used" warnings

[Michael Niedermayer]

On Sat, Jan 19, 2019 at 04:11:07PM -0300, James Almer wrote:
> On 1/19/2019 4:08 PM, Michael Niedermayer wrote:
> > On Sat, Jan 19, 2019 at 03:53:55PM -0300, James Almer wrote:
> >> On 1/19/2019 3:50 PM, Michael Niedermayer wrote:
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavformat/hcom.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavformat/hcom.c b/libavformat/hcom.c
> >>> index 35515cc5b2..6d3d726fa5 100644
> >>> --- a/libavformat/hcom.c
> >>> +++ b/libavformat/hcom.c
> >>> @@ -38,7 +38,7 @@ static int hcom_probe(AVProbeData *p)
> >>>  static int hcom_read_header(AVFormatContext *s)
> >>>  {
> >>>  AVStream *st;
> >>> -unsigned data_size, rsrc_size, huffcount;
> >>> +av_unused unsigned data_size, rsrc_size, huffcount;
> >>>  unsigned compresstype, divisor;
> >>>  unsigned dict_entries;
> >>>  int ret;
> >>
> >> No, they should be removed and the relevant avio_rb32() replaced with
> >> avio_skip() alongside a comment to document what those bytes represent.
> > 
> > I thought there might be some future code or checks that will use these
> > but if thats not the case then sure i can remove them
> > 
> > thx
> 
> data_size could i guess be used to set stream duration, 

where can i find hcom samples ?
do you have some URLs ? 
(for testing such use of the field)


> but i doubt this
> demuxer will get much more development than what's already done.

maybe


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add HCOM decoder

[Michael Niedermayer]

On Wed, Jan 02, 2019 at 06:12:08PM -0300, James Almer wrote:
> On 1/2/2019 3:53 PM, Paul B Mahol wrote:
> > +static int hcom_decode(AVCodecContext *avctx, void *data,
> > +   int *got_frame, AVPacket *pkt)
> > +{
> > +HCOMContext *s = avctx->priv_data;
> > +AVFrame *frame = data;
> > +GetByteContext gb;
> > +uint32_t current;
> > +int ret, n = 0;
> > +
> > +if (pkt->size > INT16_MAX)
> > +return AVERROR_INVALIDDATA;
> > +
> > +frame->nb_samples = pkt->size * 8;
> > +if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
> > +return ret;
> > +
> > +bytestream2_init(&gb, pkt->data, pkt->size);
> > +while (bytestream2_get_bytes_left(&gb) >= 4) {
> > +int bits = 32;
> > +
> > +current = bytestream2_get_be32(&gb);
> > +
> > +while (bits-- > 0) {
> > +
> > +if (current & 0x8000) {
> > +s->dict_entry = s->dict[s->dict_entry].r;
> > +} else {
> > +s->dict_entry = s->dict[s->dict_entry].l;
> > +}
> > +
> > +current = current << 1;
> 
> This sounds like get_bits is a better fit than bytestream2 for this decoder.

this looks like a standard vlc/huffman reader
and could be using the existing vlc code (init_vlc / get_vlc2 / ...)

thanks

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] avcodec/motion_est: remove duplicate function

[Michael Niedermayer]

On Sat, Jan 19, 2019 at 11:48:39PM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/motion_est.c  |  4 +--
>  libavcodec/motion_est_template.c | 62 
> +---
>  2 files changed, 3 insertions(+), 63 deletions(-)

please check if the compiler optimizes the size constant out after this
change

thanks

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 5/5] lavf/tls: enable server verification by default when not on mbedtls

[Michael Niedermayer]

On Fri, Jan 18, 2019 at 02:50:29PM -0600, Rodger Combs wrote:
> 
> 
> > On Jan 18, 2019, at 05:41, Carl Eugen Hoyos  wrote:
> > 
> > 2019-01-18 9:46 GMT+01:00, Rodger Combs :
> >> All other TLS wrappers now have a mechanism to load a system trust store
> >> by default, without setting the cafile option. For Secure Transport and
> >> Secure Channel, it's the OS. For OpenSSL and libtls, it's a path set at
> >> compile-time. For GNUTLS, it's either a path set at compile-time, or the
> >> OS trust store (if on macOS, iOS, or Windows). It's possible to configure
> >> OpenSSL, GNUTLS, and libtls without a working trust store, but these are
> >> broken configurations and I don't have a problem with requiring users with
> >> that kind of install to either fix it, or explicitly opt in to insecure
> >> behavior. mbedtls doesn't have a default trust store (it's assumed that the
> >> application will provide one), so it continues to require the user to pass
> >> in a path and enable verification manually.
> > 
> > I believe the current behaviour is more desirable as default for a 
> > multimedia
> > library.
> 
> That's patent nonsense. Requests for media are as likely to contain 
> authentication tokens as anything else today, and users have as much of a 
> right to privacy in the specific media they consume as in anything else they 
> use online. Without any verification of peer certificates, our current 
> defaults are little better than using plaintext.

Iam in favor of security by default too.
But there may be issues iam unaware of of course ...

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize put_hevc_pel_bi_pixels_8 with mmi.

[Michael Niedermayer]

On Fri, Jan 18, 2019 at 02:42:20PM +0800, Shiyou Yin wrote:
> Optimize put_hevc_pel_bi_pixels_8 with mmi in the case width=8/16/24/32/48/64.
> This optimization improved HEVC decoding performance 2%(1.77x to 1.81x, 
> tested on loongson 3A3000).
> ---
>  libavcodec/mips/Makefile|   1 +
>  libavcodec/mips/hevcdsp_init_mips.c |  23 ++
>  libavcodec/mips/hevcdsp_mips.h  |  19 +
>  libavcodec/mips/hevcdsp_mmi.c   | 135 
> 
>  4 files changed, 178 insertions(+)
>  create mode 100644 libavcodec/mips/hevcdsp_mmi.c

will apply

thanks

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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/hcom: Fix "set but not used" warnings

[James Almer]

On 1/19/2019 7:54 PM, Michael Niedermayer wrote:
> On Sat, Jan 19, 2019 at 04:11:07PM -0300, James Almer wrote:
>> On 1/19/2019 4:08 PM, Michael Niedermayer wrote:
>>> On Sat, Jan 19, 2019 at 03:53:55PM -0300, James Almer wrote:
 On 1/19/2019 3:50 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/hcom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hcom.c b/libavformat/hcom.c
> index 35515cc5b2..6d3d726fa5 100644
> --- a/libavformat/hcom.c
> +++ b/libavformat/hcom.c
> @@ -38,7 +38,7 @@ static int hcom_probe(AVProbeData *p)
>  static int hcom_read_header(AVFormatContext *s)
>  {
>  AVStream *st;
> -unsigned data_size, rsrc_size, huffcount;
> +av_unused unsigned data_size, rsrc_size, huffcount;
>  unsigned compresstype, divisor;
>  unsigned dict_entries;
>  int ret;

 No, they should be removed and the relevant avio_rb32() replaced with
 avio_skip() alongside a comment to document what those bytes represent.
>>>
>>> I thought there might be some future code or checks that will use these
>>> but if thats not the case then sure i can remove them
>>>
>>> thx
>>
>> data_size could i guess be used to set stream duration, 
> 
> where can i find hcom samples ?
> do you have some URLs ? 
> (for testing such use of the field)

Paul should know since he wrote both the decoder and demuxer. Also Compn
i think.

> 
> 
>> but i doubt this
>> demuxer will get much more development than what's already done.
> 
> maybe
> 
> 
> [...]
> 
> 
> ___
> 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