Re: [FFmpeg-devel] [PATCH V3] lavc/vaapi_encode_h264: Enable MB rate control.

[Mark Thompson]

On 19/05/17 00:43, Jun Zhao wrote:
> 
> On 2017/5/14 12:26, Jun Zhao wrote:
>> V3: - Fix build error with old VAAPI version.
>> V2: - Refine the name/value type to mb_rate_control/bool.
>> - Only supported GEN9+ (SKL/APL/KBL/...)
>> - i965 driver default use frame-level rate control algorithm (generate 
>> the QP for each frame), 
>>   when enable mb_rate_control, it's will enable the MB-level RC 
>> algorithm (generate the QP for each MB). 
>> - enables MB-level bitrate control that generally improves subjective 
>> visual quality, 
>>   but have negative impact on performance and objective visual quality 
>> metric. 
>>
> 
> Ping ?

I fixed the default/enable/disable inconsistency in 
.
  Using 0/1 as default/on is probably fine, but it doesn't match the statement 
that it's definitely disabled if the option is zero.  (I don't mind which way 
around that gets fixed.)

I tested with this patch and it works fine on a Skylake GT3 (6260U), but it 
killed the whole machine when enabled on a Skylake GT2 (6300).  I haven't yet 
had chance to investigate that further (rebooting repeatedly is kindof 
inconvenient), but I will try to do so soon.

What platforms have you tested on?

- Mark

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

Re: [FFmpeg-devel] [PATCH] avfilter/graphparser: allow specifying filter@id as filter instance

[Muhammad Faiz]

On Thu, May 18, 2017 at 11:48 PM, Paul B Mahol  wrote:
> On 5/18/17, Muhammad Faiz  wrote:
>> On Thu, May 18, 2017 at 11:11 PM, Paul B Mahol  wrote:
>>> On 5/17/17, Muhammad Faiz  wrote:
 See http://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-April/035975.html
 Parsed_filter_X is not intuitive as filter instance name and
 also undocumented.

 Signed-off-by: Muhammad Faiz 
 ---
  doc/filters.texi  | 13 ++---
  libavfilter/graphparser.c | 26 +-
  2 files changed, 31 insertions(+), 8 deletions(-)

>>>
>>> Could you add example in git log when you also linked that thread
>>> article.
>>
>> Added
>> Example:
>> ffplay -f lavfi "nullsrc=s=640x360,
>> sendcmd='1 drawtext@top reinit text=Hello; 2 drawtext@bottom reinit
>> text=World',
>> drawtext@top=x=16:y=16:fontsize=20:fontcolor=Red:text='',
>> drawtext@bottom=x=16:y=340:fontsize=16:fontcolor=Blue:text=''"
>>
>>>
>>> IMHO Parsed could remain and user can override it with custom one.
>>
>> Changed.
>>
>> Thank's
>
> No more comments from me.

Applied.

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

Re: [FFmpeg-devel] [PATCH] avfilter: Enable in MP4 container both AMR-NB and AMR-WB

[Bob Kirnum]

I tried adding support for MOV to see if I could use unpatched FFmpeg
libraries.  Although both AMR-NB and AMR-WB do appear to record to MOV,
neither result plays properly using QuickTime or Windows 'Movies & TV'
app.  The MOV (H.264 / AMR-NB) sometimes audio plays, sometimes video.
Appears that the MOV contains two moov atoms, one for audio one for video.
Similar is true for AMR-WB, however, there is never audio as QuickTime and
Windows app do not support AMR-WB.

I also tried both MP4 and MOV using linear PCM (s16le @ 16 kHz).  MP4
rejects the codec, MOV seems to have a similar issue as AMR, only video
plays.

I am using the exact same code as we use for MP4 so I am not sure what we
are doing wrong.  Any suggestions for how to debug this?

The recorded files are here . . .

https://drive.google.com/open?id=0B-TtYdUjPHBmM29uWkU4aHdReE0

big-buck-bunny_trailer.h264_s16le.mov
big-buck-bunny_trailer.h264_amrnb.mov
big-buck-bunny_trailer.h264_amrwb.mov

Thanks,
Bob

On Thu, May 18, 2017 at 8:34 AM, Bob Kirnum  wrote:

> Hey Carl,
>
> I am not aware of non-FFmpeg apps which can record to MP4 containing AMR.
> That's not to say one does not exist.
>
> I would agree that we likely need no changes for playing these MP4 files.
>
> The MP4 requirement was from one of our customers.
>
> Thanks,
> Bob
>
> On Wed, May 17, 2017 at 8:01 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2017-05-17 23:26 GMT+02:00 Bob Kirnum :
>> > Did not realize the files I shared were too large.  I copied them to a
>> > shared Google Drive here . . .
>>
>> The question was if you have files that were not created with FFmpeg.
>>
>> Anyway: Since both files can be decoded with unpatched FFmpeg, I
>> assume the demuxing hunk of your patch is unneeded, correct?
>>
>> Any reason why you cannot use mov for muxing?
>>
>> Carl Eugen
>> ___
>> 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

[FFmpeg-devel] [PATCH] Added the RTP Header Extension to AVPacket side data

[Anna Sokol]

Added a way to store the RFC 3550 Section 5.3.1 RTP Header Extension in
side data of AVPacket.
- In libavcodec/avcodec.h AVPacketSideDataType added
AV_PKT_DATA_RTP_HEADER_EXTENSION.
- In libavcodec/avpacket.c av_packet_side_data_name added a case for the
AV_PKT_DATA_RTP_HEADER_EXTENSION.
- In libavformat/rtpdec.c rtp_parse_packet_internal store the previously
skipped RTP Header Extension
 as side data in new packet.
The patch is attached.
Signed-off-by: Anna Sokol 


rtp_header_extension.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avio_read data loss with multiple calls to fill_buffer

[Michael Niedermayer]

hi

On Thu, May 18, 2017 at 10:58:39PM +, Rob Meyers wrote:
> avio_read does multiple calls to fill_buffer(). Adjusting things in
> fill_buffer was frowned upon; how would you suggest I approach this?

Its not frowned upon to fix a bug in fill_buffer(), its frowned
upon to make a random change that fixes a testcase without fixing
the underlaing bug. (there is a bug somewhere)


> The
> id3v2 seek doesn't come into play; the return from avio_read is the "full"
> read.

Just tried, if i comment
ff_id3v2_read_dict(s->pb, &s->internal->id3v2_meta, ID3v2_DEFAULT_MAGIC, 
&id3v2_extra_meta);
out from avformat_open_input()
your testcase works


> 
> The call I added in avio_read is only done when there was accumulated data,
> so avoid reallocating the buffer the first time through.

> 
> On Thu, May 18, 2017 at 3:53 PM Michael Niedermayer 
> wrote:
> 
> > On Thu, May 18, 2017 at 01:12:49PM -0700, Rob Meyers wrote:
> > > avio_read may make multiple calls to fill_buffer to accumulate bytes
> > > to fulfill a request. fill_buffer will overwrite previously read data
> > > if it is not prepped. Added a call to 'ffio_ensure_seekback' to adjust
> > > the s->buffer to fill_buffer's liking. This isn't necessary for the
> > > very first call to fill_buffer, thus the "size1 != size" check.
> > > ---
> > >  libavformat/aviobuf.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> > > index 0a7c39eacd..8e9594cab8 100644
> > > --- a/libavformat/aviobuf.c
> > > +++ b/libavformat/aviobuf.c
> > > @@ -648,6 +648,11 @@ int avio_read(AVIOContext *s, unsigned char *buf,
> > int size)
> > >  s->buf_end = s->buffer/* + len*/;
> > >  }
> > >  } else {
> > > +if (size1 != size)
> > > +/* this call will ensure fill_buffer will not
> > overwrite previously
> > > +read data. */
> > > +ffio_ensure_seekback(s, size1);
> >
> > ffio_ensure_seekback() should be called when theres a potential
> > seek back in the following code.
> >
> > There is no seekback in avio_read(), avio_read only moves forward.
> > Some callers may do a avio_read() and or other function calls and
> > then seek back. A caller might do 3 avio_read() and seek back over all
> >
> > ffio_ensure_seekback() generally should be called by the code that
> > later initiates teh seek back
> >
> > ffio_ensure_seekback() is not free it should only be used when it is
> > needed.
> >
> >
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Those who are too smart to engage in politics are punished by being
> > governed by those who are dumber. -- Plato
> > ___
> > 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

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

Re: [FFmpeg-devel] [PATCH] avio_read data loss with multiple calls to fill_buffer

[Michael Niedermayer]

On Fri, May 19, 2017 at 08:28:23PM +0200, Michael Niedermayer wrote:
> hi
> 
> On Thu, May 18, 2017 at 10:58:39PM +, Rob Meyers wrote:
> > avio_read does multiple calls to fill_buffer(). Adjusting things in
> > fill_buffer was frowned upon; how would you suggest I approach this?
> 
> Its not frowned upon to fix a bug in fill_buffer(), its frowned
> upon to make a random change that fixes a testcase without fixing
> the underlaing bug.

> (there is a bug somewhere)

should be fixed

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH] Disable MSA optimization for big endian arch

[Michael Niedermayer]

On Thu, May 18, 2017 at 12:36:51PM +, Shivraj Patil wrote:
> Shivraj: yes, -mmsa flag will be added and should not be an issue for big 
> endian mips builds.
> 
> > +if enabled bigendian && enabled msa; then
> > +disable msa
> > +fi
> 
> As currently, MSA optimizations does not support big endian, above code will 
> disable MSA and switch to default C functions.

So IIUC the CPU that is build for supports MSA but its not big endian
and our hand written MSA code depends on the cpu being big endian ?

then i think its more correct to leave MSA enabled and put the code
under #if HAVE_BIGENDIAN (or some other solution)

using MSA to mean MSA on either endianness in some part of configure
and otherwise have MSA mean MSA only on big endian in other parts is
a recipe for alot of confusion

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

Re: [FFmpeg-devel] [PATCH] avfilter: take_samples: do not directly return frame when samples are skipped

[Michael Niedermayer]

On Thu, May 18, 2017 at 08:37:21PM +0700, Muhammad Faiz wrote:
> Should fix Ticket6349.
> Modifying data pointer may make it unaligned.
> 
> Also change frame->nb_samples < max to frame->nb_samples <= max.
> This improves performance. Benchmark:
> ./ffmpeg -filter_complex "aevalsrc=0:n=1166,firequalizer=fixed=on" -f null 
> null
> old:
>   25767 decicycles in take_samples,1023 runs,  1 skips
>   25422 decicycles in take_samples,2047 runs,  1 skips
>   25181 decicycles in take_samples,4095 runs,  1 skips
>   24904 decicycles in take_samples,8191 runs,  1 skips
> 
> new:
> 550 decicycles in take_samples,1024 runs,  0 skips
> 548 decicycles in take_samples,2048 runs,  0 skips
> 545 decicycles in take_samples,4096 runs,  0 skips
> 544 decicycles in take_samples,8192 runs,  0 skips
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libavfilter/avfilter.c   | 3 ++-
>  libavfilter/framequeue.c | 2 ++
>  libavfilter/framequeue.h | 5 +
>  3 files changed, 9 insertions(+), 1 deletion(-)

This patch also fixes a crash/regression with avxsynth


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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] avio_read data loss with multiple calls to fill_buffer

[Rob Meyers]

I can confirm the current source tree has resolved our issue.

On Fri, May 19, 2017 at 12:16 PM Michael Niedermayer 
wrote:

> On Fri, May 19, 2017 at 08:28:23PM +0200, Michael Niedermayer wrote:
> > hi
> >
> > On Thu, May 18, 2017 at 10:58:39PM +, Rob Meyers wrote:
> > > avio_read does multiple calls to fill_buffer(). Adjusting things in
> > > fill_buffer was frowned upon; how would you suggest I approach this?
> >
> > Its not frowned upon to fix a bug in fill_buffer(), its frowned
> > upon to make a random change that fixes a testcase without fixing
> > the underlaing bug.
>
> > (there is a bug somewhere)
>
> should be fixed
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 1
> "Used only once"- "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew
> ..."
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov: make invalid mdhd time_scale default to 1 instead of erroring out

[Michael Niedermayer]

On Wed, May 17, 2017 at 02:58:12PM +0200, Matthieu Bouron wrote:
> On Wed, May 17, 2017 at 01:56:13PM +0200, Matthieu Bouron wrote:
> > On Fri, May 12, 2017 at 11:12:12PM +0200, Michael Niedermayer wrote:
> > > On Thu, May 11, 2017 at 04:33:50PM +0200, Matthieu Bouron wrote:
> > > > Some samples have their metadata track time_scale incorrectly set to 0
> > > > and the check introduced by a398f054fdb9b0f0b5a91c231fba6ce014143f71
> > > > prevents playback of those samples. Setting the time_scale to 1 fixes
> > > > playback.
> > > > ---
> > > >  libavformat/mov.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > should be ok
> > 
> > Do you agree if I extend the patch to apply this behaviour to the mvhd
> > atoms (like a398f054fdb9b0f0b5a91c231fba6ce014143f71 originally did) ?
> 
> Here is an updated version of the patch (which extends the behaviour to
> the mvhd atoms).
> 
> -- 
> Matthieu B.

>  mov.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 00585940d50d3c53c2041566c01fdab5b6003220  
> 0001-lavf-mov-make-invalid-m-d-v-hd-time_scale-default-to.patch
> From 31d808ac885bcf1af1f546a1c8f29b1af82b381b Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Thu, 11 May 2017 15:16:22 +0200
> Subject: [PATCH] lavf/mov: make invalid m{d,v}hd time_scale default to 1
>  instead of erroring out
> 
> Some samples have their metadata track time_scale incorrectly set to 0
> and the check introduced by a398f054fdb9b0f0b5a91c231fba6ce014143f71
> prevents playback of those samples. Setting the time_scale to 1 fixes
> playback.
> ---
>  libavformat/mov.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

LGTM and seems not breaking anything

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/http.c: Free allocated client URLContext in case of error.

[Stephan Holljes]

On Sat, Apr 22, 2017 at 3:18 AM, Stephan Holljes
 wrote:
> On Tue, Apr 11, 2017 at 8:05 PM, Stephan Holljes
>  wrote:
>> ---
>>
>> This version returns 0 in case of success and does not fallthrough to fail:.
>>
>>  libavformat/http.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index 293a8a7..2917b6e 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -535,7 +535,11 @@ static int http_accept(URLContext *s, URLContext **c)
>>  goto fail;
>>  cc->hd = cl;
>>  cc->is_multi_client = 1;
>> +return 0;
>>  fail:
>> +if (c) {
>> +ffurl_close(*c);
>> +}
>>  return ret;
>>  }
>>
>> --
>> 2.9.3
>>
>
> Friendly ping :)

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