Re: [FFmpeg-devel] [PATCH] vdpau: do not use buggy HEVC support by default

[Manoj Bonda]

Hi , 

HEVC issue for read-back API has been fixed and will be part of the upcoming 
drivers. 
Please help us understand the issue with the open gl interop. 
As per our understanding we are mapping the video surface to gl using the 
gl-interop
and the app(mpv) will be doing the merging/de-interlacing part.

As per our understanding, in mpv we see merging/de-interlacing is being done 
using shader at

Call stack:
   gl_sc_generate() at utils.c:1,162 0x565daa
   finish_pass_direct() at video.c:1,115 0x569cb2
   reinterleave_vdpau() at video.c:3,031 0x57277a 
   pass_upload_image() at video.c:3,079 0x572b6b
   pass_render_frame() at video.c:2,506 0x570162 
   gl_video_render_frame() at video.c:2,877 0x571ce9 
   draw_frame() at vo_opengl.c:133 0x57d920 
   render_frame() at vo.c:817 0x579113  
   vo_thread() at vo.c:916 0x579610

we are not able to get how ffmpeg is using the vdpau-opengl interop. 
Please suggest us how to repro vdpau-opengl  interop issue with ffmpeg. 

Please help us understand what needs to be done from our side for resolving 
this issue.
Please do let us know if any our understandings are wrong.

Thanks,
ManojGupta

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc.

[Jun Zhao]

On 2017/8/2 13:53, Jun Zhao wrote:
> V2: Change the slice/parameter buffers to dynamic alloc and split
> the mutil-slice support for AVC/HEVC.
> 

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

[FFmpeg-devel] [PATCH] avformat/avidec: Move packet skip after prefix and related checks

[Michael Niedermayer]

This fixes loosing packets
Fixes: big.avi

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

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index df52092067..9816a1dfac 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1265,19 +1265,6 @@ start_sync:
 }
 }
 
-if (!avi->dv_demux &&
-((st->discard >= AVDISCARD_DEFAULT && size == 0) /* ||
- // FIXME: needs a little reordering
- (st->discard >= AVDISCARD_NONKEY &&
- !(pkt->flags & AV_PKT_FLAG_KEY)) */
-|| st->discard >= AVDISCARD_ALL)) {
-if (!exit_early) {
-ast->frame_offset += get_duration(ast, size);
-avio_skip(pb, size);
-goto start_sync;
-}
-}
-
 if (d[2] == 'p' && d[3] == 'c' && size <= 4 * 256 + 4) {
 int k= avio_r8(pb);
 int last = (k + avio_r8(pb) - 1) & 0xFF;
@@ -1304,6 +1291,18 @@ start_sync:
 ast->prefix_count = 0;
 }
 
+if (!avi->dv_demux &&
+((st->discard >= AVDISCARD_DEFAULT && size == 0) /* ||
+// FIXME: needs a little reordering
+(st->discard >= AVDISCARD_NONKEY &&
+!(pkt->flags & AV_PKT_FLAG_KEY)) */
+|| st->discard >= AVDISCARD_ALL)) {
+
+ast->frame_offset += get_duration(ast, size);
+avio_skip(pb, size);
+goto start_sync;
+}
+
 avi->stream_index = n;
 ast->packet_size  = size + 8;
 ast->remaining= size;
-- 
2.13.0

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 07/08/17 23:03, Jorge Ramirez wrote:
> On 08/07/2017 11:55 PM, Mark Thompson wrote:
>>> would you know where can I get this information from (qmin/qmx for the 
>>> other encoders)?
>>  From the relevant language standards.
>>
>> H.263 / MPEG-4 part 2:  [1, 31]  (: 
>> PQUANT, GQUANT.)
>> H.264 / MPEG-4 part 10 / AVC:  [48 - 6 * bitdepth, 51]  
>> (: QpBdOffsety, pic_init_qp_minus26, 
>> slice_qp_delta.)
>> H.265 / MPEG-H part 2 / HEVC:  [48 - 6 * bitdepth, 51]  
>> (: QpBdOffsety, init_qp_minus26, 
>> slice_qp_delta.)

(Possibly relevant: many implementations normalise these to be nonnegative on 
the user side rather than using the standard values, making them [0, 3 + 
bitdepth * 6].  If you have 10-bit video then you should check what range the 
codecs actually use here.)

>> VP8:  [0, 127]  (: q_index.)
>> VP9:  [0, 255]  
>> (:
>>  base_q_idx.)
> ah thanks a lot.
> 
> btw, how come that that this information is not already present in some 
> ffmpeg table?

Most files only deal with one codec.  It's only when you've delegated almost 
everything to somewhere else that you run into the problem of all of these 
together :)

> Just trying to decide if I should just import the relevant data into the 
> v4l2_m2m_enc file or somewhere else?
Put them in the v4l2_m2m_enc file, I think.  How you want do that probably 
depends on how V4L2 acts without the options: if it acts sensibly when you 
don't pass them, then make a defaults table with sentinel values and don't pass 
anything if you see them (so they are only passed to the codec if the user sets 
them manually).  If they are required, then you'll need to make a defaults 
table for each codec with the correct values in.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 07/08/17 20:28, Jorge Ramirez wrote:
> On 08/03/2017 01:53 AM, Mark Thompson wrote:
>>> +AV_OPT_TYPE_INT,\
>>> +{.i64 = V4L2_MEMORY_MMAP},\
>>> +0, INT_MAX, FLAGS },\
>>> +{ "output_memory",\
>>> +"Output memory model: See V4L2_MEMORY_* in videodev2.h. This 
>>> depends on the HW but default should work with most.",\
>>> +OFFSET(capture_pool.memory),\
>>> +AV_OPT_TYPE_INT,\
>>> +{.i64 = V4L2_MEMORY_MMAP},\
>>> +0, INT_MAX, FLAGS },\
>>> +{ "num_output_pool_buffers",\
>>> +"Number of buffers in the output pool",\
>>> +OFFSET(output_pool.num_buffers),\
>>> +AV_OPT_TYPE_INT,\
>>> +{ .i64 = 16 },\
>>> +4, INT_MAX, FLAGS }
>> Can we attempt to set this automatically based on the codec?  16 won't be 
>> enough for worst-case H.264/H.265.
>>
> 
> please could you suggest some defaults so I can prepare the table?

If, as you've suggested elsewhere, the decoder doesn't actually use these 
frames for reference and instead has its own copies internally then this won't 
actually matter.

If it turns out that you do need the buffering here then the numbers of 
surfaces used by other hardware decoders are probably good - e.g. 
.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 07/08/17 20:24, Jorge Ramirez wrote:
> On 08/03/2017 01:53 AM, Mark Thompson wrote:
>>> +default:
>>> +return 0;
>>> +}
>>> +
>>> +SET_V4L_EXT_CTRL(value, qmin, avctx->qmin, "minimum video quantizer 
>>> scale");
>>> +SET_V4L_EXT_CTRL(value, qmax, avctx->qmax, "maximum video quantizer 
>>> scale");
>>> +
>>> +return 0;
>>> +}
>> This doesn't set extradata - you need to extract the codec global headers 
>> (such as H.264 SPS and PPS) at init time to be able to write correct files 
>> for some codecs (such as H.264) with muxers requiring global headers (such 
>> as MP4).  It kindof works without it, but the files created will not conform 
>> and will not be usable on some players.
>>
> ah that might explain some things (when I play back the encoded video the 
> quality is pretty lousy)
> is there already some code I can use as a reference? I might be out of my 
> depth here so any help will be more than welcome

Methods used by other codecs to extract the headers:

Something to call directly to get them:
* x264_encoder_headers in libx264: 
.
* nvEncGetSequenceParams in nvenc: 
.

They appear on the front of the stream and can be read from there at init time:
* OMX_BUFFERFLAG_CODECCONFIG in OpenMAX IL: 
.

Know the answer magically in advance (probably not applicable here):
* VAAPI makes the user write their own headers, so we can just write those to 
the extradata directly as well: 
.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/07/2017 11:55 PM, Mark Thompson wrote:

would you know where can I get this information from (qmin/qmx for the other 
encoders)?

 From the relevant language standards.

H.263 / MPEG-4 part 2:  [1, 31]  (: 
PQUANT, GQUANT.)
H.264 / MPEG-4 part 10 / AVC:  [48 - 6 * bitdepth, 51]  
(: QpBdOffsety, pic_init_qp_minus26, 
slice_qp_delta.)
H.265 / MPEG-H part 2 / HEVC:  [48 - 6 * bitdepth, 51]  
(: QpBdOffsety, init_qp_minus26, 
slice_qp_delta.)
VP8:  [0, 127]  (: q_index.)
VP9:  [0, 255]  
(:
 base_q_idx.)

ah thanks a lot.

btw, how come that that this information is not already present in some 
ffmpeg table?
Just trying to decide if I should just import the relevant data into the 
v4l2_m2m_enc file or somewhere else?

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/08/2017 12:01 AM, Mark Thompson wrote:

great, thanks for that.
The issue I have is that the V4L2 driver I am using to test - yes this needs to 
be detected by the decoder- has not implemented the feature yet. Will keep it 
in mind before sending the last series of the patchset.

Are they actually expecting the user to parse the stream externally to detect this 
case?  That wouldn't be too horrible to implement if many drivers are likely to have 
this problem - we already do essentially the same thing in the QSV decoder - see the 
parser use 
at.


the detection if I understood it correctly is handled and flagged by the 
hardware codec (the v4l2 driver) and the user (ie ffmpeg) is then 
notified and need to do some corrections.


But yes, I need to look this in detail (will not be in the next v4 
patchset, probably in v5)





also, I have rewritten the patchset to add clarity and clean some of the 
sedimentation from testing/hacking. is it ok with you if I post v4 now? it will 
simplify the discussion - the driver now much easier to follow.

Sure.  I'll go through it again within a few days.


thanks a lot for your help on this.



- Mark


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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Michael Niedermayer]

On Mon, Aug 07, 2017 at 11:03:51AM +0200, Nicolas George wrote:
> > >Lets take a step back and look at this
> > >
> > >There are some rarely used options in multi input filters like
> > >overlay which break.
> > >Noone even noticed except me
> > >
> > >And you propose to declare the most used syntax from every filter
> > >unstable.
> > >
> > >This just doesnt add up, its like shooting the patient in the head as
> > >a treatment for a cold
> 
> No, that is like telling the patient they need to take their antibiotics
> until the last day of treatment and not stop once they feel better,
> because they risk getting a pneumonia. Which is technically true, only
> very unlikely.
> 
> 
> Le decadi 20 thermidor, an CCXXV, Marton Balint a écrit :
> > Do you like this text better?
> > 
> > Future evolutions of filters may require inserting new options or changing
> > their order, especially for the non-essential options, and while we make
> > reasonable effort to keep the order so the options given without their name
> > would not break, sometimes that is not feasable. Therefore users should
> > generally favor the @var{key=value} notation, or refer to the Changelog file
> > which should contain such incompatible changes.
> 
> This is obviously the intent, but I do not think that the documentation
> is the place to make that kind of intent statement.
> 
> > Yeah, what is needed for compatibility? Only a single AVOption line, or
> > additional code as well?
> 
> Additional code as well. Not a lot, but still some. And testing. An
> exponential number of cases.
> 
> I do not intend to do it.
> 
> We have already wasted more time than all the users combined will spend
> typing "x=", "y=". Seriously, people !?!
> 
> Now, to all that stated a negative opinion about this:
> 
> I have in the queue a patch series that changes the options in a minor
> way, but at the same time fixes bugs and long-standing limitations of
> lavfi and makes the code more robust and cleaner.
> 
> Do you :
> 

> 1. propose to implement and test compatibility options yourself?

If you push the lavfi patchset but the doc option instability patch
is not pushed then ill likely try to fix the compatibility issue
due to the moved options in overlay and similar filters.

If theres some preferrance on how to fix it?
(iam happy to fix it in the way you perfer as long as its not more
 work than the obvious way to fix it)


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 07/08/17 19:57, Jorge Ramirez wrote:
> On 08/04/2017 03:32 PM, Mark Thompson wrote:
>> On 04/08/17 14:06, Jorge Ramirez wrote:
>>> On 08/04/2017 01:51 PM, Mark Thompson wrote:
> +if (ret)
> +return 0;
> +
> +return avpriv_v4l_dequeue(cap_pool, frame, NULL, timeout);
> +}
 What happens to the decoder if some parameters like resolution change 
 mid-stream?  (Try the stream h264/reinit-large_420_8-to-small_420_8.h264 
 in the fate samples.)
>>> yes, it breaks - the player still shows and image but it is corrupted.
>>> I am not sure how to handle this situation to be honest...so need to look 
>>> into this.
>> There should be some way to detect it from the decoder, I think?  (I don't 
>> actually know how this works in V4L2.)
>>
>> To compare, if you look at MMAL (perhaps the most similar API in current 
>> lavc) there is a special FORMAT_CHANGED return when dequeuing a frame, and 
>> the decoder is reconfigured with new buffers when that 
>> happens:.
>>
> 
> great, thanks for that.
> The issue I have is that the V4L2 driver I am using to test - yes this needs 
> to be detected by the decoder- has not implemented the feature yet. Will keep 
> it in mind before sending the last series of the patchset.

Are they actually expecting the user to parse the stream externally to detect 
this case?  That wouldn't be too horrible to implement if many drivers are 
likely to have this problem - we already do essentially the same thing in the 
QSV decoder - see the parser use at 
.

> also, I have rewritten the patchset to add clarity and clean some of the 
> sedimentation from testing/hacking. is it ok with you if I post v4 now? it 
> will simplify the discussion - the driver now much easier to follow.

Sure.  I'll go through it again within a few days.

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 07/08/17 19:51, Jorge Ramirez wrote:
> On 08/04/2017 01:51 PM, Mark Thompson wrote:
>>> +break;
>>> +case AV_CODEC_ID_H263:
>>> +qmin = MPEG_CID(H263_MIN_QP);
>>> +qmax = MPEG_CID(H263_MAX_QP);
>>> +break;
>>> +case AV_CODEC_ID_VP8:
>>> +case AV_CODEC_ID_VP9:
>>> +qmin = MPEG_CID(VPX_MIN_QP);
>>> +qmax = MPEG_CID(VPX_MAX_QP);
>>> +break;
>>> +default:
>>> +return 0;
>>> +}
>>> +
>>> +SET_V4L_EXT_CTRL(value, qmin, avctx->qmin, "minimum video quantizer 
>>> scale");
>>> +SET_V4L_EXT_CTRL(value, qmax, avctx->qmax, "maximum video quantizer 
>>> scale");
>> The default values of qmin/qmax in options_table.h are set for the MPEG-4 
>> part 2 encoder, and will do nasty things to others.  (Certainly for VP9 
>> (assuming it maps to qindex) it's a very low value, so it probably won't 
>> ever get anywhere near the bitrate target for normal video.  H.26[45] and 
>> VP8 also, but to a lesser degree.)
> 
> would you know where can I get this information from (qmin/qmx for the other 
> encoders)?

From the relevant language standards.

H.263 / MPEG-4 part 2:  [1, 31]  (: 
PQUANT, GQUANT.)
H.264 / MPEG-4 part 10 / AVC:  [48 - 6 * bitdepth, 51]  
(: QpBdOffsety, pic_init_qp_minus26, 
slice_qp_delta.)
H.265 / MPEG-H part 2 / HEVC:  [48 - 6 * bitdepth, 51]  
(: QpBdOffsety, init_qp_minus26, 
slice_qp_delta.)
VP8:  [0, 127]  (: q_index.)
VP9:  [0, 255]  
(:
 base_q_idx.)


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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Michael Niedermayer]

On Mon, Aug 07, 2017 at 09:25:27AM +0200, Marton Balint wrote:
> 
> 
> On Mon, 7 Aug 2017, Michael Niedermayer wrote:
> 
> >On Sun, Aug 06, 2017 at 10:37:35AM +0200, Nicolas George wrote:
> >>L'octidi 18 thermidor, an CCXXV, James Almer a écrit :
> >>>What do you mean? What i suggested would be done each time an option is
> >>>removed or added anywhere but at the end, both of which afaik are
> >>>uncommon cases.
> >>>It's not something that requires a rewrite of the current codebase.
> >>
> >>I mean that since I consider the break bearable (somebody upgrades a
> >>piece of software, they MUST test the scripts that depend on it, and
> >>fixing the issue once and for all is easy), I am not willing to spend my
> >>time implementing (and testing, for this kind of thing that takes time)
> >>the deprecation-warning-and-backward-compatibility dance.
> >
> >Lets take a step back and look at this
> >
> >There are some rarely used options in multi input filters like
> >overlay which break.
> >Noone even noticed except me
> >
> >And you propose to declare the most used syntax from every filter
> >unstable.
> >
> >This just doesnt add up, its like shooting the patient in the head as
> >a treatment for a cold
> 
> Do you like this text better?

No


> 
> Future evolutions of filters may require inserting new options or
> changing their order,

This is not true.
like future evolutions of the C standard dont require reordering
function arguments or standard POSIX tools dont require
renaming options.
There simply is no such requirement
We should be honest in the text.
"People working on future evolutions of libavfilter _WANT_ to insert
options or change their order"

If we write that its required some will realize that this is unlikely
and look deeper and it would make FFmpeg as a whole look
unprofessional.


> especially for the non-essential options, and
> while we make reasonable effort to keep the order so the options
> given without their name would not break,

So far there was effort toward changing the order not toward keeping it.
If effort is directed towards keeping it then we probably do not need
this text.

Yes we may hit a case once in a while where theres a majority prefering
to break some rarely used case for code cleanliness but this doesnt
require declaring the whole of the interface as unstable.
It is basically the whole as everyone and everything uses the shorthand
notation including our and others docs, examples and tutorials.


> sometimes that is not
> feasable. Therefore users should generally favor the @var{key=value}
> notation,  [...]

I do not agree as a maintainer of several filters of libavfilter.

I do try to keep my code compatible
and if someone would inform me that theres a break in the interface of
a filter of mine i would fix that if it is possible.
[if there are such issues in filters i maintain, please directly
 mail me or ping me on IRC or CC me on tickets]

I do care about users of my code, be that end users of tools or
developers using the libs.
And to me a stable interface and stable public API is a essential part
in (practically) usable software.

Will i fix every interface break in every filter? i do not know.
I do know though that iam interrested in helping with that as long
as the shorthand is part of the stable interface and help from me is
welcome. So far ive the feeling that my help is VERY unwelcome.
And this patch removes the shorthand from the stable interface.
Removing any and all reasons why i would be interrested in working on
it.


> 
> >
> >Please correct me if iam wrong, but isnt all that is needed to just
> >not remove the options from the AVOption array from the tiny number
> >of filters affected?
> >Or declare the tiny number of moved/changed options as removed/not
> >supported in shorthand notation.
> 
> Yeah, what is needed for compatibility? Only a single AVOption line,
> or additional code as well?

There are 2 ways at least, one is:

One line for each removed option, in fact the removed line, and
possbly one line to copy it to the new place if this cannot be
directly referred to from the AVOption line.
If the factored struct is referenceable by offset from the context
that is either is part of the other then only a single line is needed

Heres the removed and added options from the patches:
As you can see its the same options, only OFFSET would have to
refer to the new place

-{ "eof_action", "Action to take when encountering EOF from secondary input 
",
-OFFSET(eof_action), AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_REPEAT },
-EOF_ACTION_REPEAT, EOF_ACTION_PASS, .flags = FLAGS, "eof_action" },
-{ "repeat", "Repeat the previous frame.",   0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_REPEAT }, .flags = FLAGS, "eof_action" },
-{ "endall", "End both streams.",0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_ENDALL }, .flags = FLAGS, "eof_action" },
-{ "pass",   "Pass through the main input.", 0, AV_OPT_TYPE_CONST, { 

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

On Fri, Aug 4, 2017 at 4:40 PM, Rodger Combs  wrote:

> +sc->ctts_data = av_fast_realloc(sc->ctts_data,
> >ctts_allocated_size, request_size);
> ^ this line is incorrect; setting realloc's first arg to its return value
> leaks the existing allocation in the OOM case. Since you're doing your own
> calculation for the desired new size here, you may want to use av_reallocp
> (which frees the original allocation on failure).
>

Thanks, fixed; kept av_fast_realloc() for size setting simplicity, but
reused function-scope ctts_data as temporary.


>
> When reading a trun that requires this sort of realloc, is it common for
> there to be any existing entries in the range we're writing? Would it be
> safe to remove+replace them? Could we do a single realloc + single memmove,
> and then fill the newly-opened space, rather than repeating the memmove for
> each entry?
>

Yes it's common for their to be existing entries. To be clear this occurs
with standard files that are of sufficient length that a seek can occur
before all trun boxes are read. We could speculatively move all entries
based on the first insert and total entries count, but their are several
conditionals in av_add_index_entry() which may cause a bail out and such
failure would be unrecoverable (maybe painfully?) if we moved everything
ahead of time.

- dale
From 4938dac2d9f3b40c62822d9129046edbde44468d Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Mon, 17 Jul 2017 17:38:09 -0700
Subject: [PATCH] Fix trampling of ctts during seeks when sidx support is
 enabled.

When sidx box support is enabled, the code will skip reading all
trun boxes (each containing ctts entries for samples inthat box).

If seeks are attempted before all ctts values are known, the old
code would dump ctts entries into the wrong location. These are
then used to compute pts values which leads to out of order and
incorrectly timestamped packets.

This patch fixes ctts processing by always using the index returned
by av_add_index_entry() as the ctts_data index. When the index gains
new entries old values are reshuffled as appropriate.

This approach makes sense since the mov demuxer is already relying
on the mapping of AVIndex entries to samples for correct demuxing.

As a result of this all ctts entries are now 1-count. A followup
change will be submitted to remove support for > 1 count entries
which will simplify seeking.

Notes for future improvement:
Probably there are other boxes (stts, stsc, etc) that are impacted
by this issue... this patch only attempts to fix ctts since it
completely breaks packet timestamping.

This patch continues using an array for the ctts data, which is not
the most ideal given the rearrangement that needs to happen (via
memmove as new entries are read in). Ideally AVIndex and the ctts
data would be set-type structures so addition is always worst case
O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
noticeable during seeks.

Signed-off-by: Dale Curtis 
---
 libavformat/isom.h   |   1 +
 libavformat/mov.c|  79 ++--
 tests/fate/seek.mak  |   3 ++
 tests/ref/seek/extra-mp4 | 134 +++
 4 files changed, 189 insertions(+), 28 deletions(-)
 create mode 100644 tests/ref/seek/extra-mp4

diff --git a/libavformat/isom.h b/libavformat/isom.h
index ff009b0896..fdd98c28f5 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -137,6 +137,7 @@ typedef struct MOVStreamContext {
 unsigned int stts_count;
 MOVStts *stts_data;
 unsigned int ctts_count;
+unsigned int ctts_allocated_size;
 MOVStts *ctts_data;
 unsigned int stsc_count;
 MOVStsc *stsc_data;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 63f84be782..85377f39a9 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -74,6 +74,8 @@ typedef struct MOVParseTableEntry {
 
 static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom);
 static int mov_read_mfra(MOVContext *c, AVIOContext *f);
+static int64_t add_ctts_entry(MOVStts** ctts_data, unsigned int* ctts_count, unsigned int* allocated_size,
+  int count, int duration);
 
 static int mov_metadata_track_or_disc_number(MOVContext *c, AVIOContext *pb,
  unsigned len, const char *key)
@@ -2708,7 +2710,7 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
 MOVStreamContext *sc;
-unsigned int i, entries, ctts_count = 0;
+unsigned int i, j, entries, ctts_count = 0;
 
 if (c->fc->nb_streams < 1)
 return 0;
@@ -2726,7 +2728,7 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 if (entries >= UINT_MAX / sizeof(*sc->ctts_data))
 return AVERROR_INVALIDDATA;
 av_freep(>ctts_data);
-sc->ctts_data = av_realloc(NULL, entries * sizeof(*sc->ctts_data));
+

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

On Fri, Aug 4, 2017 at 4:38 PM, Michael Niedermayer 
wrote:

> so theres no easy way to create a smaller file then 64mb ?
>

Ah no, I didn't realize you had a size limit; I just meant none of the
existing clips were large enough / worked. I've truncated the clip at
http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 to 180 seconds
and the seek test passes and fails correctly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+AV_OPT_TYPE_INT,\
+{.i64 = V4L2_MEMORY_MMAP},\
+0, INT_MAX, FLAGS },\
+{ "output_memory",\
+"Output memory model: See V4L2_MEMORY_* in videodev2.h. This depends on the 
HW but default should work with most.",\
+OFFSET(capture_pool.memory),\
+AV_OPT_TYPE_INT,\
+{.i64 = V4L2_MEMORY_MMAP},\
+0, INT_MAX, FLAGS },\
+{ "num_output_pool_buffers",\
+"Number of buffers in the output pool",\
+OFFSET(output_pool.num_buffers),\
+AV_OPT_TYPE_INT,\
+{ .i64 = 16 },\
+4, INT_MAX, FLAGS }

Can we attempt to set this automatically based on the codec?  16 won't be 
enough for worst-case H.264/H.265.



please could you suggest some defaults so I can prepare the table?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+}
+
+dequeue:
+
+ret = avpriv_v4l_dequeue(cap_pool, NULL, pkt, timeout);
+if (ret == AVERROR(EAGAIN))
+return 0;
+if (!ret)
+*got_packet = 1;
+
+return ret;
+}

Does this actually work for a long stream?  You won't necessarily return a 
packet for every frame, but always need to enqueue a frame to be able to 
attempt to dequeue a packet.

It might be better to use the send/receive API here as well.


how long does it have to be? I have only tried a couple of minutes

ok will check the API
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+default:
+return 0;
+}
+
+SET_V4L_EXT_CTRL(value, qmin, avctx->qmin, "minimum video quantizer 
scale");
+SET_V4L_EXT_CTRL(value, qmax, avctx->qmax, "maximum video quantizer 
scale");
+
+return 0;
+}

This doesn't set extradata - you need to extract the codec global headers (such 
as H.264 SPS and PPS) at init time to be able to write correct files for some 
codecs (such as H.264) with muxers requiring global headers (such as MP4).  It 
kindof works without it, but the files created will not conform and will not be 
usable on some players.

ah that might explain some things (when I play back the encoded video 
the quality is pretty lousy)
is there already some code I can use as a reference? I might be out of 
my depth here so any help will be more than welcome

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+if (ret)
+return 0;
+
+return avpriv_v4l_dequeue(cap_pool, frame, NULL, timeout);

I feel like if the stream has a lot of delay then you will end up needing to 
wait for the timeout to get the required EAGAIN, which at 1s is very large.  
(Though I think you won't in common cases because of the min_queued_buffers 
constraint in dequeue.)


+}

yes, you are correct. fixed on v4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+
+/* this will report the size of the frame back (see a4lbuf_to_avframe) */
+cap_pool->height = avctx->coded_height;
+cap_pool->width = avctx->coded_width;

Does coded_height/width need to be set to anything sensible here?  That won't 
be true in general.


not at this point. this code has been removed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [vlc-devel] VideoLAN Dev Days 2017 Registration

[Rostislav Pehlivanov]

On 7 August 2017 at 18:40, Jean-Baptiste Kempf  wrote:

> Hello FFmpeg geeks and geekettes!
>
> Finally, I'd like to do a call for conferences, to present on Saturday
> morning, as the previous years.
>
>
I'd like to present a talk about the FFmpeg Opus encoder (which would also
get into the technicalities of the Opus codec), how its being tuned and the
challenges about writing an implementation from scratch. Ask me if you need
a placeholder title :)

Also, I'd like to invite kamedo2 to get sponsored to attend VDD this year.
He's the person who helps tuning the FFmpeg's native AAC and Opus encoders
as well as the libopus encoder. Me and Jean-Marc Valin would appreciate it
if he could attend. I've asked kamedo2 to register and email you as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+return ret;
+}
+
+av_log(log_ctx, AV_LOG_INFO, "Using device %s\n", tmpbuf);
+ret = probe_and_set(s, log_ctx, 1);
+s->devname = devname_save;

This probing structure feels very fragile and possibly harmful (opening random 
devices and poking them).  It might be better to just force the user to supply 
the right device path?


+
I cleaned it up on v4 but I dont think it can be done much differently: 
the user needs to query the capabilities of every /dev/videoX node..


btw the same probing is already done in  libavdevice/v4l2.c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+static int probe_and_set(V4Lm2mContext* s, void *log_ctx, int set)
+{
+int fail_log_level = ( set ? AV_LOG_ERROR : AV_LOG_DEBUG);
+int ret;
+
+s->fd = open(s->devname, O_RDWR, 0);

O_NONBLOCK, given DQBUF is used as if it is?


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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Marton Balint]

On Tue, 8 Aug 2017, Gyan wrote:


On Mon, Aug 7, 2017 at 11:11 PM, John Warburton 
wrote:



if an old FFmpeg script of mine breaks, as they have on a couple of
occasions, isn't it logical for a user of the command line to go
straight to the documentation, and the answer (and the fix) always
seems to be there?



If a modified filter with value-only arguments produces unexpected results,
possible if the new option accepts same type/range as the older option in
that position, then the user may be confounded as to why the filter is
behaving differently. Same if the new option isn't accommodating and the
command doesn't parse. This patch is being inserted in the docs up top, in
the generic filtering section. The user is unlikely to look there for
guidance, but in the section specific to the filter. So it may not be clear
why the filter invocation fails, given the keys aren't present.


That is why I believe a breaking change such as the overlay filter 
option order change should be mentioned in the Changelog.


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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: fix alpha blending for planar formats with a transparent background

[Marton Balint]

On Sat, 5 Aug 2017, Michael Niedermayer wrote:


On Fri, Aug 04, 2017 at 10:23:55AM +0200, Marton Balint wrote:

When the background had an alpha channel, the old code in blend_plane
calculated premultiplied alpha from the destination plane colors instead of the
destination alpha.

Also the calculation of the output alpha should only happen after the color
planes are already finished.

Fixes output of:
ffplay -f lavfi "testsrc2=alpha=32[a];color=black[b];[b][a]overlay[out0]"


if it is easy, please add a fate test when / after you push this



Ok, will do as a second step. I am going to apply this soon.

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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+return AVERROR(errno);
+
+bp->streamon = (cmd == VIDIOC_STREAMON);
+
+return 0;
+}
+
+int avpriv_v4l_enqueue(V4LBufferPool* bp, const AVFrame* f, const AVPacket* 
pkt)

Just make separate functions.


done in v4
thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/03/2017 01:53 AM, Mark Thompson wrote:

+
+static int v4lbuf_to_avframe(AVFrame *frame, V4LBuffer *avbuf)
+{
+int i, ret;
+
+av_frame_unref(frame);
+
+for (i = 0; i < avbuf->num_planes; i++) {
+ret = v4l2bufref(avbuf, i, >buf[i]);> +if (ret)
+return ret;
+
+frame->linesize[i] = avbuf->bytesperline[i];
+frame->data[i] = frame->buf[i]->data;
+
+if (avbuf->num_planes == 1) {
+if (avbuf->pool->av_pix_fmt == AV_PIX_FMT_NV12) {

Special-casing like this rather inspires doubt that other formats are handled 
correctly.

I dont disagree with you but this was the only way I could play the 
decoded videos with ffplay. do you think this could be an ffplay issue?


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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/04/2017 01:51 PM, Mark Thompson wrote:

+break;
+case AV_CODEC_ID_H263:
+qmin = MPEG_CID(H263_MIN_QP);
+qmax = MPEG_CID(H263_MAX_QP);
+break;
+case AV_CODEC_ID_VP8:
+case AV_CODEC_ID_VP9:
+qmin = MPEG_CID(VPX_MIN_QP);
+qmax = MPEG_CID(VPX_MAX_QP);
+break;
+default:
+return 0;
+}
+
+SET_V4L_EXT_CTRL(value, qmin, avctx->qmin, "minimum video quantizer 
scale");
+SET_V4L_EXT_CTRL(value, qmax, avctx->qmax, "maximum video quantizer 
scale");

The default values of qmin/qmax in options_table.h are set for the MPEG-4 part 
2 encoder, and will do nasty things to others.  (Certainly for VP9 (assuming it 
maps to qindex) it's a very low value, so it probably won't ever get anywhere 
near the bitrate target for normal video.  H.26[45] and VP8 also, but to a 
lesser degree.)


would you know where can I get this information from (qmin/qmx for the 
other encoders)?



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

Re: [FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/04/2017 03:32 PM, Mark Thompson wrote:

On 04/08/17 14:06, Jorge Ramirez wrote:

On 08/04/2017 01:51 PM, Mark Thompson wrote:

+if (ret)
+return 0;
+
+return avpriv_v4l_dequeue(cap_pool, frame, NULL, timeout);
+}

What happens to the decoder if some parameters like resolution change 
mid-stream?  (Try the stream h264/reinit-large_420_8-to-small_420_8.h264 in the 
fate samples.)

yes, it breaks - the player still shows and image but it is corrupted.
I am not sure how to handle this situation to be honest...so need to look into 
this.

There should be some way to detect it from the decoder, I think?  (I don't 
actually know how this works in V4L2.)

To compare, if you look at MMAL (perhaps the most similar API in current lavc) there 
is a special FORMAT_CHANGED return when dequeuing a frame, and the decoder is 
reconfigured with new buffers when that 
happens:.



great, thanks for that.
The issue I have is that the V4L2 driver I am using to test - yes this 
needs to be detected by the decoder- has not implemented the feature 
yet. Will keep it in mind before sending the last series of the patchset.


also, I have rewritten the patchset to add clarity and clean some of the 
sedimentation from testing/hacking. is it ok with you if I post v4 now? 
it will simplify the discussion - the driver now much easier to follow.

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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Gyan]

On Mon, Aug 7, 2017 at 11:11 PM, John Warburton 
wrote:


> if an old FFmpeg script of mine breaks, as they have on a couple of
> occasions, isn't it logical for a user of the command line to go
> straight to the documentation, and the answer (and the fix) always
> seems to be there?
>

If a modified filter with value-only arguments produces unexpected results,
possible if the new option accepts same type/range as the older option in
that position, then the user may be confounded as to why the filter is
behaving differently. Same if the new option isn't accommodating and the
command doesn't parse. This patch is being inserted in the docs up top, in
the generic filtering section. The user is unlikely to look there for
guidance, but in the section specific to the filter. So it may not be clear
why the filter invocation fails, given the keys aren't present.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[John Warburton]

On Mon, Aug 7, 2017 at 10:03 AM, Nicolas George  wrote:
>> >Lets take a step back and look at this
>> >
>> >There are some rarely used options in multi input filters like
>> >overlay which break.
>> >Noone even noticed except me
...

> Now, to all that stated a negative opinion about this:
>
> I have in the queue a patch series that changes the options in a minor
> way, but at the same time fixes bugs and long-standing limitations of
> lavfi and makes the code more robust and cleaner.
>
> Do you :
>
> 1. propose to implement and test compatibility options yourself?
>
> 2. own up you are blocking these enhancements?
>
> 3. accept the series and the breakage?

I am not a developer (though am learning to read the source code) but
if an old FFmpeg script of mine breaks, as they have on a couple of
occasions, isn't it logical for a user of the command line to go
straight to the documentation, and the answer (and the fix) always
seems to be there? Or just type "ffmpeg -h filter=scale" or similar,
where the order of un-named options isn't even mentioned? In my
experience today, much more so than in the olden days when we used to
type "C> wp.exe mydoc.wpd", CLI users aren't afraid of documentation
and development.

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

[FFmpeg-devel] [vlc-devel] VideoLAN Dev Days 2017 Registration

[Jean-Baptiste Kempf]

Hello FFmpeg geeks and geekettes!

Once again the time for VDD is approaching, and we would like to invite
you to this year's edition, to be held in Paris.

https://vdd.videolan.org/

This technical conference about open source multimedia, will see
developers from VLC, x26*, libbluray, FFmpeg, libav, DVBlast,
PulseAudio, KDE, Gnome, Xiph, handbrake and other projects gather to
discuss about open source development of multimedia projects.

This is a developer conference, so topics will be very technical.

You can find all the information you need on https://vdd.videolan.org/


The registration is open, and you can do so at
https://goo.gl/forms/YJ0IakCQ7WLyUYgr1

Please register as soon as possible, as it will help us organize the
conference.


Please note that the event will be held under the VideoLAN CoC:
https://wiki.videolan.org/Code_of_Conduct/


As usual, VideoLAN will pay for travel, food and hosting costs, for
the active people of the open source community.

If you are working for a company using multimedia open source software,
you are, of course, welcome too. Please know that we are looking for
sponsorships, for this event, though.

If you were sponsored last years, you are sponsored this year too.
If you don't know if you're likely to get sponsorship, please mail us.
If you could buy your flights ASAP, please do so. If you don't know if
the price of your flight is correct, please ask us.
Sponsoring will be granted only to people who register quickly enough.

As the previous years, we'll do an event on the Friday 22. It will
either be a Theme Park (Disney again?) or a custom adventure, followed
by the usual beers or other drinks.
This is of course, optional. (but recommended)

Finally, I'd like to do a call for conferences, to present on Saturday
morning, as the previous years.

With my kindest regards,

-- 
Jean-Baptiste Kempf
___
vlc-devel mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[John Warburton]

On Mon, Aug 7, 2017 at 10:08 AM, Nicolas George  wrote:
>
> This issue seems fixed by these changes:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/214306.html
>
> I thought it could only be triggered with the specific configuration
> caused by dualinput, but you obviously found another way.
>
> The patches in this series need some review before being pushed.

Confirming: applying the patch in
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/214306.html causes
multiple vf_stack calls to work again.

It didn't apply first time because I'd incorrectly saved the patch text.

Thank you very much for this suggestion!
J
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mov: Fix inserting frames before current_frame.

[Jacob Trimble]

Ping

On Thu, Jul 27, 2017 at 10:34 AM, Jacob Trimble  wrote:
> When using streaming input, it may be possible to see frames that appear
> before the current_frame.  When these frames are inserted into the
> index, the current_frame needs to be updated so it is still pointing
> at the same frame.
>
> Signed-off-by: Jacob Trimble 
> ---
>  libavformat/mov.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 63f84be782..d039f27063 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4259,7 +4259,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  int64_t dts;
>  int data_offset = 0;
>  unsigned entries, first_sample_flags = frag->flags;
> -int flags, distance, i, err;
> +int flags, distance, i, err, old_nb_index_entries;
>
>  for (i = 0; i < c->fc->nb_streams; i++) {
>  if (c->fc->streams[i]->id == frag->track_id) {
> @@ -4352,13 +4352,19 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES));
>  if (keyframe)
>  distance = 0;
> +old_nb_index_entries = st->nb_index_entries;
>  err = av_add_index_entry(st, offset, dts, sample_size, distance,
>   keyframe ? AVINDEX_KEYFRAME : 0);
>  if (err < 0) {
>  av_log(c->fc, AV_LOG_ERROR, "Failed to add index entry\n");
> +} else if (err <= sc->current_sample && err + 1 != 
> st->nb_index_entries &&
> +st->nb_index_entries != old_nb_index_entries) {
> +// if we inserted a new item before the current sample, move the
> +// counter ahead so it is still pointing to the same sample.
> +sc->current_sample++;
>  }
> -av_log(c->fc, AV_LOG_TRACE, "AVIndex stream %d, sample %u, offset 
> %"PRIx64", dts %"PRId64", "
> -"size %u, distance %d, keyframe %d\n", st->index, 
> sc->sample_count+i,
> +av_log(c->fc, AV_LOG_TRACE, "AVIndex stream %d, sample %d, offset 
> %"PRIx64", dts %"PRId64", "
> +"size %u, distance %d, keyframe %d\n", st->index, err,
>  offset, dts, sample_size, distance, keyframe);
>  distance++;
>  dts += sample_duration;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] [PATCH] avdevice/avfoundation: add scaleFactor attribute for avfoundation

[Thilo Borgmann]

Am 07.08.17 um 01:31 schrieb sharpbai:
> From: sharpbai 
> 
> feature: add scaleFactor attribute for avfoundation
> added by: siyuan.w...@duobei.com
> added by: yiren...@duobei.com
> ---
>  doc/indevs.texi| 22 ++
>  libavdevice/avfoundation.m |  6 ++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/doc/indevs.texi b/doc/indevs.texi
> index 09e3321..1ba71d7 100644
> --- a/doc/indevs.texi
> +++ b/doc/indevs.texi
> @@ -139,6 +139,13 @@ Capture the mouse pointer. Default is 0.
>  @item -capture_mouse_clicks
>  Capture the screen mouse clicks. Default is 0.
>  
> +@item -scale_factor
> +Scale factor for capture the screen. Set this property to scale the buffers
"Scale factor during screen capturing. Set this property to scale the screens 
by a given factor." 


> +by a given factor. For example capturing a retina screen which resolution 
> 2880x1800 
Trailing whitespace.


> +with a scale_factor of 0.5 (or 0.05) produces video buffers at 1440x900 (or 
> 144x90).
The example part should cover that so this can be removed.


> +This is useful for reducing captured file size and increasing performance 
> +in capturing screen. 
Can also be removed.


> Default is 1.0 (no scaling).
> +
>  @end table
>  
>  @subsection Examples
> @@ -169,6 +176,21 @@ Record video from the system default video device using 
> the pixel format bgr0 an
>  $ ffmpeg -f avfoundation -pixel_format bgr0 -i "default:none" out.avi
>  @end example
>  
> +@item
> +Capture video from the first screen using the pixel format bgr0 and scaling 
> in half size into out.avi.
> +First command use the avfoundation device command to enumerate all the 
> available input devices including
> +screens ready to be captured:
> +@example
> +$ ffmpeg -f avfoundation -list_devices true -i ""
> +@end example
> +Once you've figured out the device index corresponding to the screen to be 
> captured use, run the second
> +command with the correct screen device index to execute screen capture. 
The documentation already covers the block above so this should be removed.


> For example on my mac the index
> +of "Screen Capture 0" is "1", I should replace @code{-i 
> ""} with @code{-i "1"} in the second command.
> +@example
> +$ ffmpeg -f avfoundation -pixel_format bgr0 -scale_factor 0.5 -i 
> "" out.avi
> +@end example
> +
> +
Remove things like "on my mac" and "I should...".
See the other examples for reference.


>  @end itemize
>  
>  @section bktr
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index e2ddf47..1196cf3 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -96,6 +96,7 @@ typedef struct
>  
>  int capture_cursor;
>  int capture_mouse_clicks;
> +float   scale_factor;
>  
>  int list_devices;
>  int video_device_index;
> @@ -735,6 +736,10 @@ static int avf_read_header(AVFormatContext *s)
>  capture_screen_input.minFrameDuration = 
> CMTimeMake(ctx->framerate.den, ctx->framerate.num);
>  }
>  
> +if (ctx->scale_factor > 0.0) {
> +capture_screen_input.scaleFactor = ctx->scale_factor;
> +}
> +
>  #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1080
>  if (ctx->capture_cursor) {
>  capture_screen_input.capturesCursor = YES;
> @@ -1025,6 +1030,7 @@ static const AVOption options[] = {
>  { "video_size", "set video size", offsetof(AVFContext, width), 
> AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, AV_OPT_FLAG_DECODING_PARAM },
>  { "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM 
> },
>  { "capture_mouse_clicks", "capture the screen mouse clicks", 
> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "scale_factor", "scale screen factor range", offsetof(AVFContext, 
> scale_factor), AV_OPT_TYPE_FLOAT, {.dbl=1.0}, 0.0, 1.0, 
> AV_OPT_FLAG_DECODING_PARAM },
This is still a value and not a range.


>  
>  { NULL },
>  };
> 

Instead of having the others find your changes, you should comment on any 
raised questions rather than just adapting your code wherever things are non 
trivial.

Your patch misses to cover the scale factor in case of a device name string 
given by the user.

Do you have an idea why only 0.0 < scale_factor <= 1.0 is working correctly?
What happens for scale_factor == 0.0?
Although Apple's reference says it works for scale_factor > 1.0, it should be 
documented (at least in the code) that it seems not to actually do anything for 
scale_factor > 1.0.

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

[FFmpeg-devel] DXVA2 CreateVideoDecoder

[gabriele salvati]

Hi to all,

I'm working on DXVA2 video decoding, I'm facing a problem
with CreateVideoDecoder. I create a new video decoder every time a new
video have to be decoded. I noticed that when I release the video decoder
not all the allocated memory is properly released. By using VS2015 I found
the ~0.70 Kb are not released.

I take a look to the "memory usage" in VS2015 it reports that
CreateDecodeDeviceLH allocates memory that it's not released.

Someone else has noticed the same problem?

I'm using ffmpeg 3.2

thanks to everyone,

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

[FFmpeg-devel] Encoding less than a whole frame

[James Darnley]

I have a few vague questions I want to ask but keep in mind I have no
knowledge of FFmpeg's APIs.  It is my impression that encoding with
avcodec requires a whole picture to be given to the encoder at any time.

Has anyone ever started working on allowing avcodec to encode anything
less than a whole picture?  Does anyone know of anyone else ever
attempting similar work?

I think x264 allows this but it was long, long ago when I hung around
that project and I might be mis-remembering its features.  As an extreme
example the Dirac/VC2 encoder in avcodec could encode as little as 2
lines without needing the rest of the picture.

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

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[John Warburton]

On Mon, Aug 7, 2017 at 10:08 AM, Nicolas George  wrote:
>
> This issue seems fixed by these changes:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/214306.html
> ...
> Also, it would help deciding stuff if you, as a user, told us: if you
> had to write "scale=w=1536:h=512" instead of "scale=1536:512" to be
> completely sure that your scripts will not break on upgrade, would you
> consider that an unacceptable burden?

Thank you for letting me know about the incoming patch. Two of the
hunks failed to apply but I'll try sorting those out later (need to go
to a meeting right now).

The question about abbreviating parameters to filters: I am fine about
writing in the new way, but there are scripts run here regularly that
will need updating if the abbreviated form is lost. However, the
non-abbreviated form is far easier to read and, therefore, for others
to maintain.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_premultiply: add inplace mode

[Nicolas George]

Le septidi 17 thermidor, an CCXXV, Paul B Mahol a écrit :
> Hi,
> 
> patch attached.

> From f952d9a2c87f7c2387d509e986aee5adb424d9d2 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Fri, 4 Aug 2017 22:28:53 +0200
> Subject: [PATCH] avfilter/vf_premultiply: add inplace mode
> 
> ---
>  libavfilter/vf_premultiply.c | 195 
> +++
>  1 file changed, 142 insertions(+), 53 deletions(-)
> 
> diff --git a/libavfilter/vf_premultiply.c b/libavfilter/vf_premultiply.c
> index 9ecafe4..2b5348b 100644
> --- a/libavfilter/vf_premultiply.c
> +++ b/libavfilter/vf_premultiply.c
> @@ -22,6 +22,7 @@
>  #include "libavutil/pixdesc.h"
>  #include "libavutil/opt.h"
>  #include "avfilter.h"
> +#include "filters.h"
>  #include "formats.h"
>  #include "framesync2.h"
>  #include "internal.h"
> @@ -34,6 +35,7 @@ typedef struct PreMultiplyContext {
>  int nb_planes;
>  int planes;
>  int inverse;
> +int inplace;
>  int half, depth, offset, max;
>  FFFrameSync fs;
>  
> @@ -50,6 +52,7 @@ typedef struct PreMultiplyContext {
>  
>  static const AVOption options[] = {
>  { "planes", "set planes", OFFSET(planes), AV_OPT_TYPE_INT, {.i64=0xF}, 
> 0, 0xF, FLAGS },
> +{ "inplace","enable inplace mode", OFFSET(inplace), AV_OPT_TYPE_BOOL, 
> {.i64=0}, 0, 1, FLAGS },
>  { NULL }
>  };
>  
> @@ -58,7 +61,9 @@ AVFILTER_DEFINE_CLASS(premultiply);
>  
>  static int query_formats(AVFilterContext *ctx)
>  {
> -static const enum AVPixelFormat pix_fmts[] = {
> +PreMultiplyContext *s = ctx->priv;
> +
> +static const enum AVPixelFormat no_alpha_pix_fmts[] = {
>  AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVJ444P,
>  AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV444P10,
>  AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV444P14,
> @@ -69,7 +74,15 @@ static int query_formats(AVFilterContext *ctx)
>  AV_PIX_FMT_NONE
>  };
>  
> -return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
> +static const enum AVPixelFormat alpha_pix_fmts[] = {
> +AV_PIX_FMT_YUVA444P,
> +AV_PIX_FMT_YUVA444P9, AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_YUVA444P16,
> +AV_PIX_FMT_GBRAP,
> +AV_PIX_FMT_GBRAP10, AV_PIX_FMT_GBRAP12, AV_PIX_FMT_GBRAP16,
> +AV_PIX_FMT_NONE
> +};
> +
> +return ff_set_common_formats(ctx, ff_make_format_list(s->inplace ? 
> alpha_pix_fmts : no_alpha_pix_fmts));
>  }
>  
>  static void premultiply8(const uint8_t *msrc, const uint8_t *asrc,
> @@ -348,29 +361,23 @@ static void unpremultiply16offset(const uint8_t *mmsrc, 
> const uint8_t *aasrc,
>  }
>  }
>  
> -static int process_frame(FFFrameSync *fs)
> +static int filter_frame(AVFilterContext *ctx,
> +AVFrame **out, AVFrame *base, AVFrame *alpha)
>  {
> -AVFilterContext *ctx = fs->parent;
> -PreMultiplyContext *s = fs->opaque;
> +PreMultiplyContext *s = ctx->priv;
>  AVFilterLink *outlink = ctx->outputs[0];
> -AVFrame *out, *base, *alpha;
> -int ret;
> -
> -if ((ret = ff_framesync2_get_frame(>fs, 0, ,  0)) < 0 ||
> -(ret = ff_framesync2_get_frame(>fs, 1, , 0)) < 0)
> -return ret;
>  
>  if (ctx->is_disabled) {
> -out = av_frame_clone(base);
> -if (!out)
> +*out = av_frame_clone(base);
> +if (!*out)
>  return AVERROR(ENOMEM);
>  } else {
>  int p, full, limited;
>  
> -out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> -if (!out)
> +*out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> +if (!*out)
>  return AVERROR(ENOMEM);
> -av_frame_copy_props(out, base);
> +av_frame_copy_props(*out, base);
>  
>  full = base->color_range == AVCOL_RANGE_JPEG;
>  limited = base->color_range == AVCOL_RANGE_MPEG;
> @@ -378,6 +385,7 @@ static int process_frame(FFFrameSync *fs)
>  if (s->inverse) {
>  switch (outlink->format) {
>  case AV_PIX_FMT_YUV444P:
> +case AV_PIX_FMT_YUVA444P:
>  s->premultiply[0] = full ? unpremultiply8 : 
> unpremultiply8offset;
>  s->premultiply[1] = s->premultiply[2] = unpremultiply8yuv;
>  break;
> @@ -386,21 +394,28 @@ static int process_frame(FFFrameSync *fs)
>  s->premultiply[1] = s->premultiply[2] = unpremultiply8yuv;
>  break;
>  case AV_PIX_FMT_GBRP:
> +case AV_PIX_FMT_GBRAP:
>  s->premultiply[0] = s->premultiply[1] = s->premultiply[2] = 
> limited ? unpremultiply8offset : unpremultiply8;
>  break;
>  case AV_PIX_FMT_YUV444P9:
> +case AV_PIX_FMT_YUVA444P9:
>  case AV_PIX_FMT_YUV444P10:
> +case AV_PIX_FMT_YUVA444P10:
>  case AV_PIX_FMT_YUV444P12:
>  case AV_PIX_FMT_YUV444P14:
>  case AV_PIX_FMT_YUV444P16:
> +case AV_PIX_FMT_YUVA444P16:

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[Nicolas George]

Le decadi 20 thermidor, an CCXXV, Gyan a écrit :
> Obviously not for scripts written now or in the future by those who follow
> this list, but old/delivered scripts may break and often those executing
> them aren't the ones who composed them.

But I hope they test them after upgrading their version of ffmpeg.

> If the doc patch is being pushed, would you accept if I or others submitted
> abbreviated alternates for some of the long option names that exist e.g. as
> in loudnorm.

I see personally no objection, as long as the aliases are reasonable.
But it would eventually be up to the person who maintains each filter.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[Gyan]

On Mon, Aug 7, 2017 at 2:38 PM, Nicolas George  wrote:

>
> Also, it would help deciding stuff if you, as a user, told us: if you
> had to write "scale=w=1536:h=512" instead of "scale=1536:512" to be
> completely sure that your scripts will not break on upgrade, would you
> consider that an unacceptable burden?
>

Obviously not for scripts written now or in the future by those who follow
this list, but old/delivered scripts may break and often those executing
them aren't the ones who composed them.

If the doc patch is being pushed, would you accept if I or others submitted
abbreviated alternates for some of the long option names that exist e.g. as
in loudnorm.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add SSE2 simd for reorder pixels (WIP)

[Martin Vignali]

>
> 64 runs seems way too few runs for reliable result.
> Please try to run ffmpeg encoding for about a minute.
>
> About the patch:
>
> > +%include "libavutil/x86/x86util.asm"
> > +
> > +SECTION .text
>
> Please include "x86inc.asm" explicitly.
>
> > +INIT_XMM sse2
> > +cglobal reorder_pixels, 3,5,3, src, dst, size
> > +
> > +shrr2,1;half_size
>
> It's better to use the labels you define in the cglobal,
> If I count correctly, "r2" would be "sizeq".
> ("srcq" and "dstq" would be the correct labels for the pointers).
>
>
> > +;calc loop count for simd reorder
> > +movr3,r2;
> > +shrr3,4;calc loop count simd
>
> Align the instruction at 4 spaces.
> Align the first operands so that the ending commas are vertically aligned.
> For the follow up operands, just add one space after the comma.
>
> Put some spaces before the comment, to separate it from the operands.
> BTW, this is not C, you don't need to end every line with ";"
> e.g.
> > +mov  r3, r2
> > +shr  r3, 4  ;calc loop count simd
>
>
> > +;jump to afterloop2 if loop count simd is 0
> > +cmpr3,0;
> > +jleafterloop2;
>
> If you only check for size==0, then
> the "shr" has already set the correct Z flag.
>
> However, if r3/size==1, you'd still read
> 16 bytes at once in the first loop.
> Aka, overread.
>
>
> > +;simd loop
> > +loop1:
> > +movdqaxmm0,[r0];load first 16 bytes
>
> Use "m0" instead.
>
>
> > +lea r4, [r0 + r2];
> > +
> > +movdquxmm1, [r4]; unaligned load
>
> r4 doesn't seem to be used for anything else.
> Just move the address calculation directly into
> the "movdqu", it can take it.
>
> > +movdqa xmm2,xmm0;copy xmm0
> > +
> > +punpcklbw xmm2,   xmm1;
> > +movdqa [r1],   xmm2;
> > +add r1, 16;
>
> use "mmsize" instead of 16.
>
> > +movdqa xmm2,   xmm0;
> > +punpckhbw xmm2,   xmm1;
> > +movdqa[r1],   xmm2;
> > +addr1,16;
>
> You can actually avoid one of the "add"
> if you use [r1+mmsize] and add 32 at the second
> "add" (or 2*mmsize).
>
> > +decr3;
> > +addr0,16;
>
> > +; test repeat
> > +cmpr3,   0;
> > +jgeloop1;
>
> First, "dec" instructions are avoided,
> because they do a partial update
> on the flag register and
> this causes interdependence.
>
> Second, you can use the flags from
> the "sub" to check if it has reached
> zero or has gone negative.
>
>
> > +afterloop2:
> > +;scalar part
> > +
> > +mov r3, r2;
> > +and r3, 15 ;half_size % 16
> > +lea r4, [r0 + r2];
> > +
> > +;initial condition loop
> > +cmpr3,0;
> > +jleend;
> > +
> > +loop2:
> > +mov r1, r0;
> > +inc r1;
> > +mov r1, r4;
> > +inc r1;
> > +inc r0;
> > +inc r4;
> > +dec r3;
> > +; test repeat
> > +cmpr3,   0;
> > +jgloop2;
>
> O_o
> This loop does not read or write to memory.
>
> You can replace the second "cmp" in this
> loop with unconditional jump to the
> "initial condition loop" compare.
> (aka move loop2: two instruction above).
>
> This is how "for(;;)" is usually implemented in C compilers.
>
> Be sure to test your function with different sizes,
> to salt your output buffers and check for underwrites, overwrites
> etc...
>
> Best Regards.
>
>
> Thanks for your comments,

i will take a look, on all of this.

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

Re: [FFmpeg-devel] [PATCH 7/7] lavfi/vf_stack: move to activate design.

[Nicolas George]

Le nonidi 19 thermidor, an CCXXV, John Warburton a écrit :
> Gentlemen, I am sorry to report that this particular patch to
> lavfi/vf_stack.c breaks FFmpeg on-screen output when a vertical stack
> (vstack) follows a horizontal stack (hstack). Below, please find a
> chain to -filter_complex, cut down from a much more complex chain,
> that reproduces the problem.

This issue seems fixed by these changes:

https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/214306.html

I thought it could only be triggered with the specific configuration
caused by dualinput, but you obviously found another way.

The patches in this series need some review before being pushed.

Also, it would help deciding stuff if you, as a user, told us: if you
had to write "scale=w=1536:h=512" instead of "scale=1536:512" to be
completely sure that your scripts will not break on upgrade, would you
consider that an unacceptable burden?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

> >Lets take a step back and look at this
> >
> >There are some rarely used options in multi input filters like
> >overlay which break.
> >Noone even noticed except me
> >
> >And you propose to declare the most used syntax from every filter
> >unstable.
> >
> >This just doesnt add up, its like shooting the patient in the head as
> >a treatment for a cold

No, that is like telling the patient they need to take their antibiotics
until the last day of treatment and not stop once they feel better,
because they risk getting a pneumonia. Which is technically true, only
very unlikely.


Le decadi 20 thermidor, an CCXXV, Marton Balint a écrit :
> Do you like this text better?
> 
> Future evolutions of filters may require inserting new options or changing
> their order, especially for the non-essential options, and while we make
> reasonable effort to keep the order so the options given without their name
> would not break, sometimes that is not feasable. Therefore users should
> generally favor the @var{key=value} notation, or refer to the Changelog file
> which should contain such incompatible changes.

This is obviously the intent, but I do not think that the documentation
is the place to make that kind of intent statement.

> Yeah, what is needed for compatibility? Only a single AVOption line, or
> additional code as well?

Additional code as well. Not a lot, but still some. And testing. An
exponential number of cases.

I do not intend to do it.

We have already wasted more time than all the users combined will spend
typing "x=", "y=". Seriously, people !?!

Now, to all that stated a negative opinion about this:

I have in the queue a patch series that changes the options in a minor
way, but at the same time fixes bugs and long-standing limitations of
lavfi and makes the code more robust and cleaner.

Do you :

1. propose to implement and test compatibility options yourself?

2. own up you are blocking these enhancements?

3. accept the series and the breakage?

I will consider the absence of reply in a reasonable time as "4. do not
care".

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] JPEG200 encoding : added option for changing default codeblock size

[francesco]

From: Francesco Cuzzocrea 

HI
I think this time I've made correctly a patch. As in previous mail, I added
option for changing codeblock size. I've inserted check on exponent sum as for
ISO/IEC FCD 15444-1



---
 libavcodec/j2kenc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index c8d3861..63096ca 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1121,8 +1121,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 memset(codsty->log2_prec_heights, 15, sizeof(codsty->log2_prec_heights));
 codsty->nreslevels2decode=
 codsty->nreslevels   = 7;
-codsty->log2_cblk_width  = 4;
-codsty->log2_cblk_height = 4;
 codsty->transform= s->pred ? FF_DWT53 : FF_DWT97_INT;
 
 qntsty->nguardbits   = 1;
@@ -1131,6 +1129,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
 (s->tile_height & (s->tile_height-1))) {
 av_log(avctx, AV_LOG_WARNING, "Tile dimension not a power of 2\n");
 }
+i = codsty->log2_cblk_width + codsty->log2_cblk_height -4;
+if ( i > 12 )
+{
+  av_log(avctx, AV_LOG_ERROR, "Invalid values for codeblocks size\n");
+  return -1;
+}
 
 if (codsty->transform == FF_DWT53)
 qntsty->quantsty = JPEG2000_QSTY_NONE;
@@ -1188,6 +1192,8 @@ static const AVOption options[] = {
 { "pred",  "DWT Type",  OFFSET(pred),  
AV_OPT_TYPE_INT,   { .i64 = 0   }, 0, 1,   VE, "pred"   
 },
 { "dwt97int",  NULL,0, 
AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE, "pred"   
 },
 { "dwt53", NULL,0, 
AV_OPT_TYPE_CONST, { .i64 = 0   }, INT_MIN, INT_MAX,   VE, "pred"   
 },
+{ "log2_cblk_width",   "Codeblock Width",   
OFFSET(codsty.log2_cblk_width),AV_OPT_TYPE_INT,   { .i64 = 4   }, 
0, 1<<10,   VE, },
+{ "log2_cblk_height",  "Codeblock Height",  
OFFSET(codsty.log2_cblk_height),   AV_OPT_TYPE_INT,   { .i64 = 4   }, 
0, 1<<10,   VE, },
 
 { NULL }
 };
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Marton Balint]

On Mon, 7 Aug 2017, Michael Niedermayer wrote:


On Sun, Aug 06, 2017 at 10:37:35AM +0200, Nicolas George wrote:

L'octidi 18 thermidor, an CCXXV, James Almer a écrit :

What do you mean? What i suggested would be done each time an option is
removed or added anywhere but at the end, both of which afaik are
uncommon cases.
It's not something that requires a rewrite of the current codebase.


I mean that since I consider the break bearable (somebody upgrades a
piece of software, they MUST test the scripts that depend on it, and
fixing the issue once and for all is easy), I am not willing to spend my
time implementing (and testing, for this kind of thing that takes time)
the deprecation-warning-and-backward-compatibility dance.


Lets take a step back and look at this

There are some rarely used options in multi input filters like
overlay which break.
Noone even noticed except me

And you propose to declare the most used syntax from every filter
unstable.

This just doesnt add up, its like shooting the patient in the head as
a treatment for a cold


Do you like this text better?

Future evolutions of filters may require inserting new options or changing 
their order, especially for the non-essential options, and while we make 
reasonable effort to keep the order so the options given without their 
name would not break, sometimes that is not feasable. Therefore users 
should generally favor the @var{key=value} notation, or refer to the 
Changelog file which should contain such incompatible changes.




Please correct me if iam wrong, but isnt all that is needed to just
not remove the options from the AVOption array from the tiny number
of filters affected?
Or declare the tiny number of moved/changed options as removed/not
supported in shorthand notation.


Yeah, what is needed for compatibility? Only a single AVOption line, or 
additional code as well?


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

[FFmpeg-devel] [PATCH] Add FITS Muxer

[Paras Chadha]

Signed-off-by: Paras Chadha 
---
Added a new line in img2enc to add support for writing frames
into separate FITS files in a fashion similar to gif.
The following command can be used for that:
ffmpeg -i INPUT -c:v fits -f image2 "out%d.fits"

 libavformat/Makefile |   1 +
 libavformat/allformats.c |   2 +-
 libavformat/fitsenc.c| 183 +++
 libavformat/img2enc.c|   2 +
 4 files changed, 187 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/fitsenc.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 266b77a..faca4a0 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -165,6 +165,7 @@ OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
 OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
 OBJS-$(CONFIG_FILMSTRIP_MUXER)   += filmstripenc.o
 OBJS-$(CONFIG_FITS_DEMUXER)  += fitsdec.o
+OBJS-$(CONFIG_FITS_MUXER)+= fitsenc.o
 OBJS-$(CONFIG_FLAC_DEMUXER)  += flacdec.o rawdec.o \
 flac_picture.o   \
 oggparsevorbis.o \
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 3c12760..f3b2edb 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -121,7 +121,7 @@ static void register_all(void)
 REGISTER_MUXDEMUX(FFMETADATA,   ffmetadata);
 REGISTER_MUXER   (FIFO, fifo);
 REGISTER_MUXDEMUX(FILMSTRIP,filmstrip);
-REGISTER_DEMUXER (FITS, fits);
+REGISTER_MUXDEMUX(FITS, fits);
 REGISTER_MUXDEMUX(FLAC, flac);
 REGISTER_DEMUXER (FLIC, flic);
 REGISTER_MUXDEMUX(FLV,  flv);
diff --git a/libavformat/fitsenc.c b/libavformat/fitsenc.c
new file mode 100644
index 000..0dcdcdf
--- /dev/null
+++ b/libavformat/fitsenc.c
@@ -0,0 +1,183 @@
+/*
+ * FITS muxer
+ * Copyright (c) 2017 Paras Chadha
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * FITS muxer.
+ */
+
+#include "internal.h"
+
+typedef struct FITSContext {
+int first_image;
+} FITSContext;
+
+static int fits_write_header(AVFormatContext *s)
+{
+FITSContext *fitsctx = s->priv_data;
+fitsctx->first_image = 1;
+return 0;
+}
+
+/**
+ * Write one header line comprising of keyword and value(int)
+ * @param s AVFormat Context
+ * @param keyword pointer to the char array in which keyword is stored
+ * @param value the value corresponding to the keyword
+ * @param lines_written to keep track of lines written so far
+ * @return 0
+ */
+static int write_keyword_value(AVFormatContext *s, const char *keyword, int 
value, int *lines_written)
+{
+int len, ret;
+uint8_t header[80];
+
+len = strlen(keyword);
+memset(header, ' ', sizeof(header));
+memcpy(header, keyword, len);
+
+header[8] = '=';
+header[9] = ' ';
+
+ret = snprintf(header + 10, 70, "%d", value);
+header[ret + 10] = ' ';
+
+avio_write(s->pb, header, sizeof(header));
+*lines_written += 1;
+return 0;
+}
+
+static int write_image_header(AVFormatContext *s)
+{
+AVStream *st = s->streams[0];
+AVCodecParameters *encctx = st->codecpar;
+FITSContext *fitsctx = s->priv_data;
+uint8_t buffer[80];
+int bitpix, naxis, naxis3 = 1, bzero = 0, rgb = 0, lines_written = 0, 
lines_left;
+
+switch (encctx->format) {
+case AV_PIX_FMT_GRAY8:
+bitpix = 8;
+naxis = 2;
+break;
+case AV_PIX_FMT_GRAY16BE:
+bitpix = 16;
+naxis = 2;
+bzero = 32768;
+break;
+case AV_PIX_FMT_GBRP:
+case AV_PIX_FMT_GBRAP:
+bitpix = 8;
+naxis = 3;
+rgb = 1;
+if (encctx->format == AV_PIX_FMT_GBRP) {
+naxis3 = 3;
+} else {
+naxis3 = 4;
+}
+break;
+case AV_PIX_FMT_GBRP16BE:
+case AV_PIX_FMT_GBRAP16BE:
+bitpix = 16;
+naxis = 3;
+rgb = 1;
+if (encctx->format == AV_PIX_FMT_GBRP16BE) {
+naxis3 = 3;
+} else {
+naxis3 = 4;
+   

[FFmpeg-devel] [PATCH] Add FITS Encoder

[Paras Chadha]

Signed-off-by: Paras Chadha 
---
Moved header writing code to muxer
Made the changes suggested

 Changelog  |   1 +
 doc/general.texi   |   2 +-
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   2 +-
 libavcodec/fitsenc.c   | 130 +
 5 files changed, 134 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/fitsenc.c

diff --git a/Changelog b/Changelog
index 61414f8..4b7b41b 100644
--- a/Changelog
+++ b/Changelog
@@ -33,6 +33,7 @@ version :
 - tlut2 video filter
 - floodfill video filter
 - FITS demuxer and decoder
+- FITS muxer and encoder

 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/doc/general.texi b/doc/general.texi
index 01402cb..1ea7984 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -592,7 +592,7 @@ following image formats are supported:
 @tab Digital Picture Exchange
 @item EXR  @tab   @tab X
 @tab OpenEXR
-@item FITS @tab   @tab X
+@item FITS @tab X @tab X
 @tab Flexible Image Transport System
 @item JPEG @tab X @tab X
 @tab Progressive JPEG is not supported.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 42eec07..590410c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -292,6 +292,7 @@ OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
 OBJS-$(CONFIG_FFWAVESYNTH_DECODER) += ffwavesynth.o
 OBJS-$(CONFIG_FIC_DECODER) += fic.o
 OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o fits.o
+OBJS-$(CONFIG_FITS_ENCODER)+= fitsenc.o
 OBJS-$(CONFIG_FLAC_DECODER)+= flacdec.o flacdata.o flac.o
 OBJS-$(CONFIG_FLAC_ENCODER)+= flacenc.o flacdata.o flac.o 
vorbis_data.o
 OBJS-$(CONFIG_FLASHSV_DECODER) += flashsv.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 8678ac2..7fe66f4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -192,7 +192,7 @@ static void register_all(void)
 REGISTER_ENCDEC (FFV1,  ffv1);
 REGISTER_ENCDEC (FFVHUFF,   ffvhuff);
 REGISTER_DECODER(FIC,   fic);
-REGISTER_DECODER(FITS,  fits);
+REGISTER_ENCDEC (FITS,  fits);
 REGISTER_ENCDEC (FLASHSV,   flashsv);
 REGISTER_ENCDEC (FLASHSV2,  flashsv2);
 REGISTER_DECODER(FLIC,  flic);
diff --git a/libavcodec/fitsenc.c b/libavcodec/fitsenc.c
new file mode 100644
index 000..f67f3ad
--- /dev/null
+++ b/libavcodec/fitsenc.c
@@ -0,0 +1,130 @@
+/*
+ * FITS image encoder
+ * Copyright (c) 2017 Paras Chadha
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * FITS image encoder
+ *
+ * Specification: https://fits.gsfc.nasa.gov/fits_standard.html Version 3.0
+ *
+ * RGBA images are encoded as planes in RGBA order. So, NAXIS3 is 3 or 4 for 
them.
+ * Also CTYPE3 = 'RGB ' is added to the header to distinguish them from 3d 
images.
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+static int fits_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *pict, int *got_packet)
+{
+AVFrame * const p = (AVFrame *)pict;
+uint8_t *bytestream, *bytestream_start, *ptr;
+const uint16_t flip = (1 << 15);
+uint64_t data_size = 0, padded_data_size = 0;
+int ret, bitpix, naxis3 = 1, i, j, k, bytes_left;
+int map[] = {2, 0, 1, 3}; // mapping from GBRA -> RGBA as RGBA is to be 
stored in FITS file..
+
+switch (avctx->pix_fmt) {
+case AV_PIX_FMT_GRAY8:
+case AV_PIX_FMT_GRAY16BE:
+map[0] = 0; // grayscale images should be directly mapped
+if (avctx->pix_fmt == AV_PIX_FMT_GRAY8) {
+bitpix = 8;
+} else {
+bitpix = 16;
+}
+break;
+case AV_PIX_FMT_GBRP:
+case AV_PIX_FMT_GBRAP:
+bitpix = 8;
+if (avctx->pix_fmt == AV_PIX_FMT_GBRP) {
+naxis3 = 3;
+} else {
+naxis3 = 4;
+}
+break;
+case AV_PIX_FMT_GBRP16BE:
+case AV_PIX_FMT_GBRAP16BE:
+bitpix = 16;
+