Re: [FFmpeg-devel] FFmpeg 3.2

[Stephen Hutchinson]

On 10/26/2016 10:45 PM, Michael Niedermayer wrote:

applied

you are maintainer of that file, you can send me your public ssh key
to get git write access, that would simplify your work maintaining
that file as you can push changes yourself



For something that would/will be so rarely changed and not changed
all that dramatically when it is, I really don't need (or want) to
have git write access.

Also, I've been having issues with the encryption protocols not
being set up correctly on my dev machine, so whether I'd even be
able to connect correctly is something I'd rather not worry about.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.2

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 06:12:22PM -0400, Stephen Hutchinson wrote:
> On 10/26/2016 3:29 PM, Michael Niedermayer wrote:
> >On Tue, Sep 27, 2016 at 03:30:03PM +0200, Michael Niedermayer wrote:
> >>Hi all
> >>
> >>Its long since FFmpeg 3.1, so its time to make 3.2
> >>ill branch release/3.2 off master and make 3.2 in maybe about a week or
> >>2 unless something delays it
> >
> >release/3.2 branched
> >
> >ill make the 3.2 release tomorrow from release/3.2
> >so if anyone wants to backport something, you have till then
> >
> >thx
> >[...]
> >
> >
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> I'd mentioned that https://patchwork.ffmpeg.org/patch/344/
> really needed to be committed before 3.2 was branched off,
> but if it goes in now it also needs to be backported.

applied

you are maintainer of that file, you can send me your public ssh key
to get git write access, that would simplify your work maintaining
that file as you can push changes yourself

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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Andreas Cadhalpun]

On 27.10.2016 00:16, Rostislav Pehlivanov wrote:
> On 26 October 2016 at 22:48, James Almer  wrote:
> 
>> On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:
>>> Also removes url_feof from libavformat.v which should have been
>>> removed long ago and changed the multipart jpeg boundary tag to
>>> ffmpeg rather than ffserver (it's arbitrary).
>>
>> [...]
>>
>>> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
>>> index c961cd8..47d5ddc 100644
>>> --- a/libavformat/libavformat.v
>>> +++ b/libavformat/libavformat.v
>>> @@ -1,19 +1,6 @@
>>>  LIBAVFORMAT_MAJOR {
>>>  global:
>>>  av*;
>>> -#FIXME those are for ffserver
>>> -ff_inet_aton;
>>> -ff_socket_nonblock;
>>> -ff_rtsp_parse_line;
>>> -ff_rtp_get_local_rtp_port;
>>> -ff_rtp_get_local_rtcp_port;
>>> -ffio_open_dyn_packet_buf;
>>> -ffio_set_buf_size;
>>> -ffurl_close;
>>> -ffurl_open;
>>> -ffurl_write;
>>> -#those are deprecated, remove on next bump
>>> -url_feof;
>>>  local:
>>>  *;
>>>  };
>>
>> No, this can't be done until the next major bump. url_feof is even guarded
>> by an scheduled FF_API define.
>>
>> The rest should be ok, but anything that implies a library ABI break can't
>> be done just yet. Wait for other comments and/or testing. This removes a
>> lot of things after all.
>>
> Fixed version attached without removing url_feof (apparently that's meant
> to go in the next bump, wasn't forgotten)

No, none of the symbols can be removed without a major bump. The simple reason
is that a ffserver built from the 3.1 branch still has to work with the
libavformat from the 3.2 branch.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Andreas Cadhalpun]

On 26.10.2016 22:57, Carl Eugen Hoyos wrote:
> 2016-10-26 21:36 GMT+02:00 Andreas Cadhalpun 
> :
>> On 26.10.2016 10:52, Carl Eugen Hoyos wrote:
>>> 2016-10-26 1:16 GMT+02:00 Andreas Cadhalpun 
>>> :
 I'm under the impression that __attribute__((used)) is not available
 for all compilers,
>>
>>> Yes, but __attribute__((foo_bar)) does not break compilation here.
>>
>> Have you tested with MSVC?
> 
> No.

Then it's safer to assume it doesn't work.

>> On 26.10.2016 10:55, Carl Eugen Hoyos wrote:
>>> 2016-10-26 1:35 GMT+02:00 Andreas Cadhalpun 
>>> :
>>>
 I forgot to include stdint.h. Fixed patch attached.
>>>
>>> Why don't you cast to (int)?
>>
>> Because gcc doesn't like it:
>> warning: cast from pointer to integer of different size 
>> [-Wpointer-to-int-cast]
> 
> I don't see the problem with this warning but I guess you could use
> long, no?

As Hendrik said, intptr_t is the correct type here, so I see no reason not to 
use.

Best regards,
Andreas

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

Re: [FFmpeg-devel] FFmpeg 3.2

[Stephen Hutchinson]

On 10/26/2016 3:29 PM, Michael Niedermayer wrote:

On Tue, Sep 27, 2016 at 03:30:03PM +0200, Michael Niedermayer wrote:

Hi all

Its long since FFmpeg 3.1, so its time to make 3.2
ill branch release/3.2 off master and make 3.2 in maybe about a week or
2 unless something delays it


release/3.2 branched

ill make the 3.2 release tomorrow from release/3.2
so if anyone wants to backport something, you have till then

thx
[...]



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



I'd mentioned that https://patchwork.ffmpeg.org/patch/344/
really needed to be committed before 3.2 was branched off,
but if it goes in now it also needs to be backported.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [OPW] OPW Project Proposal

[Michael Niedermayer]

On Thu, Oct 27, 2016 at 12:40:53AM +0530, Pallavi Kumari wrote:
> I mean deciding a timeline for the opw project. Which is to be mentioned in
> application

its your application, you can choose whatever timeline you feel makes
sense.
As far as iam concered whats important is to finish the qualification
task well before we have to choose the applicant(s) we accept this
year.

The timeline for the main project in dec-mar can be segmented as you
like but leave plenty of time toward the end, problems always occur
and things get delayed.
Also both for qualification and the main project submit code early
if you have questions ask early,
if you dont get satisfactory reply from me on something ask again and
louder/clearer ... i do sometimes also forget to reply until i then
remember again days later ...

also i think the architecture wasnt discussed much yet
do you have some plans about it ?

I mean for example there could be a avfilter that passes audio through
and adds fingerint(s) as metadata into thf AVFrame
(as with avpriv_frame_get_metadatap in vf_idet.c) and also print the
fingerprints via av_log()

a 2nd filter could then look these fingerprints from the metadata
up in some file/database

a 3rd one could add the fingerprints to the file/database

or these also could all be in one filter of course

this can be extended in the future to for example have a filter
delay the audio until lookup succeeds and then once identified
lookup lyrics online and add them or such (this of course would be a
future thing after outreachy/opw)

but maybe you have a different plan on how the components would
interact ?

thx

> 
> On Wed, Oct 26, 2016 at 6:01 PM, Michael Niedermayer  > wrote:
> 
> > Hi
> >
> > On Mon, Oct 17, 2016 at 02:06:26PM +0530, Pallavi Kumari wrote:
> > > Hi Michael,
> > >
> > > I figured out the use of fft. Help me with the time line setting. Thanks
> >
> > I dont understand the question,
> > if its about AVFILTER_FLAG_SUPPORT_TIMELINE*, please ignore this for
> > now, its not needed
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Rewriting code that is poorly written but fully understood is good.
> > Rewriting code that one doesnt understand is a sign that one is less smart
> > then the original author, trying to rewrite it will not make it better.
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[James Almer]

On 10/26/2016 6:19 PM, Rostislav Pehlivanov wrote:
> Also removes url_feof from libavformat.v which should have been
> removed long ago and changed the multipart jpeg boundary tag to
> ffmpeg rather than ffserver (it's arbitrary).

[...]

> diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
> index c961cd8..47d5ddc 100644
> --- a/libavformat/libavformat.v
> +++ b/libavformat/libavformat.v
> @@ -1,19 +1,6 @@
>  LIBAVFORMAT_MAJOR {
>  global:
>  av*;
> -#FIXME those are for ffserver
> -ff_inet_aton;
> -ff_socket_nonblock;
> -ff_rtsp_parse_line;
> -ff_rtp_get_local_rtp_port;
> -ff_rtp_get_local_rtcp_port;
> -ffio_open_dyn_packet_buf;
> -ffio_set_buf_size;
> -ffurl_close;
> -ffurl_open;
> -ffurl_write;
> -#those are deprecated, remove on next bump
> -url_feof;
>  local:
>  *;
>  };

No, this can't be done until the next major bump. url_feof is even guarded
by an scheduled FF_API define.

The rest should be ok, but anything that implies a library ABI break can't
be done just yet. Wait for other comments and/or testing. This removes a
lot of things after all.

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

Re: [FFmpeg-devel] FFmpeg 3.2

[Michael Niedermayer]

On Tue, Sep 27, 2016 at 03:30:03PM +0200, Michael Niedermayer wrote:
> Hi all
> 
> Its long since FFmpeg 3.1, so its time to make 3.2
> ill branch release/3.2 off master and make 3.2 in maybe about a week or
> 2 unless something delays it

release/3.2 branched

ill make the 3.2 release tomorrow from release/3.2
so if anyone wants to backport something, you have till then

thx
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Hendrik Leppkes]

On Wed, Oct 26, 2016 at 10:57 PM, Carl Eugen Hoyos  wrote:
> 2016-10-26 21:36 GMT+02:00 Andreas Cadhalpun 
> :
>> On 26.10.2016 10:52, Carl Eugen Hoyos wrote:
>>> 2016-10-26 1:16 GMT+02:00 Andreas Cadhalpun 
>>> :
 I'm under the impression that __attribute__((used)) is not available
 for all compilers,
>>
>>> Yes, but __attribute__((foo_bar)) does not break compilation here.
>>
>> Have you tested with MSVC?
>
> No.
>
>>> (But it is still a regression: 3.1 should not have seen the patch,
>>> it doesn't support new incompatible external libraries, and the
>>> issue was neither a regression nor security-related.)
>>
>> This was not about a new external library, the support was added
>> in 2015 (commit 99eabcd), and I think fixing build failures is quite
>> sensible for release branches.
>
> Sorry for bringing this up.
>
>> On 26.10.2016 10:55, Carl Eugen Hoyos wrote:
>>> 2016-10-26 1:35 GMT+02:00 Andreas Cadhalpun 
>>> :
>>>
 I forgot to include stdint.h. Fixed patch attached.
>>>
>>> Why don't you cast to (int)?
>>
>> Because gcc doesn't like it:
>> warning: cast from pointer to integer of different size 
>> [-Wpointer-to-int-cast]
>
> I don't see the problem with this warning but I guess you could use
> long, no?
>

long is still 32-bit on some 64-bit platforms. intptr_t is the type
designed for this, whats wrong with using it?

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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Carl Eugen Hoyos]

2016-10-26 21:36 GMT+02:00 Andreas Cadhalpun :
> On 26.10.2016 10:52, Carl Eugen Hoyos wrote:
>> 2016-10-26 1:16 GMT+02:00 Andreas Cadhalpun 
>> :
>>> I'm under the impression that __attribute__((used)) is not available
>>> for all compilers,
>
>> Yes, but __attribute__((foo_bar)) does not break compilation here.
>
> Have you tested with MSVC?

No.

>> (But it is still a regression: 3.1 should not have seen the patch,
>> it doesn't support new incompatible external libraries, and the
>> issue was neither a regression nor security-related.)
>
> This was not about a new external library, the support was added
> in 2015 (commit 99eabcd), and I think fixing build failures is quite
> sensible for release branches.

Sorry for bringing this up.

> On 26.10.2016 10:55, Carl Eugen Hoyos wrote:
>> 2016-10-26 1:35 GMT+02:00 Andreas Cadhalpun 
>> :
>>
>>> I forgot to include stdint.h. Fixed patch attached.
>>
>> Why don't you cast to (int)?
>
> Because gcc doesn't like it:
> warning: cast from pointer to integer of different size 
> [-Wpointer-to-int-cast]

I don't see the problem with this warning but I guess you could use
long, no?

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

Re: [FFmpeg-devel] FFmpeg 3.2

[James Almer]

On 10/26/2016 5:44 PM, d...@dericed.com wrote:
> 
>> On Oct 26, 2016, at 3:29 PM, Michael Niedermayer  
>> wrote:
>>
>> On Tue, Sep 27, 2016 at 03:30:03PM +0200, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> Its long since FFmpeg 3.1, so its time to make 3.2
>>> ill branch release/3.2 off master and make 3.2 in maybe about a week or
>>> 2 unless something delays it
>>
>> release/3.2 branched
>>
>> ill make the 3.2 release tomorrow from release/3.2
>> so if anyone wants to backport something, you have till then
> 
> Maybe too late, but it is possible to include 
> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/eabbc64728c2fdb74f565aededec2ab023d20699
>  
> 
>  in 3.2. It resolves a regression added just before 3.2.
> Dave

I already cherry picked that commit for the 3.2 branch.
Pushed it to master and release/3.2 at the same time.

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

Re: [FFmpeg-devel] FFmpeg 3.2

[dave]

> On Oct 26, 2016, at 4:44 PM, d...@dericed.com wrote:
> 
> 
>> On Oct 26, 2016, at 3:29 PM, Michael Niedermayer > > wrote:
>> 
>> On Tue, Sep 27, 2016 at 03:30:03PM +0200, Michael Niedermayer wrote:
>>> Hi all
>>> 
>>> Its long since FFmpeg 3.1, so its time to make 3.2
>>> ill branch release/3.2 off master and make 3.2 in maybe about a week or
>>> 2 unless something delays it
>> 
>> release/3.2 branched
>> 
>> ill make the 3.2 release tomorrow from release/3.2
>> so if anyone wants to backport something, you have till then
> 
> Maybe too late, but it is possible to include 
> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/eabbc64728c2fdb74f565aededec2ab023d20699
>  
> 
>  in 3.2. It resolves a regression added just before 3.2.

Sorry about this. I see James referenced the same issue in 
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201831.html 
.
Dave Rice

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

Re: [FFmpeg-devel] FFmpeg 3.2

[dave]

> On Oct 26, 2016, at 3:29 PM, Michael Niedermayer  
> wrote:
> 
> On Tue, Sep 27, 2016 at 03:30:03PM +0200, Michael Niedermayer wrote:
>> Hi all
>> 
>> Its long since FFmpeg 3.1, so its time to make 3.2
>> ill branch release/3.2 off master and make 3.2 in maybe about a week or
>> 2 unless something delays it
> 
> release/3.2 branched
> 
> ill make the 3.2 release tomorrow from release/3.2
> so if anyone wants to backport something, you have till then

Maybe too late, but it is possible to include 
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/eabbc64728c2fdb74f565aededec2ab023d20699
 

 in 3.2. It resolves a regression added just before 3.2.
Dave
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.2

[Helmut K. C. Tessarek]

On 2016-10-26 15:29, Michael Niedermayer wrote:
> release/3.2 branched
> 
> ill make the 3.2 release tomorrow from release/3.2
> so if anyone wants to backport something, you have till then

ffserver is still in that branch. I thought it would be removed from the
repo and the configure script. Or am I missing something?

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://sks.pkqs.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: fix cue relative position values when CRC32 is enabled

[James Almer]

On 10/25/2016 12:38 PM, James Almer wrote:
> The dynamic buffer does not contain the CRC32 element so calls to avio_tell()
> don't take it into account. This resulted in CueRelativePosition values being
> six bytes short.
> This is a regression since 6724525a1576ca334d2ffdc085620bb44aea7394

Pushed so it makes it to release 3.2, being a fix for a recent regression in a
muxer.

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

[FFmpeg-devel] [PATCH 07/10] crystalhd: Keep NOPTS_VALUE so we know it's not there.

[Philip Langdale]

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index b68701a..4ac138c 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -848,8 +848,7 @@ static int crystalhd_decode_packet(AVCodecContext *avctx, 
const AVPacket *avpkt)
  * avoiding mangling so we need to build a mapping to values
  * we know will not be mangled.
  */
-int64_t safe_pts = avpkt->pts == AV_NOPTS_VALUE ? 0 : avpkt->pts;
-uint64_t pts = opaque_list_push(priv, safe_pts);
+uint64_t pts = opaque_list_push(priv, avpkt->pts);
 if (!pts) {
 ret = AVERROR(ENOMEM);
 goto exit;
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] mpeg2video: Return correct coded frame sizes from parser

[Mark Thompson]

---
 libavcodec/mpegvideo_parser.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 206f268..de70cd5 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/libavcodec/mpegvideo_parser.c
@@ -168,8 +168,10 @@ static void mpegvideo_extract_headers(AVCodecParserContext 
*s,

 if (pix_fmt != AV_PIX_FMT_NONE) {
 s->format = pix_fmt;
-s->width  = s->coded_width  = pc->width;
-s->height = s->coded_height = pc->height;
+s->width  = pc->width;
+s->height = pc->height;
+s->coded_width  = FFALIGN(pc->width,  16);
+s->coded_height = FFALIGN(pc->height, 16);
 }

 #if FF_API_AVCTX_TIMEBASE
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] avformat: close parser if codec changed

[Andreas Cadhalpun]

On 22.10.2016 01:16, Andreas Cadhalpun wrote:
> From 9de87a4fb2c6c6311a11a2da5de8554a71adfa66 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Mon, 17 Oct 2016 20:26:51 +0200
> Subject: [PATCH] avformat: close parser if codec changed
> 
> The parser depends on the codec and thus must not be used with a different 
> one.
> If it is, the 'avctx->codec_id == s->parser->codec_ids[0] ...' assert in
> av_parser_parse2 gets triggered.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/utils.c | 12 
>  1 file changed, 12 insertions(+)

Ping. (I'd like to have this in 3.2.)

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 00/10] crystalhd: Move to new decode API

[Philip Langdale]

The CrystalHD hardware decoder is an excellent example of something that was
ill-suited to the old 1:1 decode API. I had to put in a ton of fragile
heuristics and sleep()s to make it mostly work.

By switching to the new m:n decode API, all that crap can get tossed out,
and things actually look sane now.

Obviously, switching to the new API while dropping support for the old one
is an incompatible change, but the decoder functionality with the old API
was so fragile that it just isn't worth maintaing - and obviously, retaining
support for the old API means keeping all the hacks, so we'd gain nothing.

Philip Langdale (10):
  crystalhd: Fix up the missing first sample
  crystalhd: Switch to new decode API and remove the insanity
  crystalhd: Revert back to letting hardware handle packed b-frames
  crystalhd: Remove trust_interlaced heuristic
  crystalhd: We don't need the track the last picture number anymore
  crystalhd: Remove h.264 parser
  crystalhd: Keep NOPTS_VALUE so we know it's not there.
  crystalhd: Loop for a frame internally where possible.
  crystalhd: Simplify output frame handling
  crystalhd: Update high level description

 libavcodec/crystalhd.c | 699 +
 libavcodec/version.h   |   2 +-
 2 files changed, 178 insertions(+), 523 deletions(-)

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

[FFmpeg-devel] [PATCH 03/10] crystalhd: Revert back to letting hardware handle packed b-frames

[Philip Langdale]

I'm not sure why, but the mpeg4_unpack_bframes bsf is not
interacting well with seeking. Looking at the code, it should be
ok, with possibly one warning shown, but I see it getting stuck
for an extended period of time after a seek where a packed frame
is cached to be shown later.

So, I gave up on that and went back to making the old hardware
based path work. Turns out that it wasn't broken except that some
samples have a 6 byte drop packet which I wasn't accounting for.

Now it works again and seeks are good.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 37 +
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index dca58f2..c1ca066 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -140,6 +140,7 @@ typedef struct {
 
 /* Options */
 uint32_t sWidth;
+uint8_t bframe_bug;
 } CHDContext;
 
 static const AVOption options[] = {
@@ -460,14 +461,6 @@ static av_cold int init(AVCodecContext *avctx)
 format.pMetaData  = avctx->extradata;
 format.metaDataSz = avctx->extradata_size;
 break;
-case BC_MSUBTYPE_DIVX:
-avret = init_bsf(avctx, "mpeg4_unpack_bframes");
-if (avret != 0) {
-return avret;
-}
-format.pMetaData  = avctx->extradata;
-format.metaDataSz = avctx->extradata_size;
-break;
 case BC_MSUBTYPE_H264:
 format.startCodeSz = 4;
 // Fall-through
@@ -476,6 +469,7 @@ static av_cold int init(AVCodecContext *avctx)
 case BC_MSUBTYPE_WMV3:
 case BC_MSUBTYPE_WMVA:
 case BC_MSUBTYPE_MPEG2VIDEO:
+case BC_MSUBTYPE_DIVX:
 case BC_MSUBTYPE_DIVX311:
 format.pMetaData  = avctx->extradata;
 format.metaDataSz = avctx->extradata_size;
@@ -829,6 +823,17 @@ static inline CopyRet receive_frame(AVCodecContext *avctx,
 priv->last_picture = output.PicInfo.picture_number - 1;
 }
 
+if (avctx->codec->id == AV_CODEC_ID_MPEG4 &&
+output.PicInfo.timeStamp == 0 && priv->bframe_bug) {
+if (!priv->bframe_bug) {
+av_log(avctx, AV_LOG_VERBOSE,
+   "CrystalHD: Not returning packed frame twice.\n");
+}
+priv->last_picture++;
+DtsReleaseOutputBuffs(dev, NULL, FALSE);
+return RET_COPY_AGAIN;
+}
+
 print_frame_info(priv, );
 
 if (priv->last_picture + 1 < output.PicInfo.picture_number) {
@@ -879,6 +884,22 @@ static int crystalhd_decode_packet(AVCodecContext *avctx, 
const AVPacket *avpkt)
 if (avpkt && avpkt->size) {
 int32_t tx_free = (int32_t)DtsTxFreeSize(dev);
 
+if (!priv->bframe_bug && (avpkt->size == 6 || avpkt->size == 7)) {
+/*
+ * Drop frames trigger the bug
+ */
+av_log(avctx, AV_LOG_WARNING,
+   "CrystalHD: Enabling work-around for packed b-frame bug\n");
+priv->bframe_bug = 1;
+} else if (priv->bframe_bug && avpkt->size == 8) {
+/*
+ * Delay frames don't trigger the bug
+ */
+av_log(avctx, AV_LOG_WARNING,
+   "CrystalHD: Disabling work-around for packed b-frame 
bug\n");
+priv->bframe_bug = 0;
+}
+
 if (priv->bsfc) {
 AVPacket filter_packet = { 0 };
 
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 10/10] crystalhd: Update high level description

[Philip Langdale]

We don't need to document the horrible hacks that we removed.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 38 +-
 1 file changed, 5 insertions(+), 33 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 7cf2c75..d85e351 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -34,39 +34,11 @@
  * is not just a function of time, but also one of the dependency on additional
  * frames being fed into the decoder to satisfy the b-frame dependencies.
  *
- * As such, a pipeline will build up that is roughly equivalent to the required
- * DPB for the file being played. If that was all it took, things would still
- * be simple - so, of course, it isn't.
- *
- * The hardware has a way of indicating that a picture is ready to be copied 
out,
- * but this is unreliable - and sometimes the attempt will still fail so, based
- * on testing, the code will wait until 3 pictures are ready before starting
- * to copy out - and this has the effect of extending the pipeline.
- *
- * Finally, while it is tempting to say that once the decoder starts outputting
- * frames, the software should never fail to return a frame from a decode(),
- * this is a hard assertion to make, because the stream may switch between
- * differently encoded content (number of b-frames, interlacing, etc) which
- * might require a longer pipeline than before. If that happened, you could
- * deadlock trying to retrieve a frame that can't be decoded without feeding
- * in additional packets.
- *
- * As such, the code will return in the event that a picture cannot be copied
- * out, leading to an increase in the length of the pipeline. This in turn,
- * means we have to be sensitive to the time it takes to decode a picture;
- * We do not want to give up just because the hardware needed a little more
- * time to prepare the picture! For this reason, there are delays included
- * in the decode() path that ensure that, under normal conditions, the hardware
- * will only fail to return a frame if it really needs additional packets to
- * complete the decoding.
- *
- * Finally, to be explicit, we do not want the pipeline to grow without bound
- * for two reasons: 1) The hardware can only buffer a finite number of packets,
- * and 2) The client application may not be able to cope with arbitrarily long
- * delays in the video path relative to the audio path. For example. MPlayer
- * can only handle a 20 picture delay (although this is arbitrary, and needs
- * to be extended to fully support the CrystalHD where the delay could be up
- * to 32 pictures - consider PAFF H.264 content with 16 b-frames).
+ * As such, the hardware can only be used effectively with a decode API that
+ * doesn't assume a 1:1 relationship between input packets and output frames.
+ * The new avcodec decode API is such an API (an m:n API) while the old one is
+ * 1:1. Consequently, we no longer support the old API, which allows us to 
avoid
+ * the vicious hacks that are required to approximate 1:1 operation.
  */
 
 /*
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 04/10] crystalhd: Remove trust_interlaced heuristic

[Philip Langdale]

It seems that without all the other 1:1 heuristics, we don't have
a fundamental problem trusting the interlaced flag on output
pictures. That's a relief.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 37 -
 1 file changed, 4 insertions(+), 33 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index c1ca066..d738ddb 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -561,7 +561,6 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 {
 BC_STATUS ret;
 BC_DTS_STATUS decoder_status = { 0, };
-uint8_t trust_interlaced;
 uint8_t interlaced;
 
 CHDContext *priv = avctx->priv_data;
@@ -611,29 +610,7 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 }
 
 /*
- * For most content, we can trust the interlaced flag returned
- * by the hardware, but sometimes we can't. These are the
- * conditions under which we can trust the flag:
- *
- * 1) It's not h.264 content
- * 2) The UNKNOWN_SRC flag is not set
- * 3) We know we're expecting a second field
- * 4) The hardware reports this picture and the next picture
- *have the same picture number.
- *
- * Note that there can still be interlaced content that will
- * fail this check, if the hardware hasn't decoded the next
- * picture or if there is a corruption in the stream. (In either
- * case a 0 will be returned for the next picture number)
- */
-trust_interlaced = avctx->codec->id != AV_CODEC_ID_H264 ||
-   !(output->PicInfo.flags & VDEC_FLAG_UNKNOWN_SRC) ||
-   priv->need_second_field ||
-   (decoder_status.picNumFlags & ~0x4000) ==
-   output->PicInfo.picture_number;
-
-/*
- * If we got a false negative for trust_interlaced on the first field,
+ * If we got a false negative for interlaced on the first field,
  * we will realise our mistake here when we see that the picture number is 
that
  * of the previous picture. We cannot recover the frame and should discard 
the
  * second field to keep the correct number of output frames.
@@ -645,16 +622,10 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 return RET_OK;
 }
 
-interlaced = (output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC) &&
- trust_interlaced;
-
-if (!trust_interlaced && (decoder_status.picNumFlags & ~0x4000) == 0) {
-av_log(avctx, AV_LOG_VERBOSE,
-   "Next picture number unknown. Assuming progressive frame.\n");
-}
+interlaced = output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC;
 
-av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d | trust_interlaced 
%d\n",
-   interlaced, trust_interlaced);
+av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d\n",
+   interlaced);
 
 if (priv->pic->data[0] && !priv->need_second_field)
 av_frame_unref(priv->pic);
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 01/10] crystalhd: Fix up the missing first sample

[Philip Langdale]

Why on earth the hardware returns garbage for the first sample of
a decoded picture is anyone's guess. The simplest reasonable way
to patch it up is to copy the first sample of the second line. This
should result in the correct chroma values (because the data was
original 4:2:0 upsampled to 4:2:2) even if the luma is isn't.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 9120940..137ed20 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -706,6 +706,15 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 
 av_log(priv->avctx, AV_LOG_VERBOSE, "CrystalHD: Copying out frame\n");
 
+/*
+ * The hardware doesn't return the first sample of a picture.
+ * Ignoring why it behaves this way, it's better to copy the sample from
+ * the second line, rather than the next sample across because the chroma
+ * values should be correct (assuming the decoded video was 4:2:0, which
+ * it was).
+ */
+*((uint32_t *)src) = *((uint32_t *)(src + sStride));
+
 if (interlaced) {
 int dY = 0;
 int sY = 0;
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 09/10] crystalhd: Simplify output frame handling

[Philip Langdale]

The old code had to retain a partial frame across two calls in
the case of separate interlaced fields. Now, we know that we'll
get both fields within the same receive_frame call, and so we
don't need to manage the frame as private state any more.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 42 +++---
 1 file changed, 15 insertions(+), 27 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 2d803ab..7cf2c75 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -117,7 +117,6 @@ typedef struct OpaqueList {
 typedef struct {
 AVClass *av_class;
 AVCodecContext *avctx;
-AVFrame *pic;
 HANDLE dev;
 
 uint8_t *orig_extradata;
@@ -308,8 +307,6 @@ static void flush(AVCodecContext *avctx)
 priv->need_second_field = 0;
 priv->draining  = 0;
 
-av_frame_unref (priv->pic);
-
 /* Flush mode 4 flushes all software and hardware buffers. */
 DtsFlushInput(priv->dev, 4);
 }
@@ -344,8 +341,6 @@ static av_cold int uninit(AVCodecContext *avctx)
 
 av_freep(>sps_pps_buf);
 
-av_frame_free (>pic);
-
 if (priv->head) {
OpaqueList *node = priv->head;
while (node) {
@@ -440,7 +435,6 @@ static av_cold int init(AVCodecContext *avctx)
 priv   = avctx->priv_data;
 priv->avctx= avctx;
 priv->is_nal   = avctx->extradata_size > 0 && *(avctx->extradata) == 1;
-priv->pic  = av_frame_alloc();
 priv->draining = 0;
 
 subtype = id2subtype(priv, avctx->codec->id);
@@ -543,7 +537,7 @@ static av_cold int init(AVCodecContext *avctx)
 
 static inline CopyRet copy_frame(AVCodecContext *avctx,
  BC_DTS_PROC_OUT *output,
- void *data, int *got_frame)
+ AVFrame *frame, int *got_frame)
 {
 BC_STATUS ret;
 BC_DTS_STATUS decoder_status = { 0, };
@@ -594,13 +588,10 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d\n",
interlaced);
 
-if (priv->pic->data[0] && !priv->need_second_field)
-av_frame_unref(priv->pic);
-
 priv->need_second_field = interlaced && !priv->need_second_field;
 
-if (!priv->pic->data[0]) {
-if (ff_get_buffer(avctx, priv->pic, AV_GET_BUFFER_FLAG_REF) < 0)
+if (!frame->data[0]) {
+if (ff_get_buffer(avctx, frame, 0) < 0)
 return RET_ERROR;
 }
 
@@ -618,8 +609,8 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 sStride = bwidth;
 }
 
-dStride = priv->pic->linesize[0];
-dst = priv->pic->data[0];
+dStride = frame->linesize[0];
+dst = frame->data[0];
 
 av_log(priv->avctx, AV_LOG_VERBOSE, "CrystalHD: Copying out frame\n");
 
@@ -653,27 +644,24 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 av_image_copy_plane(dst, dStride, src, sStride, bwidth, height);
 }
 
-priv->pic->interlaced_frame = interlaced;
+frame->interlaced_frame = interlaced;
 if (interlaced)
-priv->pic->top_field_first = !bottom_first;
+frame->top_field_first = !bottom_first;
 
 if (pkt_pts != AV_NOPTS_VALUE) {
-priv->pic->pts = pkt_pts;
+frame->pts = pkt_pts;
 #if FF_API_PKT_PTS
 FF_DISABLE_DEPRECATION_WARNINGS
-priv->pic->pkt_pts = pkt_pts;
+frame->pkt_pts = pkt_pts;
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 }
-av_frame_set_pkt_pos(priv->pic, -1);
-av_frame_set_pkt_duration(priv->pic, 0);
-av_frame_set_pkt_size(priv->pic, -1);
+av_frame_set_pkt_pos(frame, -1);
+av_frame_set_pkt_duration(frame, 0);
+av_frame_set_pkt_size(frame, -1);
 
 if (!priv->need_second_field) {
 *got_frame   = 1;
-if ((ret = av_frame_ref(data, priv->pic)) < 0) {
-return ret;
-}
 } else {
 return RET_COPY_AGAIN;
 }
@@ -683,7 +671,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 
 static inline CopyRet receive_frame(AVCodecContext *avctx,
-void *data, int *got_frame)
+AVFrame *frame, int *got_frame)
 {
 BC_STATUS ret;
 BC_DTS_PROC_OUT output = {
@@ -767,7 +755,7 @@ static inline CopyRet receive_frame(AVCodecContext *avctx,
 
 print_frame_info(priv, );
 
-copy_ret = copy_frame(avctx, , data, got_frame);
+copy_ret = copy_frame(avctx, , frame, got_frame);
 } else {
 /*
  * An invalid frame has been consumed.
@@ -945,7 +933,7 @@ static int crystalhd_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 .send_packet= crystalhd_decode_packet, \
 .receive_frame  = crystalhd_receive_frame, \
 .flush  = flush, \
-.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY | 
AV_CODEC_CAP_AVOID_PROBING, \
+.capabilities   = 

[FFmpeg-devel] [PATCH 02/10] crystalhd: Switch to new decode API and remove the insanity

[Philip Langdale]

The new decode API allows for m:n decode patterns, which is what
you need to use this hardware in a sane way. There are so many
situations where 1:1 doesn't happen naturally that it's a miracle
I got it working as well as I did.

With this change, we can throw all of the crazy heuristics and
sleeps(!) out, and things work correctly.

Small issue - mpv (at least) expects that every output call after
input EOF returns a frame or is the end of the stream - this is not
behaviour we can offer - sometimes we have separate fields that
require two calls to collect and combine.

Trying to do a tight loop in the decoder to get the second field
requires restoring some heuristics to avoid dead-locking when
additional input is required to get additional output.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 480 +
 libavcodec/version.h   |   2 +-
 2 files changed, 126 insertions(+), 356 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 137ed20..dca58f2 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -97,10 +97,6 @@
 #define OUTPUT_PROC_TIMEOUT 50
 /** Step between fake timestamps passed to hardware in units of 100ns */
 #define TIMESTAMP_UNIT 10
-/** Initial value in us of the wait in decode() */
-#define BASE_WAIT 1
-/** Increment in us to adjust wait in decode() */
-#define WAIT_UNIT 1000
 
 
 /*
@@ -110,9 +106,6 @@
 typedef enum {
 RET_ERROR   = -1,
 RET_OK  = 0,
-RET_COPY_AGAIN  = 1,
-RET_SKIP_NEXT_COPY  = 2,
-RET_COPY_NEXT_FIELD = 3,
 } CopyRet;
 
 typedef struct OpaqueList {
@@ -138,10 +131,7 @@ typedef struct {
 uint8_t *sps_pps_buf;
 uint32_t sps_pps_size;
 uint8_t is_nal;
-uint8_t output_ready;
 uint8_t need_second_field;
-uint8_t skip_next_output;
-uint64_t decode_wait;
 
 uint64_t last_picture;
 
@@ -188,42 +178,42 @@ static inline BC_MEDIA_SUBTYPE id2subtype(CHDContext 
*priv, enum AVCodecID id)
 
 static inline void print_frame_info(CHDContext *priv, BC_DTS_PROC_OUT *output)
 {
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tYBuffSz: %u\n", output->YbuffSz);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tYBuffDoneSz: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tYBuffSz: %u\n", output->YbuffSz);
+av_log(priv->avctx, AV_LOG_TRACE, "\tYBuffDoneSz: %u\n",
output->YBuffDoneSz);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tUVBuffDoneSz: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tUVBuffDoneSz: %u\n",
output->UVBuffDoneSz);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tTimestamp: %"PRIu64"\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tTimestamp: %"PRIu64"\n",
output->PicInfo.timeStamp);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tPicture Number: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tPicture Number: %u\n",
output->PicInfo.picture_number);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tWidth: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tWidth: %u\n",
output->PicInfo.width);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tHeight: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tHeight: %u\n",
output->PicInfo.height);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tChroma: 0x%03x\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tChroma: 0x%03x\n",
output->PicInfo.chroma_format);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tPulldown: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tPulldown: %u\n",
output->PicInfo.pulldown);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tFlags: 0x%08x\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tFlags: 0x%08x\n",
output->PicInfo.flags);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tFrame Rate/Res: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tFrame Rate/Res: %u\n",
output->PicInfo.frame_rate);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tAspect Ratio: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tAspect Ratio: %u\n",
output->PicInfo.aspect_ratio);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tColor Primaries: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tColor Primaries: %u\n",
output->PicInfo.colour_primaries);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tMetaData: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tMetaData: %u\n",
output->PicInfo.picture_meta_payload);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tSession Number: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tSession Number: %u\n",
output->PicInfo.sess_num);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tycom: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tycom: %u\n",
output->PicInfo.ycom);
-av_log(priv->avctx, AV_LOG_VERBOSE, "\tCustom Aspect: %u\n",
+av_log(priv->avctx, AV_LOG_TRACE, "\tCustom Aspect: %u\n",

[FFmpeg-devel] [PATCH 08/10] crystalhd: Loop for a frame internally where possible.

[Philip Langdale]

It's not possible to return EAGAIN when we've passed input EOF and are
in draining mode. If do return EAGAIN, we're saying there's no way to
get any more output - which isn't true in many cases.

So let's handled these cases in an internal loop as best we can.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 40 ++--
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 4ac138c..2d803ab 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -105,6 +105,7 @@
 typedef enum {
 RET_ERROR   = -1,
 RET_OK  = 0,
+RET_COPY_AGAIN  = 1,
 } CopyRet;
 
 typedef struct OpaqueList {
@@ -129,6 +130,7 @@ typedef struct {
 uint32_t sps_pps_size;
 uint8_t is_nal;
 uint8_t need_second_field;
+uint8_t draining;
 
 OpaqueList *head;
 OpaqueList *tail;
@@ -304,6 +306,7 @@ static void flush(AVCodecContext *avctx)
 CHDContext *priv = avctx->priv_data;
 
 priv->need_second_field = 0;
+priv->draining  = 0;
 
 av_frame_unref (priv->pic);
 
@@ -438,6 +441,7 @@ static av_cold int init(AVCodecContext *avctx)
 priv->avctx= avctx;
 priv->is_nal   = avctx->extradata_size > 0 && *(avctx->extradata) == 1;
 priv->pic  = av_frame_alloc();
+priv->draining = 0;
 
 subtype = id2subtype(priv, avctx->codec->id);
 switch (subtype) {
@@ -670,6 +674,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if ((ret = av_frame_ref(data, priv->pic)) < 0) {
 return ret;
 }
+} else {
+return RET_COPY_AGAIN;
 }
 
 return RET_OK;
@@ -745,7 +751,7 @@ static inline CopyRet receive_frame(AVCodecContext *avctx,
 avctx->sample_aspect_ratio = (AVRational) {221,  1};
 break;
 }
-return RET_OK;
+return RET_COPY_AGAIN;
 } else if (ret == BC_STS_SUCCESS) {
 int copy_ret = -1;
 if (output.PoutFlags & BC_POUT_FLAGS_PIB_VALID) {
@@ -768,13 +774,13 @@ static inline CopyRet receive_frame(AVCodecContext *avctx,
  */
 av_log(avctx, AV_LOG_ERROR, "CrystalHD: ProcOutput succeeded with "
 "invalid PIB\n");
-copy_ret = RET_OK;
+copy_ret = RET_COPY_AGAIN;
 }
 DtsReleaseOutputBuffs(dev, NULL, FALSE);
 
 return copy_ret;
 } else if (ret == BC_STS_BUSY) {
-return RET_OK;
+return RET_COPY_AGAIN;
 } else {
 av_log(avctx, AV_LOG_ERROR, "CrystalHD: ProcOutput failed %d\n", ret);
 return RET_ERROR;
@@ -874,6 +880,7 @@ static int crystalhd_decode_packet(AVCodecContext *avctx, 
const AVPacket *avpkt)
 }
 } else {
 av_log(avctx, AV_LOG_INFO, "CrystalHD: No more input data\n");
+priv->draining = 1;
 ret = AVERROR_EOF;
 goto exit;
 }
@@ -893,22 +900,27 @@ static int crystalhd_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 
 av_log(avctx, AV_LOG_VERBOSE, "CrystalHD: receive_frame\n");
 
-bc_ret = DtsGetDriverStatus(dev, _status);
-if (bc_ret != BC_STS_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "CrystalHD: GetDriverStatus failed\n");
-return -1;
-}
+do {
+bc_ret = DtsGetDriverStatus(dev, _status);
+if (bc_ret != BC_STS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "CrystalHD: GetDriverStatus failed\n");
+return -1;
+}
 
-if (decoder_status.ReadyListCount == 0) {
-av_log(avctx, AV_LOG_INFO, "CrystalHD: Insufficient frames ready. 
Returning\n");
-return AVERROR(EAGAIN);
-}
+if (decoder_status.ReadyListCount == 0) {
+av_log(avctx, AV_LOG_INFO, "CrystalHD: Insufficient frames ready. 
Returning\n");
+got_frame = 0;
+rec_ret = RET_OK;
+break;
+}
+
+rec_ret = receive_frame(avctx, frame, _frame);
+} while (rec_ret == RET_COPY_AGAIN);
 
-rec_ret = receive_frame(avctx, frame, _frame);
 if (rec_ret == RET_ERROR) {
 return -1;
 } else if (got_frame == 0) {
-return AVERROR(EAGAIN);
+return priv->draining ? AVERROR_EOF : AVERROR(EAGAIN);
 } else {
 return 0;
 }
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 05/10] crystalhd: We don't need the track the last picture number anymore

[Philip Langdale]

This was needed to detect an interlaced failure case that doesn't
happen with the new decode api.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 40 
 1 file changed, 40 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index d738ddb..3db0e17 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -133,8 +133,6 @@ typedef struct {
 uint8_t is_nal;
 uint8_t need_second_field;
 
-uint64_t last_picture;
-
 OpaqueList *head;
 OpaqueList *tail;
 
@@ -310,7 +308,6 @@ static void flush(AVCodecContext *avctx)
 {
 CHDContext *priv = avctx->priv_data;
 
-priv->last_picture  = -1;
 priv->need_second_field = 0;
 
 av_frame_unref (priv->pic);
@@ -446,7 +443,6 @@ static av_cold int init(AVCodecContext *avctx)
 priv   = avctx->priv_data;
 priv->avctx= avctx;
 priv->is_nal   = avctx->extradata_size > 0 && *(avctx->extradata) == 1;
-priv->last_picture = -1;
 priv->pic  = av_frame_alloc();
 
 subtype = id2subtype(priv, avctx->codec->id);
@@ -609,19 +605,6 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
return RET_ERROR;
 }
 
-/*
- * If we got a false negative for interlaced on the first field,
- * we will realise our mistake here when we see that the picture number is 
that
- * of the previous picture. We cannot recover the frame and should discard 
the
- * second field to keep the correct number of output frames.
- */
-if (output->PicInfo.picture_number == priv->last_picture && 
!priv->need_second_field) {
-av_log(avctx, AV_LOG_WARNING,
-   "Incorrectly guessed progressive frame. Discarding second 
field\n");
-/* Returning without providing a picture. */
-return RET_OK;
-}
-
 interlaced = output->PicInfo.flags & VDEC_FLAG_INTERLACED_SRC;
 
 av_log(avctx, AV_LOG_VERBOSE, "Interlaced state: %d\n",
@@ -786,42 +769,19 @@ static inline CopyRet receive_frame(AVCodecContext *avctx,
 } else if (ret == BC_STS_SUCCESS) {
 int copy_ret = -1;
 if (output.PoutFlags & BC_POUT_FLAGS_PIB_VALID) {
-if (priv->last_picture == -1) {
-/*
- * Init to one less, so that the incrementing code doesn't
- * need to be special-cased.
- */
-priv->last_picture = output.PicInfo.picture_number - 1;
-}
-
 if (avctx->codec->id == AV_CODEC_ID_MPEG4 &&
 output.PicInfo.timeStamp == 0 && priv->bframe_bug) {
 if (!priv->bframe_bug) {
 av_log(avctx, AV_LOG_VERBOSE,
"CrystalHD: Not returning packed frame twice.\n");
 }
-priv->last_picture++;
 DtsReleaseOutputBuffs(dev, NULL, FALSE);
 return RET_COPY_AGAIN;
 }
 
 print_frame_info(priv, );
 
-if (priv->last_picture + 1 < output.PicInfo.picture_number) {
-av_log(avctx, AV_LOG_WARNING,
-   "CrystalHD: Picture Number discontinuity\n");
-/*
- * XXX: I have no idea what the semantics of this situation
- * are so I don't even know if we've lost frames or which
- * ones.
- */
-   priv->last_picture = output.PicInfo.picture_number - 1;
-}
-
 copy_ret = copy_frame(avctx, , data, got_frame);
-if (*got_frame > 0) {
-priv->last_picture++;
-}
 } else {
 /*
  * An invalid frame has been consumed.
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 06/10] crystalhd: Remove h.264 parser

[Philip Langdale]

Now that we don't need to do ridiculous things to work out if a
frame is interlaced or not, we don't need an extra h.264 parser.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c | 55 --
 1 file changed, 4 insertions(+), 51 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 3db0e17..b68701a 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -83,7 +83,6 @@
 #include 
 
 #include "avcodec.h"
-#include "h264dec.h"
 #include "internal.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/intreadwrite.h"
@@ -112,7 +111,6 @@ typedef struct OpaqueList {
 struct OpaqueList *next;
 uint64_t fake_timestamp;
 uint64_t reordered_opaque;
-uint8_t pic_type;
 } OpaqueList;
 
 typedef struct {
@@ -125,7 +123,6 @@ typedef struct {
 uint32_t orig_extradata_size;
 
 AVBSFContext *bsfc;
-AVCodecParserContext *parser;
 
 uint8_t is_70012;
 uint8_t *sps_pps_buf;
@@ -221,8 +218,7 @@ static inline void print_frame_info(CHDContext *priv, 
BC_DTS_PROC_OUT *output)
  * OpaqueList functions
  /
 
-static uint64_t opaque_list_push(CHDContext *priv, uint64_t reordered_opaque,
- uint8_t pic_type)
+static uint64_t opaque_list_push(CHDContext *priv, uint64_t reordered_opaque)
 {
 OpaqueList *newNode = av_mallocz(sizeof (OpaqueList));
 if (!newNode) {
@@ -239,7 +235,6 @@ static uint64_t opaque_list_push(CHDContext *priv, uint64_t 
reordered_opaque,
 }
 priv->tail = newNode;
 newNode->reordered_opaque = reordered_opaque;
-newNode->pic_type = pic_type;
 
 return newNode->fake_timestamp;
 }
@@ -340,7 +335,6 @@ static av_cold int uninit(AVCodecContext *avctx)
 priv->orig_extradata_size = 0;
 }
 
-av_parser_close(priv->parser);
 if (priv->bsfc) {
 av_bsf_free(>bsfc);
 }
@@ -533,14 +527,6 @@ static av_cold int init(AVCodecContext *avctx)
 goto fail;
 }
 
-if (avctx->codec->id == AV_CODEC_ID_H264) {
-priv->parser = av_parser_init(avctx->codec->id);
-if (!priv->parser)
-av_log(avctx, AV_LOG_WARNING,
-   "Cannot open the h.264 parser! Interlaced h.264 content "
-   "will not be detected reliably.\n");
-priv->parser->flags = PARSER_FLAG_COMPLETE_FRAMES;
-}
 av_log(avctx, AV_LOG_VERBOSE, "CrystalHD: Init complete.\n");
 
 return 0;
@@ -561,7 +547,6 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 
 CHDContext *priv = avctx->priv_data;
 int64_t pkt_pts  = AV_NOPTS_VALUE;
-uint8_t pic_type = 0;
 
 uint8_t bottom_field = (output->PicInfo.flags & VDEC_FLAG_BOTTOMFIELD) ==
VDEC_FLAG_BOTTOMFIELD;
@@ -579,23 +564,18 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 OpaqueList *node = opaque_list_pop(priv, output->PicInfo.timeStamp);
 if (node) {
 pkt_pts = node->reordered_opaque;
-pic_type = node->pic_type;
 av_free(node);
 } else {
 /*
  * We will encounter a situation where a timestamp cannot be
  * popped if a second field is being returned. In this case,
  * each field has the same timestamp and the first one will
- * cause it to be popped. To keep subsequent calculations
- * simple, pic_type should be set a FIELD value - doesn't
- * matter which, but I chose BOTTOM.
+ * cause it to be popped. We'll avoid overwriting the valid
+ * timestamp below.
  */
-pic_type = PICT_BOTTOM_FIELD;
 }
 av_log(avctx, AV_LOG_VERBOSE, "output \"pts\": %"PRIu64"\n",
output->PicInfo.timeStamp);
-av_log(avctx, AV_LOG_VERBOSE, "output picture type %d\n",
-   pic_type);
 }
 
 ret = DtsGetDriverStatus(priv->dev, _status);
@@ -806,7 +786,6 @@ static int crystalhd_decode_packet(AVCodecContext *avctx, 
const AVPacket *avpkt)
 BC_STATUS bc_ret;
 CHDContext *priv   = avctx->priv_data;
 HANDLE dev = priv->dev;
-uint8_t pic_type   = 0;
 AVPacket filtered_packet = { 0 };
 int ret = 0;
 
@@ -859,32 +838,6 @@ static int crystalhd_decode_packet(AVCodecContext *avctx, 
const AVPacket *avpkt)
 av_packet_unref(_packet);
 }
 
-if (priv->parser) {
-uint8_t *pout;
-int psize;
-int index;
-H264Context *h = priv->parser->priv_data;
-
-index = av_parser_parse2(priv->parser, avctx, , ,
- avpkt->data, avpkt->size, avpkt->pts,
- avpkt->dts, 0);
-if (index < 0) {
-av_log(avctx, AV_LOG_WARNING,
-   "CrystalHD: Failed to parse h.264 

Re: [FFmpeg-devel] [PATCH 01/12] adxdec: validate sample_rate

[Andreas Cadhalpun]

On 26.10.2016 20:15, Paul B Mahol wrote:
> On 10/25/16, Michael Niedermayer  wrote:
>> On Tue, Oct 25, 2016 at 07:45:25PM +0200, Andreas Cadhalpun wrote:
>>> On 25.10.2016 12:58, Paul B Mahol wrote:
 patch(es)have good intent, but better fix is doing/checking it in single
 place.
>>>
>>> I don't agree.
>>> In general, validity checks should be where the values are actually read.
>>> This eliminates the risk that bogus values could cause problems between
>>> being set
>>> and being checked.
>>> Also, having only a check in a central place is bad for debugging, because
>>> it is
>>> not immediately clear where the bogus value came from, when the check is
>>> triggered.
>>> (I know this from personal experience debugging all the cases triggering
>>> the
>>> assert in av_rescale_rnd.)
>>>
>>> The problem with that approach is that such checks can easily be
>>> forgotten, which
>>> is why I think a check in a central place would make sense in addition to
>>> checking
>>> the individual cases.
>>
>> some formats may also lack a sample rate like mpeg ps/ts
>> the fact is known insude the demuxer, generic code after it doesnt
>> know. Doing the only check after the parser is a bit late OTOH
>>
>> [...]
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> What does censorship reveal? It reveals fear. -- Julian Assange
>>
> 
> I'm not (yet) aware of better "fix" so do as you like.

Have you seen the patch for checking this in a central place [1]?
It would catch all the negative sample rates, but not the negative
timescales.
(I still think it should be checked both centrally and locally.)

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201769.html

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

[FFmpeg-devel] [PATCH 2/4] hevc: Return stream format information from parser

[Mark Thompson]

---
 libavcodec/hevc_parser.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index d93586b..508f22f 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -312,6 +312,14 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 ps->vps = (HEVCVPS*)ps->vps_list[ps->sps->vps_id]->data;
 }

+s->coded_width  = ps->sps->width;
+s->coded_height = ps->sps->height;
+s->width= ps->sps->output_width;
+s->height   = ps->sps->output_height;
+s->format   = ps->sps->pix_fmt;
+avctx->profile  = ps->sps->ptl.general_ptl.profile_idc;
+avctx->level= ps->sps->ptl.general_ptl.level_idc;
+
 if (!sh->first_slice_in_pic_flag) {
 int slice_address_length;

-- 
2.7.4

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

[FFmpeg-devel] [PATCH 4/4] qsv: Merge libav implementation

[Mark Thompson]

Merged as-at libav 398f015, and therefore includes outstanding
skipped merges 04b17ff and 130e1f1.

All features not in libav are preserved, and no options change.
---
v3.

Changes from v2:
- Profile seems to be required by the decoder in some cases; always pass in the 
correct value.
- Fix parsing for MPEG-2; now works with streams which are not exactly 
macroblock-aligned.
- Fix H.265 parsing when the decoder is enabled.
- Add H.265 HW decode plugin ID for MSS 2017.


 libavcodec/qsv.c  | 333 ---
 libavcodec/qsv_internal.h |  38 ++--
 libavcodec/qsvdec.c   | 569 +++---
 libavcodec/qsvdec.h   |  30 +--
 libavcodec/qsvdec_h2645.c |  29 ++-
 libavcodec/qsvdec_mpeg2.c |  85 ++-
 libavcodec/qsvdec_vc1.c   |  89 +++-
 libavcodec/qsvenc.c   | 158 +++--
 libavcodec/qsvenc.h   |   6 +-
 libavcodec/qsvenc_h264.c  |   3 +-
 10 files changed, 744 insertions(+), 596 deletions(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 11d453d..efd7cea 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -25,7 +25,10 @@
 #include 

 #include "libavutil/avstring.h"
+#include "libavutil/common.h"
 #include "libavutil/error.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_qsv.h"

 #include "avcodec.h"
 #include "qsv_internal.h"
@@ -51,6 +54,22 @@ int ff_qsv_codec_id_to_mfx(enum AVCodecID codec_id)
 return AVERROR(ENOSYS);
 }

+int ff_qsv_profile_to_mfx(enum AVCodecID codec_id, int profile)
+{
+if (profile == FF_PROFILE_UNKNOWN)
+return MFX_PROFILE_UNKNOWN;
+switch (codec_id) {
+case AV_CODEC_ID_H264:
+case AV_CODEC_ID_HEVC:
+return profile;
+case AV_CODEC_ID_VC1:
+return 4 * profile + 1;
+case AV_CODEC_ID_MPEG2VIDEO:
+return 0x10 * profile;
+}
+return MFX_PROFILE_UNKNOWN;
+}
+
 int ff_qsv_error(int mfx_err)
 {
 switch (mfx_err) {
@@ -85,90 +104,58 @@ int ff_qsv_error(int mfx_err)
 return AVERROR_UNKNOWN;
 }
 }
-static int ff_qsv_set_display_handle(AVCodecContext *avctx, QSVSession *qs)
+
+static int qsv_load_plugins(mfxSession session, const char *load_plugins,
+void *logctx)
 {
-// this code is only required for Linux.  It searches for a valid
-// display handle.  First in /dev/dri/renderD then in /dev/dri/card
-#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
-// VAAPI display handle
-int ret = 0;
-VADisplay va_dpy = NULL;
-VAStatus va_res = VA_STATUS_SUCCESS;
-int major_version = 0, minor_version = 0;
-int fd = -1;
-char adapterpath[256];
-int adapter_num;
-
-qs->fd_display = -1;
-qs->va_display = NULL;
-
-//search for valid graphics device
-for (adapter_num = 0;adapter_num < 6;adapter_num++) {
-
-if (adapter_num<3) {
-snprintf(adapterpath,sizeof(adapterpath),
-"/dev/dri/renderD%d", adapter_num+128);
-} else {
-snprintf(adapterpath,sizeof(adapterpath),
-"/dev/dri/card%d", adapter_num-3);
-}
+if (!load_plugins || !*load_plugins)
+return 0;

-fd = open(adapterpath, O_RDWR);
-if (fd < 0) {
-av_log(avctx, AV_LOG_ERROR,
-"mfx init: %s fd open failed\n", adapterpath);
-continue;
-}
+while (*load_plugins) {
+mfxPluginUID uid;
+mfxStatus ret;
+int i, err = 0;

-va_dpy = vaGetDisplayDRM(fd);
-if (!va_dpy) {
-av_log(avctx, AV_LOG_ERROR,
-"mfx init: %s vaGetDisplayDRM failed\n", adapterpath);
-close(fd);
-continue;
+char *plugin = av_get_token(_plugins, ":");
+if (!plugin)
+return AVERROR(ENOMEM);
+if (strlen(plugin) != 2 * sizeof(uid.Data)) {
+av_log(logctx, AV_LOG_ERROR, "Invalid plugin UID length\n");
+err = AVERROR(EINVAL);
+goto load_plugin_fail;
 }

-va_res = vaInitialize(va_dpy, _version, _version);
-if (VA_STATUS_SUCCESS != va_res) {
-av_log(avctx, AV_LOG_ERROR,
-"mfx init: %s vaInitialize failed\n", adapterpath);
-close(fd);
-fd = -1;
-continue;
-} else {
-av_log(avctx, AV_LOG_VERBOSE,
-"mfx initialization: %s vaInitialize successful\n",adapterpath);
-qs->fd_display = fd;
-qs->va_display = va_dpy;
-ret = MFXVideoCORE_SetHandle(qs->session,
-  (mfxHandleType)MFX_HANDLE_VA_DISPLAY, (mfxHDL)va_dpy);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR,
-"Error %d during set display handle\n", ret);
-return ff_qsv_error(ret);
+for (i = 0; i < sizeof(uid.Data); i++) {
+err = sscanf(plugin + 2 * i, "%2hhx", uid.Data + i);
+if (err != 1) {
+av_log(logctx, 

[FFmpeg-devel] [PATCH 1/4] vc1: Return stream format information from parser

[Mark Thompson]

---
 libavcodec/vc1_parser.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/vc1_parser.c b/libavcodec/vc1_parser.c
index 9ca6154..bb54947 100644
--- a/libavcodec/vc1_parser.c
+++ b/libavcodec/vc1_parser.c
@@ -115,6 +115,14 @@ static void vc1_extract_header(AVCodecParserContext *s, 
AVCodecContext *avctx,
 }
 if (avctx->framerate.num)
 avctx->time_base = av_inv_q(av_mul_q(avctx->framerate, 
(AVRational){avctx->ticks_per_frame, 1}));
+s->format = vpc->v.chromaformat == 1 ? AV_PIX_FMT_YUV420P
+ : AV_PIX_FMT_NONE;
+if (avctx->width && avctx->height) {
+s->width= avctx->width;
+s->height   = avctx->height;
+s->coded_width  = FFALIGN(avctx->coded_width,  16);
+s->coded_height = FFALIGN(avctx->coded_height, 16);
+}
 }

 static int vc1_parse(AVCodecParserContext *s,
-- 
2.7.4

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

[FFmpeg-devel] [PATCH] lavf/mov.c: Set duration to zero if the duration is UINT_MAX

[Sasi Inguva]

Fixes some MP4F files which have duration in mdhd set to UINT_MAX instead of 
zero.

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 357d800..245e424 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1221,6 +1221,11 @@ static int mov_read_mdhd(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 sc->time_scale = avio_rb32(pb);
 st->duration = (version == 1) ? avio_rb64(pb) : avio_rb32(pb); /* duration 
*/
 
+if ((version == 1 && st->duration == UINT64_MAX) ||
+(version != 1 && st->duration == UINT32_MAX)) {
+st->duration = 0;
+}
+
 lang = avio_rb16(pb); /* language */
 if (ff_mov_lang_to_iso639(lang, language))
 av_dict_set(>metadata, "language", language, 0);
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Andreas Cadhalpun]

On 26.10.2016 10:52, Carl Eugen Hoyos wrote:
> 2016-10-26 1:16 GMT+02:00 Andreas Cadhalpun 
> :
>> I'm under the impression that __attribute__((used)) is not available
>> for all compilers,

> Yes, but __attribute__((foo_bar)) does not break compilation here.

Have you tested with MSVC?

> (But it is still a regression: 3.1 should not have seen the patch,
> it doesn't support new incompatible external libraries, and the
> issue was neither a regression nor security-related.)

This was not about a new external library, the support was added in 2015
(commit 99eabcd), and I think fixing build failures is quite sensible
for release branches.

On 26.10.2016 10:55, Carl Eugen Hoyos wrote:
> 2016-10-26 1:35 GMT+02:00 Andreas Cadhalpun 
> :
> 
>> I forgot to include stdint.h. Fixed patch attached.
> 
> Why don't you cast to (int)?

Because gcc doesn't like it:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

Best regards,
Andreas

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

Re: [FFmpeg-devel] [OPW] OPW Project Proposal

[Pallavi Kumari]

I mean deciding a timeline for the opw project. Which is to be mentioned in
application

On Wed, Oct 26, 2016 at 6:01 PM, Michael Niedermayer  wrote:

> Hi
>
> On Mon, Oct 17, 2016 at 02:06:26PM +0530, Pallavi Kumari wrote:
> > Hi Michael,
> >
> > I figured out the use of fft. Help me with the time line setting. Thanks
>
> I dont understand the question,
> if its about AVFILTER_FLAG_SUPPORT_TIMELINE*, please ignore this for
> now, its not needed
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mov.c: Use the first sidx for tracks without sidx.

[Sasi Inguva]

According to spec ISO_IEC_15444_12 "For any media stream for which no segment 
index is present, referred to as non‐indexed stream, the media stream 
associated with the first Segment Index box in the segment serves as a 
reference stream in a sense that it also describes the subsegments for any 
non‐indexed media stream."

Signed-off-by: Sasi Inguva 
---
 libavformat/isom.h |  1 +
 libavformat/mov.c  | 25 ++---
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 9038057..d684502 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -179,6 +179,7 @@ typedef struct MOVStreamContext {
 int32_t *display_matrix;
 uint32_t format;
 
+int has_sidx;  // If there is an sidx entry for this stream.
 struct {
 int use_subsamples;
 uint8_t* auxiliary_info;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 357d800..d9ed5a3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4202,7 +4202,8 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 uint8_t version;
 unsigned i, track_id;
 AVStream *st = NULL;
-MOVStreamContext *sc;
+AVStream *ref_st;
+MOVStreamContext *sc, *ref_sc;
 MOVFragmentIndex *index = NULL;
 MOVFragmentIndex **tmp;
 AVRational timescale;
@@ -4284,9 +4285,26 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 c->fragment_index_data = tmp;
 c->fragment_index_data[c->fragment_index_count++] = index;
+sc->has_sidx = 1;
+
+if (offset == avio_size(pb)) {
+for (i = 0; i < c->fc->nb_streams; i++) {
+if (c->fc->streams[i]->id == c->fragment_index_data[0]->track_id) {
+ref_st = c->fc->streams[i];
+ref_sc = ref_st->priv_data;
+break;
+}
+}
+for (i = 0; i < c->fc->nb_streams; i++) {
+st = c->fc->streams[i];
+sc = st->priv_data;
+if (!sc->has_sidx) {
+st->duration = sc->track_end = av_rescale(ref_st->duration, 
sc->time_scale, ref_sc->time_scale);
+}
+}
 
-if (offset == avio_size(pb))
 c->fragment_index_complete = 1;
+}
 
 return 0;
 }
@@ -5846,13 +5864,14 @@ static int mov_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 static int mov_seek_fragment(AVFormatContext *s, AVStream *st, int64_t 
timestamp)
 {
 MOVContext *mov = s->priv_data;
+MOVStreamContext *sc = st->priv_data;
 int i, j;
 
 if (!mov->fragment_index_complete)
 return 0;
 
 for (i = 0; i < mov->fragment_index_count; i++) {
-if (mov->fragment_index_data[i]->track_id == st->id) {
+if (mov->fragment_index_data[i]->track_id == st->id || !sc->has_sidx) {
 MOVFragmentIndex *index = mov->fragment_index_data[i];
 for (j = index->item_count - 1; j >= 0; j--) {
 if (index->items[j].time <= timestamp) {
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Use the first sidx for tracks without sidx.

[Sasi Inguva]

sorry. forgot to remove the debug printf. sending the corrected  patch.

On Wed, Oct 26, 2016 at 7:47 AM, Michael Niedermayer  wrote:

> On Tue, Oct 25, 2016 at 11:07:58PM -0700, Sasi Inguva wrote:
> > According to spec ISO_IEC_15444_12 "For any media stream for which no
> segment index is present, referred to as non‐indexed stream, the media
> stream associated with the first Segment Index box in the segment serves as
> a reference stream in a sense that it also describes the subsegments for
> any non‐indexed media stream."
> >
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/isom.h |  1 +
> >  libavformat/mov.c  | 26 +++---
> >  2 files changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/isom.h b/libavformat/isom.h
> > index 9038057..d684502 100644
> > --- a/libavformat/isom.h
> > +++ b/libavformat/isom.h
> > @@ -179,6 +179,7 @@ typedef struct MOVStreamContext {
> >  int32_t *display_matrix;
> >  uint32_t format;
> >
> > +int has_sidx;  // If there is an sidx entry for this stream.
> >  struct {
> >  int use_subsamples;
> >  uint8_t* auxiliary_info;
>
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 357d800..1b04b1a 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -4189,6 +4189,7 @@ static int mov_read_trun(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> >
> >  frag->implicit_offset = offset;
> >
> > +av_log(c, AV_LOG_DEBUG, "stindex: %d duration: %d end: %d\n",
> st->index, st->duration, sc->track_end);
>
> the types mismatch, also not sure this should be DEBUG or TRACE
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> When you are offended at any man's fault, turn to yourself and study your
> own failings. Then you will forget your anger. -- Epictetus
>
> ___
> 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 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[u-9iep]

On Wed, Oct 26, 2016 at 06:17:27PM +0200, wm4 wrote:
> > With all respect, I find such an argument hardly appropriate for two 
> > reasons:
> > it is formally incorrect (see below),
> > it shifts the attention from the functionality/usability to emotionally
> > charged aspects like age.
> 
> It's not an "emotionally charged" aspect. Phasing out old hardware is
> common sense. Of course this doesn't appeal to the "keep all the trash"

You do not seem to notice that you make the same mistake,
using emotionally charged expressions.

You are insulting the people who use older hardware, which is
_not_necessarily_ "trash" and who do this for their reasons - good or
bad is not in the realm of one's competence unless one is involved in
the actual case.

You the developers know everything between CPU, memory and I/O. The user
acts in her real world. For the developers it is unfounded to pretend
to be familiar with all the worlds out there.

If not otherwise, I mentioned the good reasons to run on the existing
hardware:

On Wed, Oct 26, 2016 at 06:04:24PM +0200, u-9...@aetey.se wrote:
> Such arguments can not be passed on to the users without an offer of
> a corresponding amount in cache. :)
> 
> More seriously, the act of replacement itself has its costs too, in
> cases like this one such cost is much higher than the cost of hardware.

To make it clear why I do not offer the expected spared money to the
developers, let me point out the phrase which may have gone unnoticed:

> (regrettably, this cost or gain is not trivial to convert to a
> compensation for the ffmpeg developers, unless video is one's main
> business, sorry for that!)
=>^^

I did my best to contribute some small bits of code and of understanding.

To conclude, I would like to friendly suggest to every bright
programmer on this list (sincerely highly respecting your skills),
try to notice when you tread outside your competence area.

Good luck to the ffmpeg project, my humble effort here is over.

Regards,
Rune

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

Re: [FFmpeg-devel] [PATCH 01/12] adxdec: validate sample_rate

[Paul B Mahol]

On 10/25/16, Michael Niedermayer  wrote:
> On Tue, Oct 25, 2016 at 07:45:25PM +0200, Andreas Cadhalpun wrote:
>> On 25.10.2016 12:58, Paul B Mahol wrote:
>> > patch(es)have good intent, but better fix is doing/checking it in single
>> > place.
>>
>> I don't agree.
>> In general, validity checks should be where the values are actually read.
>> This eliminates the risk that bogus values could cause problems between
>> being set
>> and being checked.
>> Also, having only a check in a central place is bad for debugging, because
>> it is
>> not immediately clear where the bogus value came from, when the check is
>> triggered.
>> (I know this from personal experience debugging all the cases triggering
>> the
>> assert in av_rescale_rnd.)
>>
>> The problem with that approach is that such checks can easily be
>> forgotten, which
>> is why I think a check in a central place would make sense in addition to
>> checking
>> the individual cases.
>
> some formats may also lack a sample rate like mpeg ps/ts
> the fact is known insude the demuxer, generic code after it doesnt
> know. Doing the only check after the parser is a bit late OTOH
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> What does censorship reveal? It reveals fear. -- Julian Assange
>

I'm not (yet) aware of better "fix" so do as you like.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: Fix off by 1 error

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 12:31:06AM +0200, Michael Niedermayer wrote:
> Fixes out of array read
> 
> Found-by: Thomas Garnier using libFuzzer
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvdsubdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH] avformat/utils: Discard huge timestamps which would cause overflows if used in basic computations

[Michael Niedermayer]

On Sun, Sep 25, 2016 at 11:54:00PM +0200, Michael Niedermayer wrote:
> Allowing larger timestamps makes it impossible to calculate basic things like 
> the
> difference of 2 timestamps or their sum without checking each individual 
> computation for
> overflow.
> This should avoid a significant number of overflow checks
> 
> Fixes Ticket5136
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c | 6 ++
>  1 file changed, 6 insertions(+)

applied

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH] avformat/isom: Fix old API regression with exporting max bitrate

[Michael Niedermayer]

On Mon, Oct 10, 2016 at 02:36:37AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/isom.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

applied

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

No snowflake in an avalanche ever feels responsible. -- 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] removing comma at final enumeration items to fix pedantic warnings

[Clément Bœsch]

On Fri, Oct 21, 2016 at 10:32:58AM +0200, Michael Behrisch wrote:
> Am 20.10.2016 um 10:00 schrieb Clément Bœsch:
> > On Thu, Oct 20, 2016 at 09:55:17AM +0200, Nicolas George wrote:
> >> Le nonidi 29 vendémiaire, an CCXXV, Clement Boesch a écrit :
> >>> it's really a trivial and harmless patch.
> >>
> >> Which is not enough to accept it.
> >>
> > 
> > but the patch is perfectly fine and semantically more correct (it
> > explicits that it's wrong to add entry afterward).
> > 
> >> I am sure there are better uses of contributors' time than that.
> >>
> > 
> > people are free to do whatever they feel like; you're just wasting yours
> > by bikeshedding about this stuff you could just ignore.
> > 
> 
> So here is the patch again, this time without the line breaks, hopefully.
> 
> Best regards,
> Michael
> 

> Date: Thu, 20 Oct 2016 08:48:25 +0200
> From: Michael Behrisch 
> To: ffmpeg-devel@ffmpeg.org
> Cc: Michael Behrisch 
> Subject: [PATCH] removing comma at final enumeration items to fix pedantic
>  warnings
> X-Mailer: git-send-email 2.6.6
> 

Reworded the commit message and applied.

thanks

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/patchwork: Document the patchwork states

[Michael Niedermayer]

On Sat, Oct 22, 2016 at 09:20:20PM +0200, Michael Niedermayer wrote:
> On Sat, Oct 22, 2016 at 10:41:29AM -0800, Lou Logan wrote:
> > On Sat, Oct 22, 2016, at 09:49 AM, Bodecs Bela wrote:
> > >
> > > under review: someone marked it because he/she investigate this patch. 
> > > So the patch submitter and other potential reviewers may feel/be_sure 
> > > that this patch is already handled by someone else.
> > > I suggest to use it. This is psychologic aspect that the patch submitter 
> > > may feel more patienty toward review process opposite to mere "new"
> > > state.
> > 
> > In my opinion that seems like unnecessary extra work. All patches in
> > theory are to be "under review". Reviewing takes enough time,
> > initiative, and motivation as is, and adding another, potentially
> > superfluous step just over complicates it.
> > 
> > Perhaps "Under Review" can just be removed, disabled, hidden, or
> > documented as "this option is ignored". Same with "Deferred" and
> > "Awaiting Upstream".
> 
> Removed "Under Review" and "Awaiting Upstream"
> Theres a patch with "Deferred" state, this would need to be changed
> first

patch applied


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] FFmpeg 3.2

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 05:07:44PM +0200, Carl Eugen Hoyos wrote:
> 2016-10-26 1:32 GMT+02:00 Michael Niedermayer :
> > On Wed, Sep 28, 2016 at 05:11:23PM +0200, Carl Eugen Hoyos wrote:
> >> 2016-09-27 15:30 GMT+02:00 Michael Niedermayer :
> >>
> >> > Its long since FFmpeg 3.1, so its time to make 3.2
> >>
> >> The configure option --enable-incompatible-libav-abi was intentionally
> >> broken some time ago, if it cannot get removed it should at least be
> >> removed from the help output.
> >
> > feel free to remove it, i dont have any references at hand to explain
> > it in the commit message
> 
> 655b6dcb, I had not remembered your review...

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

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[wm4]

On Wed, 26 Oct 2016 18:04:24 +0200
u-9...@aetey.se wrote:

> On Wed, Oct 26, 2016 at 05:08:56PM +0200, Hendrik Leppkes wrote:
> > > One of the highly appreciated virtues of ffmpeg is its efficiency,
> > > this makes hardware much more useful. Please do not cut off the low
> > > end systems when possible.  
> 
> > Its not about low-end, its about 15+ years old hardware. At some point  
> 
> With all respect, I find such an argument hardly appropriate for two reasons:
> it is formally incorrect (see below),
> it shifts the attention from the functionality/usability to emotionally
> charged aspects like age.

It's not an "emotionally charged" aspect. Phasing out old hardware is
common sense. Of course this doesn't appeal to the "keep all the trash"
crowd, which for some reason seems to be going strong in FFmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Ronald S. Bultje]

Hi,

On Wed, Oct 26, 2016 at 12:04 PM,  wrote:

> On Wed, Oct 26, 2016 at 05:08:56PM +0200, Hendrik Leppkes wrote:
> > you just have to replace this stuff.
> > For $100 you can buy a system at least 10 times as fast then those.
> > Heck even a RPi might rival those for $20 or so.
>
> Such arguments can not be passed on to the users without an offer of
> a corresponding amount in cache. :)


Will you pay us for code maintenance?

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

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[u-9iep]

On Wed, Oct 26, 2016 at 05:08:56PM +0200, Hendrik Leppkes wrote:
> > One of the highly appreciated virtues of ffmpeg is its efficiency,
> > this makes hardware much more useful. Please do not cut off the low
> > end systems when possible.

> Its not about low-end, its about 15+ years old hardware. At some point

With all respect, I find such an argument hardly appropriate for two reasons:
it is formally incorrect (see below),
it shifts the attention from the functionality/usability to emotionally
charged aspects like age.

I am participating in the discussion as a concerned _packager_.
Nevertheless I am a ffmpeg "user" too.

As a matter of fact I am running several low power units which have mmx but no 
sse.
Several of them exist for handling video, either for playback or encoding or 
both.

They have been set up this way because they fit the bill very nicely,
among others thanks to ffmpeg.

The one I looked at recently is manufactured 10 years ago and is not
youngest in its generation. So we have to wait at least extra 5 years
to make it 15+.

> you just have to replace this stuff.
> For $100 you can buy a system at least 10 times as fast then those.
> Heck even a RPi might rival those for $20 or so.

Such arguments can not be passed on to the users without an offer of
a corresponding amount in cache. :)

More seriously, the act of replacement itself has its costs too, in
cases like this one such cost is much higher than the cost of hardware.

(regrettably, this cost or gain is not trivial to convert to a
compensation for the ffmpeg developers, unless video is one's main
business, sorry for that!)

Regards,
Rune

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

Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 06:38:12PM -0600, Roger Pack wrote:
> On 10/25/16, Michael Niedermayer  wrote:
> > On Mon, Oct 24, 2016 at 03:20:14PM -0600, Roger Pack wrote:
> >> On 10/16/16, Michael Niedermayer  wrote:
> >> > On Mon, Oct 10, 2016 at 02:56:24PM -0600, Roger Pack wrote:
> >> >> On 9/22/16, Roger Pack  wrote:
> >> >> > On 1/4/12, Yuval Adam  wrote:
> >> >> >> From: Yuval Adam 
> >> >> >>
> >> >> >> The image2 muxer now supports timestamps in output filenames.
> >> >> >> When used in an output patterm '%t' will be replaced with the
> >> >> >> frames
> >> >> >> timestamp in hours, minutes and seconds (hh:mm:ss).
> >> >> >
> >> >> > A somewhat updated (but not yet cleaned up) revision:
> >> >> >
> >> >> > https://gist.github.com/rdp/e518616f2a702367ae5a922b56e09e04
> >> >> >
> >> >> > see also https://trac.ffmpeg.org/ticket/1452
> >> >>
> >> >> OK attached is the "cleaned up" patch, ready for review/commit.
> >> >>
> >> >> how to test:
> >> >> (apply then) run this:
> >> >>
> >> >> ./ffmpeg -i input -copyts -vsync vfr temp/abc-%d-%t.jpeg
> >> >> and compare filenames with the timestamps from video packets of
> >> >> ffprobe -show_packets.
> >> >>
> >> >> Probably a better way would have been to mix it into
> >> >> av_bprint_strftime however I wasn't sure how to use that within
> >> >> libavformat/utils.c av_get_frame_filename2
> >> >>
> >> >> Adam's initial patch
> >> >> (https://github.com/yuvadm/FFmpeg/commit/0eb002821a2076cb3593c823399aeef9fdd29525)
> >> >> also deprecated av_get_frame_filename
> >> >>
> >> >> but I wasn't sure if we wanted that here or not so didn't include it.
> >> >> Thank you for your consideration.
> >> >> -roger-
> >> >
> >> >>  doc/muxers.texi|   19 ---
> >> >>  libavformat/avformat.h |3 ++-
> >> >>  libavformat/hlsenc.c   |6 +++---
> >> >>  libavformat/img2enc.c  |7 +--
> >> >>  libavformat/utils.c|   36 
> >> >>  5 files changed, 58 insertions(+), 13 deletions(-)
> >> >> 06950fc8ba5a9163ffb838a2bff9933e69255b41
> >> >> 0001-img2-encoder-allow-t-in-filename-based-on-patch-from.patch
> >> >> From 11deddfacc595c43a4f542fffe5e90b142e39c85 Mon Sep 17 00:00:00 2001
> >> >> From: rogerdpack 
> >> >> Date: Mon, 10 Oct 2016 14:50:20 -0600
> >> >> Subject: [PATCH] img2 encoder: allow %t in filename, based on patch
> >> >> from
> >> >> Yuval
> >> >>  Adam
> >> >>
> >> >> Signed-off-by: rogerdpack 
> >> >> ---
> >> >>  doc/muxers.texi| 19 ---
> >> >>  libavformat/avformat.h |  3 ++-
> >> >>  libavformat/hlsenc.c   |  6 +++---
> >> >>  libavformat/img2enc.c  |  7 +--
> >> >>  libavformat/utils.c| 36 
> >> >>  5 files changed, 58 insertions(+), 13 deletions(-)
> >> >>
> >> >> diff --git a/doc/muxers.texi b/doc/muxers.texi
> >> >> index 9ec2e31..6fff966 100644
> >> >> --- a/doc/muxers.texi
> >> >> +++ b/doc/muxers.texi
> >> >> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
> >> >> first filename of
> >> >>  the file list specified will contain the number 1, all the following
> >> >>  numbers will be sequential.
> >> >>
> >> >> +If the pattern contains "%t", the frame's timestamps will be inserted
> >> >> +in the filename like "00.00.00.000" for hours, minutes, seconds,
> >> >> +and milliseconds.
> >> >> +
> >> >> +The "%t" and "%d" patterns may be used simultaneously.
> >> >> +
> >> >>  The pattern may contain a suffix which is used to automatically
> >> >>  determine the format of the image files to write.
> >> >>
> >> >> @@ -635,7 +641,7 @@ The following example shows how to use
> >> >> @command{ffmpeg} for creating a
> >> >>  sequence of files @file{img-001.jpeg}, @file{img-002.jpeg}, ...,
> >> >>  taking one image every second from the input video:
> >> >>  @example
> >> >> -ffmpeg -i in.avi -vsync 1 -r 1 -f image2 'img-%03d.jpeg'
> >> >> +ffmpeg -i in.avi -vsync cfr -r 1 -f image2 'img-%03d.jpeg'
> >> >>  @end example
> >> >>
> >> >>  Note that with @command{ffmpeg}, if the format is not specified with
> >> >> the
> >> >> @@ -643,12 +649,12 @@ Note that with @command{ffmpeg}, if the format
> >> >> is
> >> >> not specified with the
> >> >>  format, the image2 muxer is automatically selected, so the previous
> >> >>  command can be written as:
> >> >>  @example
> >> >> -ffmpeg -i in.avi -vsync 1 -r 1 'img-%03d.jpeg'
> >> >> +ffmpeg -i in.avi -vsync cfr -r 1 'img-%03d.jpeg'
> >> >>  @end example
> >> >>
> >> >>  Note also that the pattern must not necessarily contain "%d" or
> >> >>  "%0@var{N}d", for example to create a single image file
> >> >> -@file{img.jpeg} from the input video you can employ the command:
> >> >> +@file{img.jpeg} from the start of the input video you can employ the
> >> >> command:
> >> >>  @example
> >> >>  ffmpeg -i in.avi -f image2 

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 04:21:14PM +0200, Hendrik Leppkes wrote:
> On Wed, Oct 26, 2016 at 3:54 PM, Michael Niedermayer
>  wrote:
> > On Tue, Oct 25, 2016 at 12:00:01AM +0200, Hendrik Leppkes wrote:
> >> On Mon, Oct 24, 2016 at 10:31 PM, Ronald S. Bultje  
> >> wrote:
> >> > Hi,
> >> >
> >> > On Mon, Oct 24, 2016 at 4:26 PM, Henrik Gramner  
> >> > wrote:
> >> >
> >> >> On Mon, Oct 24, 2016 at 9:59 PM, Ronald S. Bultje 
> >> >> wrote:
> >> >> > Good idea to reference Hendrik Gramner here, who keeps insisting we 
> >> >> > get
> >> >> rid
> >> >> > of all MMX code in ffmpeg (at least as an option) for future Intel 
> >> >> > CPUs
> >> >> in
> >> >> > which MMX will be deprecated.
> >> >>
> >> >> Replacing MMX with SSE2 is indeed the most "proper" fix in my opinion,
> >> >> but it's a fair amount of work and not done in an evening.
> >> >>
> >> >> The fact that a lot of assembly lacks unit tests is certainly not
> >> >> helping in that regard.
> >> >>
> >> >> Some MMX instructions are slower than the equivalent SSE2 code on
> >> >> Skylake. Intel hasn't officially commented on (as far as I know at
> >> >> least) if we should expect this trend to continue, but they certainly
> >> >> seem to treat MMX as legacy.
> >> >>
> >> >> I doubt they would completely remove support for it though, backwards
> >> >> compatibility is a big selling-point for x86.
> >> >
> >> >
> >> > Well, it gives us another way of fixing this issue (on x86-64 only): have
> >> > sse2 implementations for all code that has a mmx (register) path right 
> >> > now.
> >> >
> >>
> >> I don't think the argument for pre-sse2 CPUs is that strong on 32-bit
> >> systems, either.
> >
> > SSE2 was initially not faster than MMX as CPUs implemented it as 2
> > MMX operations internally not having a full width SIMD unit for SSE*
> > so there would be a performace loss on some x86-32 CPUs if MMX was
> > replaced by "half-width SSE2" there
> >
> 
> You can add "not caring about first-gen sse2 CPUs" to the list as

its more like 3 or 4 generations than 1 according to the instruction
tables from Agner Fog

core 2 (Merom) seems the first that has partial full width support
shift/pack/unpack/shuffle still are faster as MMX
PM, P4, P4E all seem half speed at SSE* than MMX


> well, if you want. Those are way old as well.


> There is going to be a performance loss either way, except that emms
> slows it down everywhere, while using sse2 is likely to be fine on

minor detail being that there is a factor of around
ten thousand in the speed loss between the 2 cases you compare
(0.001% vs maybe 50%)

Droping MMX will cause pre SSE2 CPUs to be alot slower, maybe half
speed overall or less, they loose all SIMD optimizations. On older
SSE2 cpus its still going to be a hefty hit too.
adding emms at a video frame or slice level which is what the patches
posted do pretty much has no real effect but dont belive me look at the
timings worst case i see in agners tables are 18 clock cycles that at
60fps and 1slice and a slow 100mhz cpu is 0.001%
even if there are 100 times more emms (due to slice level EMMS) it
still at the edge of being
hard to meassure. Doing EMMS per function call is of course not
prcatical.

theres an additional penalty for the first float instruction after emms
on some cpus, 58 clock cycles (on P4) but thats still just 0.003% in the
example above.

anyway, i wantd to stay out of this and ill do that, just wanted to
comment on the technical details

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Hendrik Leppkes]

On Wed, Oct 26, 2016 at 4:52 PM,   wrote:
> On Wed, Oct 26, 2016 at 04:21:14PM +0200, Hendrik Leppkes wrote:
>> You can add "not caring about first-gen sse2 CPUs" to the list as
>> well, if you want. Those are way old as well.
>> There is going to be a performance loss either way, except that emms
>> slows it down everywhere, while using sse2 is likely to be fine on
>> modern CPUs. So IMHO thats the better course to take, if any.
>
> Note that making MMX-acceleration unavailable would hurt at most on
> those slowest, non-sse systems, which otherwise e.g. often struggle for
> real-time decoding of heavier streams.
>
> One of the highly appreciated virtues of ffmpeg is its efficiency,
> this makes hardware much more useful. Please do not cut off the low
> end systems when possible.
>

Its not about low-end, its about 15+ years old hardware. At some point
you just have to replace this stuff.
For $100 you can buy a system at least 10 times as fast then those.
Heck even a RPi might rival those for $20 or so.

If you want to convince developers to fix the MMX situation properly,
which would cost a lot of time to do, then the best course is to look
forward, which the SSE2 option imho is doing.
All other options are just band-aids.

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

Re: [FFmpeg-devel] FFmpeg 3.2

[Carl Eugen Hoyos]

2016-10-26 1:32 GMT+02:00 Michael Niedermayer :
> On Wed, Sep 28, 2016 at 05:11:23PM +0200, Carl Eugen Hoyos wrote:
>> 2016-09-27 15:30 GMT+02:00 Michael Niedermayer :
>>
>> > Its long since FFmpeg 3.1, so its time to make 3.2
>>
>> The configure option --enable-incompatible-libav-abi was intentionally
>> broken some time ago, if it cannot get removed it should at least be
>> removed from the help output.
>
> feel free to remove it, i dont have any references at hand to explain
> it in the commit message

655b6dcb, I had not remembered your review...

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

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[u-9iep]

On Wed, Oct 26, 2016 at 04:21:14PM +0200, Hendrik Leppkes wrote:
> You can add "not caring about first-gen sse2 CPUs" to the list as
> well, if you want. Those are way old as well.
> There is going to be a performance loss either way, except that emms
> slows it down everywhere, while using sse2 is likely to be fine on
> modern CPUs. So IMHO thats the better course to take, if any.

Note that making MMX-acceleration unavailable would hurt at most on
those slowest, non-sse systems, which otherwise e.g. often struggle for
real-time decoding of heavier streams.

One of the highly appreciated virtues of ffmpeg is its efficiency,
this makes hardware much more useful. Please do not cut off the low
end systems when possible.

Regards,
Rune

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Use the first sidx for tracks without sidx.

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 11:07:58PM -0700, Sasi Inguva wrote:
> According to spec ISO_IEC_15444_12 "For any media stream for which no segment 
> index is present, referred to as non‐indexed stream, the media stream 
> associated with the first Segment Index box in the segment serves as a 
> reference stream in a sense that it also describes the subsegments for any 
> non‐indexed media stream."
> 
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/isom.h |  1 +
>  libavformat/mov.c  | 26 +++---
>  2 files changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 9038057..d684502 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -179,6 +179,7 @@ typedef struct MOVStreamContext {
>  int32_t *display_matrix;
>  uint32_t format;
>  
> +int has_sidx;  // If there is an sidx entry for this stream.
>  struct {
>  int use_subsamples;
>  uint8_t* auxiliary_info;

> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 357d800..1b04b1a 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4189,6 +4189,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  
>  frag->implicit_offset = offset;
>  
> +av_log(c, AV_LOG_DEBUG, "stindex: %d duration: %d end: %d\n", st->index, 
> st->duration, sc->track_end);

the types mismatch, also not sure this should be DEBUG or TRACE

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] lavfi/vf_overlay: support NV12 and NV21

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 09:58:43PM -0500, Rodger Combs wrote:
> ---
>  libavfilter/vf_overlay.c| 22 +-
>  tests/fate/filter-video.mak | 10 ++
>  tests/filtergraphs/overlay_nv12 |  5 +
>  tests/filtergraphs/overlay_nv21 |  5 +
>  4 files changed, 37 insertions(+), 5 deletions(-)
>  create mode 100644 tests/filtergraphs/overlay_nv12
>  create mode 100644 tests/filtergraphs/overlay_nv21

Tested-by: Michael on x86-32/64 linux, mingw, mips/arm qemu linux

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Hendrik Leppkes]

On Wed, Oct 26, 2016 at 3:54 PM, Michael Niedermayer
 wrote:
> On Tue, Oct 25, 2016 at 12:00:01AM +0200, Hendrik Leppkes wrote:
>> On Mon, Oct 24, 2016 at 10:31 PM, Ronald S. Bultje  
>> wrote:
>> > Hi,
>> >
>> > On Mon, Oct 24, 2016 at 4:26 PM, Henrik Gramner  wrote:
>> >
>> >> On Mon, Oct 24, 2016 at 9:59 PM, Ronald S. Bultje 
>> >> wrote:
>> >> > Good idea to reference Hendrik Gramner here, who keeps insisting we get
>> >> rid
>> >> > of all MMX code in ffmpeg (at least as an option) for future Intel CPUs
>> >> in
>> >> > which MMX will be deprecated.
>> >>
>> >> Replacing MMX with SSE2 is indeed the most "proper" fix in my opinion,
>> >> but it's a fair amount of work and not done in an evening.
>> >>
>> >> The fact that a lot of assembly lacks unit tests is certainly not
>> >> helping in that regard.
>> >>
>> >> Some MMX instructions are slower than the equivalent SSE2 code on
>> >> Skylake. Intel hasn't officially commented on (as far as I know at
>> >> least) if we should expect this trend to continue, but they certainly
>> >> seem to treat MMX as legacy.
>> >>
>> >> I doubt they would completely remove support for it though, backwards
>> >> compatibility is a big selling-point for x86.
>> >
>> >
>> > Well, it gives us another way of fixing this issue (on x86-64 only): have
>> > sse2 implementations for all code that has a mmx (register) path right now.
>> >
>>
>> I don't think the argument for pre-sse2 CPUs is that strong on 32-bit
>> systems, either.
>
> SSE2 was initially not faster than MMX as CPUs implemented it as 2
> MMX operations internally not having a full width SIMD unit for SSE*
> so there would be a performace loss on some x86-32 CPUs if MMX was
> replaced by "half-width SSE2" there
>

You can add "not caring about first-gen sse2 CPUs" to the list as
well, if you want. Those are way old as well.
There is going to be a performance loss either way, except that emms
slows it down everywhere, while using sse2 is likely to be fine on
modern CPUs. So IMHO thats the better course to take, if any.

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

Re: [FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 12:00:01AM +0200, Hendrik Leppkes wrote:
> On Mon, Oct 24, 2016 at 10:31 PM, Ronald S. Bultje  wrote:
> > Hi,
> >
> > On Mon, Oct 24, 2016 at 4:26 PM, Henrik Gramner  wrote:
> >
> >> On Mon, Oct 24, 2016 at 9:59 PM, Ronald S. Bultje 
> >> wrote:
> >> > Good idea to reference Hendrik Gramner here, who keeps insisting we get
> >> rid
> >> > of all MMX code in ffmpeg (at least as an option) for future Intel CPUs
> >> in
> >> > which MMX will be deprecated.
> >>
> >> Replacing MMX with SSE2 is indeed the most "proper" fix in my opinion,
> >> but it's a fair amount of work and not done in an evening.
> >>
> >> The fact that a lot of assembly lacks unit tests is certainly not
> >> helping in that regard.
> >>
> >> Some MMX instructions are slower than the equivalent SSE2 code on
> >> Skylake. Intel hasn't officially commented on (as far as I know at
> >> least) if we should expect this trend to continue, but they certainly
> >> seem to treat MMX as legacy.
> >>
> >> I doubt they would completely remove support for it though, backwards
> >> compatibility is a big selling-point for x86.
> >
> >
> > Well, it gives us another way of fixing this issue (on x86-64 only): have
> > sse2 implementations for all code that has a mmx (register) path right now.
> >
> 
> I don't think the argument for pre-sse2 CPUs is that strong on 32-bit
> systems, either.

SSE2 was initially not faster than MMX as CPUs implemented it as 2
MMX operations internally not having a full width SIMD unit for SSE*
so there would be a performace loss on some x86-32 CPUs if MMX was
replaced by "half-width SSE2" there

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH] libavcodec/tests: Added test for libavcodec/avpacket.c

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 03:03:07PM +0200, wm4 wrote:
> On Wed, 26 Oct 2016 14:56:01 +0200
> Michael Niedermayer  wrote:
> 
> > On Wed, Oct 26, 2016 at 02:00:46PM +0200, wm4 wrote:
> > > On Sat, 22 Oct 2016 23:40:42 -0700
> > > Thomas Turner  wrote:
> > >   
> > > > Function(s) Tested: av_packet_clone().
> > > > 
> > > > This test checks if av_packet_clone() can successfully make a copy of 
> > > > an AVPacket.
> > > > Compares all data members in AVPacket EXCEPT for "buf" because "buf" is 
> > > > initialized
> > > > to NIL in the original AVPacket [to be cloned].
> > > > 
> > > > This test also prints out the all the contents of the original and 
> > > > cloned AVPackets.
> > > > 
> > > > Signed-off-by: Thomas Turner 
> > > > ---  
> > > 
> > > Am I the only one who thinks this test is overly complex and worthless?
> > > (Checks if each field got copied... come on, that's not useful. And
> > > would probably bitrot quickly as nobody would add new fields to the
> > > test anyway.)  
> > 
> > what do you suggest, how to test it ?
> > or should we deprecate av_packet_clone()
> > nothing uses it, so the total lack of tests and uses means noone
> > would notice (quickly) if it broke ever
> > 
> > [...]
> 
> I don't think it's the choice between either adding a test
> for av_packet_clone or deprecating it?

Its desirable to have code tested to identify problems, code thats
not tested at all bit rots eventually. The issue is propotional to
the complexity of the code and how activly it changes so the risk is
low with av_packet_clone() but still


> 
> Also, av_packet_clone is 100% implemented using public functions and
> doesn't access any AVPacket fields itself.

yes but these public functions themselfs arent tested for completness
either.

iam not arguing for a specific way of testing this, but that some
clean test would be desirable


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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] libavcodec/tests: Added test for libavcodec/avpacket.c

[wm4]

On Wed, 26 Oct 2016 14:56:01 +0200
Michael Niedermayer  wrote:

> On Wed, Oct 26, 2016 at 02:00:46PM +0200, wm4 wrote:
> > On Sat, 22 Oct 2016 23:40:42 -0700
> > Thomas Turner  wrote:
> >   
> > > Function(s) Tested: av_packet_clone().
> > > 
> > > This test checks if av_packet_clone() can successfully make a copy of an 
> > > AVPacket.
> > > Compares all data members in AVPacket EXCEPT for "buf" because "buf" is 
> > > initialized
> > > to NIL in the original AVPacket [to be cloned].
> > > 
> > > This test also prints out the all the contents of the original and cloned 
> > > AVPackets.
> > > 
> > > Signed-off-by: Thomas Turner 
> > > ---  
> > 
> > Am I the only one who thinks this test is overly complex and worthless?
> > (Checks if each field got copied... come on, that's not useful. And
> > would probably bitrot quickly as nobody would add new fields to the
> > test anyway.)  
> 
> what do you suggest, how to test it ?
> or should we deprecate av_packet_clone()
> nothing uses it, so the total lack of tests and uses means noone
> would notice (quickly) if it broke ever
> 
> [...]

I don't think it's the choice between either adding a test
for av_packet_clone or deprecating it?

Also, av_packet_clone is 100% implemented using public functions and
doesn't access any AVPacket fields itself.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/tests: Added test for libavcodec/avpacket.c

[Michael Niedermayer]

On Wed, Oct 26, 2016 at 02:00:46PM +0200, wm4 wrote:
> On Sat, 22 Oct 2016 23:40:42 -0700
> Thomas Turner  wrote:
> 
> > Function(s) Tested: av_packet_clone().
> > 
> > This test checks if av_packet_clone() can successfully make a copy of an 
> > AVPacket.
> > Compares all data members in AVPacket EXCEPT for "buf" because "buf" is 
> > initialized
> > to NIL in the original AVPacket [to be cloned].
> > 
> > This test also prints out the all the contents of the original and cloned 
> > AVPackets.
> > 
> > Signed-off-by: Thomas Turner 
> > ---
> 
> Am I the only one who thinks this test is overly complex and worthless?
> (Checks if each field got copied... come on, that's not useful. And
> would probably bitrot quickly as nobody would add new fields to the
> test anyway.)

what do you suggest, how to test it ?
or should we deprecate av_packet_clone()
nothing uses it, so the total lack of tests and uses means noone
would notice (quickly) if it broke ever

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [OPW] OPW Project Proposal

[Michael Niedermayer]

Hi

On Mon, Oct 17, 2016 at 02:06:26PM +0530, Pallavi Kumari wrote:
> Hi Michael,
> 
> I figured out the use of fft. Help me with the time line setting. Thanks

I dont understand the question,
if its about AVFILTER_FLAG_SUPPORT_TIMELINE*, please ignore this for
now, its not needed

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] libavcodec/tests: Added test for libavcodec/avpacket.c

[wm4]

On Sat, 22 Oct 2016 23:40:42 -0700
Thomas Turner  wrote:

> Function(s) Tested: av_packet_clone().
> 
> This test checks if av_packet_clone() can successfully make a copy of an 
> AVPacket.
> Compares all data members in AVPacket EXCEPT for "buf" because "buf" is 
> initialized
> to NIL in the original AVPacket [to be cloned].
> 
> This test also prints out the all the contents of the original and cloned 
> AVPackets.
> 
> Signed-off-by: Thomas Turner 
> ---

Am I the only one who thinks this test is overly complex and worthless?
(Checks if each field got copied... come on, that's not useful. And
would probably bitrot quickly as nobody would add new fields to the
test anyway.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[wm4]

On Wed, 26 Oct 2016 01:46:35 +0200
Michael Niedermayer  wrote:

> On Tue, Oct 25, 2016 at 05:07:34PM +0200, Stefano Sabatini wrote:
> > On date Tuesday 2016-10-18 16:06:47 +0200, Michael Niedermayer encoded:  
> > > On Tue, Oct 18, 2016 at 01:33:27PM +0200, Stefano Sabatini wrote:  
> > > > On date Thursday 2016-10-13 19:46:41 +0200, Stefano Sabatini encoded:  
> > > > > On date Thursday 2016-09-29 21:55:11 +0200, wm4 encoded:  
> > > > [...]  
> > > > > > This seems like a rather special use case. Why does it have a 
> > > > > > demuxer,
> > > > > > and can't be in your own C code using libavcodec/libavformat?
> > > > > >   
> > > > >   
> > > > > > In addition, I think using the ffprobe "format" is an 
> > > > > > overcomplication,
> > > > > > and will justify adding even more stuff to the demuxer, until it's a
> > > > > > similarily complex mess like the ffm demuxer/muxer.  
> > > > > 
> > > > > I'm aware of the issue. OTOH I think the feature per-se is useful, at
> > > > > least for the two mentioned use cases (debugging - especially if
> > > > > coupled with a corresponding muxer), and data streams (generated by
> > > > > script) injection, since it relies on a textual format easily
> > > > > scriptable and editable by hand.
> > > > > 
> > > > > I thus leave the choice to the community. I guess this will require a
> > > > > vote if we cannot find an agreement.
> > > > > 
> > > > > Latest patch in attachment with ffprobe demuxer disabled by default,
> > > > > and extended documentation. (I'm also attaching the ff_get_line2 patch
> > > > > which is used by this new patch).  
> > > > 
> > > > Updated, depends on the ff_get_line2() patch.
> > > > -- 
> > > > FFmpeg = Fanciful and Fundamentalist Magnificient Ponderous Elastic 
> > > > Game  
> > >   
> > > >  configure|3 
> > > >  doc/demuxers.texi|   18 ++
> > > >  doc/ffprobe-format.texi  |  121 ++
> > > >  doc/formats.texi |1 
> > > >  libavformat/Makefile |1 
> > > >  libavformat/allformats.c |1 
> > > >  libavformat/ffprobedec.c |  405 
> > > > +++
> > > >  7 files changed, 550 insertions(+)
> > > > 1d8a987564e907802dfd84722e3f5aafa69919ee  
> > > > 0002-lavf-add-ffprobe-demuxer.patch
> > > > From bef4930a2bf280425b5952de0e2281f03897ff7c Mon Sep 17 00:00:00 2001
> > > > From: Nicolas George 
> > > > Date: Sat, 11 Jan 2014 19:42:41 +0100
> > > > Subject: [PATCH] lavf: add ffprobe demuxer
> > > > 
> > > > With several modifications and documentation by Stefano Sabatini
> > > > .
> > > > 
> > > > Signed-off-by: Nicolas George 
> > > > ---  
> > > [...]  
> > > > +static int read_section_packet(AVFormatContext *avf, AVPacket *pkt)
> > > > +{
> > > > +FFprobeContext *ffp = avf->priv_data;
> > > > +uint8_t buf[4096];
> > > > +int ret;
> > > > +AVPacket p;
> > > > +char flags;
> > > > +
> > > > +av_init_packet();
> > > > +p.pos = avio_tell(avf->pb);
> > > > +p.stream_index = -1;
> > > > +p.size = -1;
> > > > +av_bprint_clear(>data);
> > > > +while ((ret = read_section_line(avf, buf, sizeof(buf {
> > > > +int has_time = 0;
> > > > +int64_t pts, dts, duration;
> > > > +char timebuf[1024];
> > > > +
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +if (sscanf(buf, "stream_index=%d", _index)) {
> > > > +if ((unsigned)p.stream_index >= avf->nb_streams) {
> > > > +av_log(avf, AV_LOG_ERROR, "Invalid stream number %d 
> > > > specified in packet number %d\n",
> > > > +   p.stream_index, ffp->packet_nb);
> > > > +return AVERROR_INVALIDDATA;
> > > > +}
> > > > +}
> > > > +
> > > > +#define PARSE_TIME(name_, is_duration) 
> > > >  \
> > > > +sscanf(buf, #name_ "=%"SCNi64, _);  
> > > >  \  
> > >   
> > > > +has_time = sscanf(buf, #name_ "_time=%s", timebuf);
> > > >  \  
> > >   
> >   
> > > %s may be unsafe, not sure if theres a check elsewhere that prevents
> > > writing over the outut buffer  
> > 
> > Now the buffer is big enough, since it has the same size of the read
> > line.
> > -- 
> > FFmpeg = Fanciful and Formidable Maxi Patchable Ecletic Geisha  
> 
> >  configure|3 
> >  doc/demuxers.texi|   18 ++
> >  doc/ffprobe-format.texi  |  121 ++
> >  doc/formats.texi |1 
> >  libavformat/Makefile |1 
> >  libavformat/allformats.c |1 
> >  libavformat/ffprobedec.c |  405 
> > +++
> >  7 files changed, 550 insertions(+)
> > 267580c51d49daf94e73a33175c63ecfed6a0bed  
> > 0002-lavf-add-ffprobe-demuxer.patch
> > From 4e0aac4bc00104483859f9950af2ffb15fea6c12 Mon Sep 17 00:00:00 2001
> > From: Nicolas George 

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Carl Eugen Hoyos]

2016-10-26 1:16 GMT+02:00 Andreas Cadhalpun :
> On 25.10.2016 23:34, Carl Eugen Hoyos wrote:
>> 2016-10-25 19:19 GMT+02:00 Andreas Cadhalpun 
>> :
>>
>>> +# LTO could optimize out the test functions without this
>>> +echo "#if defined(__GNUC__) && __GNUC__ >= 4"
>>> +echo "  #define USED __attribute__((used))"
>>> +echo "#else"
>>> +echo "  #define USED"
>>> +echo "#endif"
>>
>> Why is the ugly #if - #else - #endif necessary?
>
> I'm under the impression that __attribute__((used)) is not available
> for all compilers,

Yes, but __attribute__((foo_bar)) does not break compilation here.

> see e.g. libavutil/attributes.h.

This is not a good reference, you cannot test - for example -
icc like this.

> But thinking more about it, a better way is to actually use the functions so 
> that
> LTO can't optimize them out. This avoids the ugly preprocessor checks.

Imo, they were only ugly as long as they were enclosed in #if - #endif ;-)

>> Please mention ticket #5909 if it is related.
>
> Sure, new patch attached.
>
> By the way, this is not a regression in 3.1.5, but a fix included in
> that release allowed them to drop their distro-specific patch,
> exposing the problem with LTO.

Yes, they are adding a few unneeded flags that make FFmpeg
slower and then they add lto to make compilation slower...

(But it is still a regression: 3.1 should not have seen the patch,
it doesn't support new incompatible external libraries, and the
issue was neither a regression nor security-related.)

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

Re: [FFmpeg-devel] [PATCH] configure: make sure LTO does not optimize out the test functions

[Carl Eugen Hoyos]

2016-10-26 1:35 GMT+02:00 Andreas Cadhalpun :

> I forgot to include stdint.h. Fixed patch attached.

Why don't you cast to (int)?

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

[FFmpeg-devel] [PATCH] lavf/mov.c: Use the first sidx for tracks without sidx.

[Sasi Inguva]

According to spec ISO_IEC_15444_12 "For any media stream for which no segment 
index is present, referred to as non‐indexed stream, the media stream 
associated with the first Segment Index box in the segment serves as a 
reference stream in a sense that it also describes the subsegments for any 
non‐indexed media stream."

Signed-off-by: Sasi Inguva 
---
 libavformat/isom.h |  1 +
 libavformat/mov.c  | 26 +++---
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 9038057..d684502 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -179,6 +179,7 @@ typedef struct MOVStreamContext {
 int32_t *display_matrix;
 uint32_t format;
 
+int has_sidx;  // If there is an sidx entry for this stream.
 struct {
 int use_subsamples;
 uint8_t* auxiliary_info;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 357d800..1b04b1a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4189,6 +4189,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 frag->implicit_offset = offset;
 
+av_log(c, AV_LOG_DEBUG, "stindex: %d duration: %d end: %d\n", st->index, 
st->duration, sc->track_end);
 sc->track_end = dts + sc->time_offset;
 if (st->duration < sc->track_end)
 st->duration = sc->track_end;
@@ -4202,7 +4203,8 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 uint8_t version;
 unsigned i, track_id;
 AVStream *st = NULL;
-MOVStreamContext *sc;
+AVStream *ref_st;
+MOVStreamContext *sc, *ref_sc;
 MOVFragmentIndex *index = NULL;
 MOVFragmentIndex **tmp;
 AVRational timescale;
@@ -4284,9 +4286,26 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 c->fragment_index_data = tmp;
 c->fragment_index_data[c->fragment_index_count++] = index;
+sc->has_sidx = 1;
+
+if (offset == avio_size(pb)) {
+for (i = 0; i < c->fc->nb_streams; i++) {
+if (c->fc->streams[i]->id == c->fragment_index_data[0]->track_id) {
+ref_st = c->fc->streams[i];
+ref_sc = ref_st->priv_data;
+break;
+}
+}
+for (i = 0; i < c->fc->nb_streams; i++) {
+st = c->fc->streams[i];
+sc = st->priv_data;
+if (!sc->has_sidx) {
+st->duration = sc->track_end = av_rescale(ref_st->duration, 
sc->time_scale, ref_sc->time_scale);
+}
+}
 
-if (offset == avio_size(pb))
 c->fragment_index_complete = 1;
+}
 
 return 0;
 }
@@ -5846,13 +5865,14 @@ static int mov_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 static int mov_seek_fragment(AVFormatContext *s, AVStream *st, int64_t 
timestamp)
 {
 MOVContext *mov = s->priv_data;
+MOVStreamContext *sc = st->priv_data;
 int i, j;
 
 if (!mov->fragment_index_complete)
 return 0;
 
 for (i = 0; i < mov->fragment_index_count; i++) {
-if (mov->fragment_index_data[i]->track_id == st->id) {
+if (mov->fragment_index_data[i]->track_id == st->id || !sc->has_sidx) {
 MOVFragmentIndex *index = mov->fragment_index_data[i];
 for (j = index->item_count - 1; j >= 0; j--) {
 if (index->items[j].time <= timestamp) {
-- 
2.8.0.rc3.226.g39d4020

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