good long-term API where the
information is eventually available outside.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
can define
things properly exactly like we need.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg
xtra parameter to the function.
> + *
> + * @param externalAlloc The function that will be called when a new buffer
> is required. This function can return
> + *NULL if it does not take care of allocating
> buffers of the provided size. In this case
s(+), 3 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-
| 2 +-
> libavfilter/buffersink.h | 2 +-
> libavfilter/version.h| 3 +++
> 3 files changed, 5 insertions(+), 2 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel
"I do
not like it"?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
f
it even more so
> with internal side data formats.
Please, there nothing of a black box about libavfilter.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.o
sizeof(buf) < 11 even though we
know that x is between 0 and 10.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsu
o.c
Thanks for the patch. I have not yet looked at the code itself.
Please include some documentation, it would be helpful even for
reviewing.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpe
coupling between filters and graphs to
> be limiting.
I would like to hear their arguments. Please let me know if you find
more accurate instances of these complaints.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffm
d fragment part and performing
%-unescaping; keep file: without the double slash as an alias for
fs:.
4. For some more time, warn users if they are using file: but not
file://.
5. Remove the compatibility file: → fs: alias.
Regards,
--
Nicolas George
signature.asc
Descrip
Nicolas George (12021-03-21):
> By the way, about that: at some point, we will need to clarify what part
> of our API uses real URLs and what parts uses fake URLs.
>
> Because as it is, a lot of code looks like it uses URLs but really it
> does not. The worst offender is "fil
: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffwavesynth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
No objection.
Regards,
--
Nicolas George
rocess
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/sbgdec.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
No objection.
Regards,
--
Nicolas George
; +if (idx < 0)
> + return AVERROR(ENOENT);
> +
> +memcpy(index_entry, &st->internal->index_entries[idx],
> sizeof(*index_entry));
Same, of course.
> +
> +return 0;
> +}
> +
> static int64_t ff_read_timestamp(AVFormatContext *s, int stream_in
dexEntry) part of the ABI just disappears
if we do that.
May I suggest that you recalibrate your dislike?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Nicolas George (12021-03-23):
> And it is exactly what we are doing when we let users access fields
> directly.
I mean:
AVStream **streams = ctx->streams;
av_read_frame(ctx, &packet);
AVStream *stream = streams[packet.stream_index];
That should work, ri
we choose the second, because the first is not really possible.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
ere will help you gratis to take our
public free code so that you can use with your private proprietary code.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.
simple.
This is by far the simplest and most efficient solution for both you and
our users.
So why reject it?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.o
on, but you will need a little more work to convince me that
this is better than just returning the pointer. You make more work for
yourself and more work for the user, you have to have a good reason for
it.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
veloper wants to chime in and comment which approach they
> prefer, then that would be ideal.
Indeed.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Andreas Rheinhardt (12021-03-26):
> Will apply.
Sorry, missed it.
How does it impact the performance? Or even better: code? This code is
meant to be as fast as possible.
Regards,
--
Nicolas George
signature.asc
Description: PGP signat
> casting to unsigned).)
Thank you. Then ok, of course.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
obtained through malloc().
So, worst case scenario, we can use this construct to work around a
compiler that does stupid optimizations.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel
ation has already finished using them, or
does not use them at all?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsub
anyway, it is a good time to
decide if we want to change something.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To uns
having a function to get the packet rather than just a
pointer gives us more freedom to extend the API later.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://f
d
trust the users to use it properly to access the fields they need,
without speculating.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link a
u are writing new C code with explicit references to long or short,
you are almost certainly doing it wrong.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg
oxes);
}
#define AV_BOUNDING_BOX_GET(header, idx) \
((AVBoundingBox *)((char *)(header) + (header)->bboxes_offset + (idx) *
(header)->bboxes_step))
You can do the same to lift the 128 limit on the name.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
_
lpers on both are the same (The standard alloc,
> and the alloc + wrapping into frame side data ones).
I agree with this.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
optimization.
This is not a variable-length array but a pointer to a variable-length
array, it does not cause the optimization problems. As it is, it is just
a trick to let the compiler compute offsets for us taking into account
alignment requirements.
Regards,
--
Nicolas George
James Almer (12021-04-05):
> Lavd is supposed to be either merged into lavf, or rewritten to
> stop depending on lavf
The second one is out of question in the short term, it has already been
discussed.
Regards,
--
Nicolas George
signature.asc
Description: PGP sig
nstraint "only valid until the next function call on the same
structure" is not the most common, nor the least dangerous, but it is
not exceptional at all. And in this case, it is by far both the most
simple and the most efficient solution.
Regards,
--
If people agree with my analysis that pointers to VLA used to compute
sizes and offsets in an isolated function are not a problem, unlike
actual VLAs on the stack, then we can just remove it. I do not think we
are at risk of adding VLAs by mistake.
Regards,
--
Nicolas George
signature.asc
Descrip
make sure).
Too bad.
Can you document which compilers they are? This is an information that
should be centralized.
We will have have a backup implementation.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel ma
ntually for whoever writes it to decide.
Also, assuming the alignment is the same as the size is rather a safe
assumption for elementary types.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
f
have a
pointer to do the actual arithmetic on, but here we have, and we define
the offset by the exact difference between the pointer we want.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing li
Derek Buitenhuis (12021-04-07):
> We should not be using them as a matter of good practice, as well, IMO.
Please follow the discussion. Good practice decourages VLA on the stack,
not pointers to VLA.
Regards,
--
Nicolas George
signature.asc
Description: PGP signat
too much
of the stack in an unexpected way, and (2) they require extra registers
that ruin optimization in the whole function.
Obviously, it does not apply to pointers to VLA.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
_
Jean-Baptiste Kempf (12021-04-07):
> I don't think this is a good idea.
Can you explain the problems about VLA that I do not know about?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing lis
Anton Khirnov (12021-04-08):
> Does this mean that there are no stability guarantees for metadata
> exported by filters?
We can have stability for the components that are good enough to be
stable, and no stability yet for components that need enhancing.
Regards,
--
Nicolas
> So, we need frame_width and frame_height here.
But the crop or pad filters will also invalidate the information, and in
a different way. How should frame_width and frame_height be used to
solve all?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
_
r with the jargon of any particular sub-field. The
specialists of the particular subfield are supposed to be more capable
of adjusting.
Also, I have observed that the jargon of a narrow field is frequently
made of awful misnomers kept more as cargo cult than for any good
reason.
Regards,
-
avfilter/avfilter.c | 82 ++
> libavfilter/version.h | 3 --
> 2 files changed, 3 insertions(+), 82 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel
| 3 ---
> 3 files changed, 9 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit lin
---
> 3 files changed, 18 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abo
filter/avfilter.h | 35 ---
> libavfilter/version.h| 3 ---
> 3 files changed, 76 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmp
---
> 3 files changed, 18 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abo
rmats.h | 4
> 2 files changed, 11 deletions(-)
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscri
---
> libavfilter/transform.h | 29 +
> libavfilter/vf_deshake.c | 5 +++--
> 3 files changed, 5 insertions(+), 52 deletions(-)
Should be ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpe
James Almer (12021-04-19):
> From: Andreas Rheinhardt
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/Makefile | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Should be ok.
Regards,
--
Nicolas George
signature.asc
Descript
James Almer (12021-04-19):
> It was depreacted less than two years ago
>
> Signed-off-by: James Almer
> ---
> libavfilter/version.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
No objection.
Regards,
--
Nicolas George
signature.asc
Descript
Andreas Rheinhardt (12021-04-19):
> This is possible now that the next-API is gone.
>
> Signed-off-by: Andreas Rheinhardt
Ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffm
me side data should not happen.
Somebody remembers it?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit lin
e for all votes, AFAIK, we only
agreed on the procedure for the first vote. Having a procedure already
implemented and in the official Git source tree would be pretty
disloyal.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
tstrap is a
good idea, but using an automatic commit count for future evolutions is
a bad idea.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/li
quot;Attempt recovery regardless of type of the
> error", OFFSET(recover_any_error),
> AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>
> +{"output_delay", "Time to delay output, in microseconds",
> OFFSET(output_delay),
> + AV
t; +fifo->start_time = av_gettime_relative();
> +
> return 0;
> }
>
> @@ -637,6 +653,9 @@ static const AVOption options[] = {
> {"output_delay", "Time to delay output, in microseconds",
> OFFSET(output_delay),
> AV_OPT_TYPE_INT, {.i64 =
s a little reflection to see it is correct. Not much, but more than
(s / 6) % 60.
Also, you are using PRId64 tu print numbers between 0 and 1000.
> +avio_printf(avf->pb, "%d\n", srt->index);
> +srt_write_time(avf->pb, s);
> +avio_printf(avf->pb, &qu
u test your change?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
rc));
> +}
> }
> +if (size > skip)
Same as previous: just skipping the work when the buffer is not big
enough seems broken.
> avio_write(pb, buf + skip, size - skip);
>
> if (keep_buffer) {
Regards,
--
Nicolas George
signature.asc
Descriptio
f);
>
> if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX)
This one seems broken like the other two.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Limin Wang (12020-04-29):
> Sorry, the idea is coming from webvtt_write_time()
Well, I do not like Matthew Heaney's style. Everybody can use their
preferred style in their own files, of course.
Regards,
--
Nicolas George
signature.asc
Description: PGP s
to do something, and with
your change it does not do it.
These changes are therefore not acceptable.
The invalid access need to be fixed, but they need to be fixed properly:
since they correspond to a memory allocation failure, there should be
some kind of AVERROR(ENOMEM) in there.
Regards,
ust regular contributors to have tested their changes
and run FATE before submitting patches.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailma
ses an on-stack
buffer as long as it fits (it is based on BPrint).
I have a small intro written about it if people are interested.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
r this kind of thing. Can I count
on your support when I propose it again?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
T
he library, and links like that happen automatically.)
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit l
Carl Eugen Hoyos (12020-05-01):
> This patch is not ok, please split it.
What benefit would it serve?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.
s more like a sales pitch to me. "this
encoder has become the default and is the recommended choice" could be
in an encoding guide, but it has nothing to do in a reference
documentation.
Regards,
--
Nicolas George
signature.asc
Descriptio
perhaps a better solution is to ignore
> side data extradata if it's already been written once?
Would it not lead to a corrupted file, possibly unplayable?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel
users.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.o
hings. I'm
> not well versed in aac details.
Then for now, I would say that we can only accept when it is
bit-identical with the extradata already there. If we cannot test for
compatibility more finely, then we have to assume incompatibility and
reject every AV_PKT_DATA_NEW_EXTR
open a dialog "Data successfully
saved. Delete original? [Yes] No" and let actual data be lost.
We can have an option to ignore the error, but as it is, it really must
be an error condition by default. Exactly the same as a write error on
the file.
Regards,
--
Nicolas George
signature.
as before.
I thin it could work:
void *free_funcp = &mq->free_func; // pointer to data
and in free_func_wrap():
void (*free_func)(void *) = *((void (*)(void *)) *)arg;
But that needs testing.
Do we support an arch where function pointers are different?
Regards,
--
Nicolas Geor
t seems annoying:
misunderstanding on purpose used as a sarcasm. If you were feeling
offended, it was an understandable reaction, but it can still be felt as
annoying if there was no intent to offense.
Can we please assume goodwill unless we have strong evidence otherwise?
Regards,
--
Nicolas Ge
Carl Eugen Hoyos (12020-05-02):
> Could you tell me where free_func() is used as a void *?
> I don't see it.
You are right, I misread. The problem is even simpler: why is there an
intermediate variable in the first place? Just test mq->free_func
directly.
Regards,
--
Carl Eugen Hoyos (12020-05-02):
> My guess is to avoid a race condition.
Avoid a race condition is: take local variable, unlock, use local
variable. Here it is take local variable, lock, use local variable.
Regards,
--
Nicolas George
signature.asc
Description: PGP signat
, that is changing the whole logic. At the
very least, th commit message should say that.
But your changes seemed a little more invasive than that, for example
renaming functions.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
t;
> doc/examples/transcoding.c | 106 +++--
> 1 file changed, 55 insertions(+), 51 deletions(-)
Again, >100 lines changed, that's not fixing a compilation warning.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
_
lance.lmw...@gmail.com (12020-05-02):
> will apply the patch set tomorrow if no comments.
I lost track of all these patches, I thought the options were to be
changed to AV_OPT_TYPE_DURATION.
Regards,
--
Nicolas George
signature.asc
Description: PGP signat
64 deletions(-)
Same remark as for the other similar patches: it is not fixing a
warning, it changing the whole logic.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:
Marton Balint (12020-05-02):
> That would break existing command lines...
Then a reasonable transition plan needs to be prepared. Not blocking for
this patch, though.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffm
.com/
It still needs to be changed, just properly: introduce a new option,
warn about deprecation.
It would have been simpler to catch it in the beginning :-(
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mai
| 5 +++
> 3 files changed, 83 insertions(+), 4 deletions(-)
I do not have any objection to this version, but I do not maintain that
code, nor do I know it very well.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
lance.lmw...@gmail.com (12020-05-02):
> The most important is document, I think current option is OK to use.
> deprecation is more confusing.
An option with the wrong type is confusing too. But deprecation is
temporary.
Regards,
--
Nicolas George
signature.asc
Description: PGP sig
e patch make it harder to review. You could
name the merged function write_any_frame().
And if you think it is best, make another patch to rename both
functions: it would be easier to review.
Regards,
--
Nicolas George
signature.asc
Description
date to new encoding API" would
be fine.
The warning is a minor detail, it's just the thing that told you this
was needed.
But see James' message.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mai
what I observed in the rest of the code.
> ret = get_aac_sample_rates(s, side_data, side_data_size,
> &track->sample_rate,
> &output_sample_rate);
> if (ret < 0)
Thanks, I think it does the right thing.
Regards,
--
ill start on 20:10, but the subtitles will start from 00:00.
You can use -copyts to keep the timestamps of the video matching with
the subtitles.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ff
T16_MAX + 1), INT16_MAX, .flags =
> > FLAGS },
> > +
> > +{ NULL },
> > +};
>
> You are using an AV_OPT_TYPE_INT parameter, yet the actual type of the
> destination is int64_t. This won't work on big endian systems. Make gain
> an int.
Or make it a float and multiply it
t duplicate a word of it.
Normal users will follow the link, because they need the syntax anyway.
Lazy users can go use a GUI.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Lynne (12020-05-05):
> Pushed.
I find rather rude that you did not even acknowledge the suggestion in
this mail:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262151.html
--
Nicolas George
signature.asc
Description: PGP signature
___
ffm
ou among the developers who would be favorable to merging
the shared objects to avoid gratuitous issues of ABI compatibility?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:
l = 8; /* Main */
> @@ -205,7 +205,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
> if (s->drop_frame_timecode && s->frame_rate_index != 4) {
> av_log(avctx, AV_LOG_ERROR,
> "Drop frame time code only allowed wi
invent a new error code. One would be fixed later, the other
not.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsub
return -1;
> +return AVERROR(EINVAL);
> }
> s->out_format = FMT_H261;
> avctx->delay = 0;
> @@ -798,7 +799,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> break;
> case AV_CODEC_ID_H263:
> if (!CONFIG_H263_ENC
let
the caller print the error message.
Third design mistake: hard-coded use of goto.
Best design:
#define FF_ALLOC_ARRAY_OR_GOTO(p, nelem, elsize, ret, error)\
{\
p = av_malloc_array(nelem, elsize);\
if (!p) {\
ret = AVERROR(ENOMEM); \
error;
}\
}
Regards,
--
Nicolas
601 - 700 of 5032 matches
Mail list logo
