Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec.c:flush pes buffer while rtsp seek
> On Nov 14, 2022, at 15:46, tanwei (D) wrote:
>
> Fixes ticket #9949.
>
> Signed-off-by: tanwei123
> ---
> libavformat/mpegts.c| 20
> libavformat/mpegts.h| 1 +
> libavformat/rtpdec.c| 7 +++
> libavformat/rtpdec.h| 2 ++
> libavformat/rtpdec_mpegts.c | 11 +++
> libavformat/rtspdec.c | 11 +++
> 6 files changed, 52 insertions(+)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index d97702fcd7..c5472bb464 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -3419,6 +3419,26 @@ int avpriv_mpegts_parse_packet(MpegTSContext *ts,
> AVPacket *pkt,
> return len1 - len;
> }
>
> +void avpriv_mpegts_seek_flush(MpegTSContext *ts)
avpriv_ is meant to be exported symbols which can be called from
other libs. ff_ prefix should be fine.
> +{
> +int i;
> +/* flush pes buffer */
> +for (i = 0; i < NB_PID_MAX; i++) {
> +if (ts->pids[i]) {
> +if (ts->pids[i]->type == MPEGTS_PES) {
> +PESContext *pes = ts->pids[i]->u.pes_filter.opaque;
> +av_buffer_unref(&pes->buffer);
> +pes->data_index = 0;
> +pes->state = MPEGTS_SKIP; /* skip until pes header */
> +} else if (ts->pids[i]->type == MPEGTS_SECTION) {
> +ts->pids[i]->u.section_filter.last_ver = -1;
> +}
> +ts->pids[i]->last_cc = -1;
> +ts->pids[i]->last_pcr = -1;
> +}
> +}
> +}
> +
> void avpriv_mpegts_parse_close(MpegTSContext *ts)
> {
> mpegts_free(ts);
> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> index a48f14e768..b6f19e96bb 100644
> --- a/libavformat/mpegts.h
> +++ b/libavformat/mpegts.h
> @@ -170,6 +170,7 @@ MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext
> *s);
> int avpriv_mpegts_parse_packet(MpegTSContext *ts, AVPacket *pkt,
>const uint8_t *buf, int len);
> void avpriv_mpegts_parse_close(MpegTSContext *ts);
> +void avpriv_mpegts_seek_flush(MpegTSContext *ts);
>
> typedef struct SLConfigDescr {
> int use_au_start;
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> index fa7544cc07..d688afd1c1 100644
> --- a/libavformat/rtpdec.c
> +++ b/libavformat/rtpdec.c
> @@ -954,6 +954,13 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket
> *pkt,
> return rv ? rv : has_next_packet(s);
> }
>
> +void ff_rtp_seek_flush(RTPDemuxContext *s)
> +{
> +ff_rtp_reset_packet_queue(s);
> +if (s->handler && s->handler->seek_flush)
> +s->handler->seek_flush(s->dynamic_protocol_context);
> +}
> +
> void ff_rtp_parse_close(RTPDemuxContext *s)
> {
> ff_rtp_reset_packet_queue(s);
> diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
> index 5a02e72dc2..8d6d857e28 100644
> --- a/libavformat/rtpdec.h
> +++ b/libavformat/rtpdec.h
> @@ -52,6 +52,7 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket *pkt,
> void ff_rtp_parse_close(RTPDemuxContext *s);
> int64_t ff_rtp_queued_packet_time(RTPDemuxContext *s);
> void ff_rtp_reset_packet_queue(RTPDemuxContext *s);
> +void ff_rtp_seek_flush(RTPDemuxContext *s);
>
> /**
> * Send a dummy packet on both port pairs to set up the connection
> @@ -135,6 +136,7 @@ struct RTPDynamicProtocolHandler {
> /** Parse handler for this dynamic packet */
> DynamicPayloadPacketHandlerProc parse_packet;
> int (*need_keyframe)(PayloadContext *context);
> +void (*seek_flush)(PayloadContext *protocol_data);
> };
>
> typedef struct RTPPacket {
> diff --git a/libavformat/rtpdec_mpegts.c b/libavformat/rtpdec_mpegts.c
> index 405271f744..6e9abcae08 100644
> --- a/libavformat/rtpdec_mpegts.c
> +++ b/libavformat/rtpdec_mpegts.c
> @@ -47,6 +47,16 @@ static av_cold int mpegts_init(AVFormatContext *ctx, int
> st_index,
> return 0;
> }
>
> +static void mpegts_seek_flush(PayloadContext *data)
> +{
> +if (!data)
> +return;
> +memset(data->buf, 0, data->read_buf_size);
> +data->read_buf_size = 0;
> +if (data->ts)
> +avpriv_mpegts_seek_flush(data->ts);
> +}
> +
> static int mpegts_handle_packet(AVFormatContext *ctx, PayloadContext *data,
> AVStream *st, AVPacket *pkt, uint32_t
> *timestamp,
> const uint8_t *buf, int len, uint16_t seq,
> @@ -94,6 +104,7 @@ const RTPDynamicProtocolHandler ff_mpegts_dynamic_handler
> = {
> .priv_data_size= sizeof(PayloadContext),
> .parse_packet = mpegts_handle_packet,
> .init = mpegts_init,
> +.seek_flush= mpegts_seek_flush,
> .close = mpegts_close_context,
> .static_payload_id = 33,
> };
> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> index bbabec7db8..f743fac2ee 100644
> --- a/libavformat/rtspdec.c
> +++ b/libavformat/rtspdec.c
> @@ -36,6 +36,7 @@
> #include "rdt.h"
> #include "tls.h"
> #include "url.h"
> +#include "mpegts.h"
> #include "version.h"
>
> sta
Re: [FFmpeg-devel] [PATCH v2 5/5] all: Guard if (EXTERNAL*) checks with #if HAVE_X86ASM
Hi, I preferred to check instead for HAVE_X86ASM, as those checks would only hit on either a missing or crippled NASM. Moreover, the EXTERNAL_ macros do both the HAVE__EXTERNAL and the runtime CPU flag check. The former of which would become redundant and duplicated with your suggestion. Should I move forward anyway with it? On 03/11/2022 12:55, dev at lynne.ee (Lynne) wrote: > Nov 3, 2022, 16:30 by amy at amyspark.me: > >> Continuation of 40e6575aa3eed64cd32bf28c00ae57edc5acb25a >> >> Signed-off-by: L. E. Segovia <> amy at amyspark.me> > >> > > Wrong way to fix it. Makefile to prevent compilation + ifdef guards > on all arch-specific init function calls. > -- amyspark 🌸 https://www.amyspark.me ___ 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".
[FFmpeg-devel] [PATCH 1/4] doc/developer.texi: improve the introductory text
Remove confusing references to "external" vs. "internal" developers.
---
doc/developer.texi | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index addee0d826..5cf3b19ee0 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -10,13 +10,19 @@
@contents
-@chapter Notes for external developers
+@chapter Introduction
-This document is mostly useful for internal FFmpeg developers.
-External developers who need to use the API in their application should
-refer to the API doxygen documentation in the public headers, and
-check the examples in @file{doc/examples} and in the source code to
-see how the public API is employed.
+This text is concerned with the development @emph{of} FFmpeg itself.
Information
+on using the FFmpeg libraries in other programs can be found elsewhere, e.g.
in:
+@itemize @bullet
+@item
+the installed header files
+@item
+@url{http://ffmpeg.org/doxygen/trunk/index.html, the Doxygen documentation}
+generated from the headers
+@item
+the examples under @file{doc/examples}
+@end itemize
You can use the FFmpeg libraries in your commercial program, but you
are encouraged to @emph{publish any patch you make}. In this case the
--
2.35.1
___
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".
[FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Stop talking about commercial programs, since this applies to any
downstream user.
---
doc/developer.texi | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index 5cf3b19ee0..2f0d2b7daa 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -24,11 +24,21 @@ generated from the headers
the examples under @file{doc/examples}
@end itemize
-You can use the FFmpeg libraries in your commercial program, but you
-are encouraged to @emph{publish any patch you make}. In this case the
-best way to proceed is to send your patches to the ffmpeg-devel
-mailing list following the guidelines illustrated in the remainder of
-this document.
+If you modify FFmpeg code for your own use case, you are highly encouraged to
+@emph{submit your changes back to us}, using this document as a guide. There
are
+both pragmatic and ideological reasons to do so:
+@itemize @bullet
+@item
+Maintaining external changes to keep up with upstream development is
+time-consuming and error-prone. With your code in the main tree, it will be
+maintained by FFmpeg developers.
+@item
+FFmpeg developers include leading experts in the field who can find bugs or
+design flaws in your code.
+@item
+By supporting the project you find useful you ensure it continues to be
+maintained and developed.
+@end itemize
For more detailed legal information about the use of FFmpeg in
external programs read the @file{LICENSE} file in the source tree and
--
2.35.1
___
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".
[FFmpeg-devel] [PATCH 3/4] doc/developer.texi: demote the "contributing" chapter to a section
It is very short and its main functions is linking to the
coding rules/submitting patches chapters.
---
doc/developer.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index 2f0d2b7daa..2e050edc6a 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -44,7 +44,7 @@ For more detailed legal information about the use of FFmpeg in
external programs read the @file{LICENSE} file in the source tree and
consult @url{https://ffmpeg.org/legal.html}.
-@chapter Contributing
+@section Contributing code
There are 2 ways by which code gets into FFmpeg:
@itemize @bullet
--
2.35.1
___
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".
[FFmpeg-devel] [PATCH 4/4] doc/developer.texi: refine the "contributing code" section
Drop the reference to directly committing code, because
- it is highly discouraged and very rarely done these days
- there is no good reason NOT to submit patches for review
Add a link to the development policy chapter.
---
doc/developer.texi | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index 2e050edc6a..cf918ac6b1 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -46,15 +46,10 @@ consult @url{https://ffmpeg.org/legal.html}.
@section Contributing code
-There are 2 ways by which code gets into FFmpeg:
-@itemize @bullet
-@item Submitting patches to the ffmpeg-devel mailing list.
- See @ref{Submitting patches} for details.
-@item Directly committing changes to the main tree.
-@end itemize
-
-Whichever way, changes should be reviewed by the maintainer of the code
-before they are committed. And they should follow the @ref{Coding Rules}.
+All proposed code changes should be submitted for review to
+@url{mailto:ffmpeg-devel@@ffmpeg.org, the development mailing list}, as
+described in more detail in the @ref{Submitting patches} chapter. The code
+should comply with the @ref{Development Policy} and follow the @ref{Coding
Rules}.
The developer making the commit and the author are responsible for their
changes
and should try to fix issues their commit causes.
@@ -267,6 +262,7 @@ For Emacs, add these roughly equivalent lines to your
@file{.emacs.d/init.el}:
(setq c-default-style "ffmpeg")
@end lisp
+@anchor{Development Policy}
@chapter Development Policy
@section Patches/Committing
--
2.35.1
___
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".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Quoting Michael Niedermayer (2022-11-10 20:52:33) > On Thu, Nov 10, 2022 at 01:31:44PM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2022-11-10 13:28:27) > > > On Tue, Nov 08, 2022 at 12:25:47PM +0100, Anton Khirnov wrote: > > > > Lavf only supports a very limited approximation of non-blocking > > > > behavior, so we should not return random EAGAINs to callers unless they > > > > specifically requested it. > > > > --- > > > > libavformat/demux.c | 8 ++-- > > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > this changes seeking behavior of for example: > > > libavformat/tests/seek fate-suite/dss/sp.dss > > > > > > (this seemed to return EAGAIN before sometimes) > > > > Are you saying that is wrong? I don't see why seeks should return EAGAIN > > either. > > I do not know if its wrong or not. I remember some seeking used error > returns to switch to generic seeking and such stuff. > I just reporrted this as i saw a difference in the tests/seek output AFAICT the differences are only in av_read_frame() calls, which no longer return EAGAIN. That is exactly what this patch is supposed to do, so I'd say there is no problem. If noone has further objections, I'll push this patch soonish. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 14/20] fftools/ffmpeg_mux_init: drop a duplicated block in copy_metadata()
Will push the rest of this set soonish if noone has further comments. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 10:13 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the
> argument for submitting patches
>
> Stop talking about commercial programs, since this applies to any
> downstream user.
> ---
> doc/developer.texi | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 5cf3b19ee0..2f0d2b7daa 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -24,11 +24,21 @@ generated from the headers
> the examples under @file{doc/examples}
> @end itemize
>
> -You can use the FFmpeg libraries in your commercial program, but you
> -are encouraged to @emph{publish any patch you make}. In this case
> the
> -best way to proceed is to send your patches to the ffmpeg-devel
> -mailing list following the guidelines illustrated in the remainder
> of
> -this document.
> +If you modify FFmpeg code for your own use case, you are highly
> encouraged to
> +@emph{submit your changes back to us}, using this document as a
> guide. There are
> +both pragmatic and ideological reasons to do so:
> +@itemize @bullet
> +@item
> +Maintaining external changes to keep up with upstream development is
> +time-consuming and error-prone. With your code in the main tree, it
> will be
> +maintained by FFmpeg developers.
You should mention that sometimes it's not really worth to take the effort,
because waiting for reviews and permanent rebasing and re-submitting,
explaining, defending, getting insulted or ignored and whatsoever,
might end up taking much more time than just to keep and maintain your
changes privately. Eventually you might regret that you have even
started going that way.
Regards,
softworkz
___
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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Quoting Soft Works (2022-11-14 10:35:40)
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Anton Khirnov
> > Sent: Monday, November 14, 2022 10:13 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the
> > argument for submitting patches
> >
> > Stop talking about commercial programs, since this applies to any
> > downstream user.
> > ---
> > doc/developer.texi | 20 +++-
> > 1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 5cf3b19ee0..2f0d2b7daa 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -24,11 +24,21 @@ generated from the headers
> > the examples under @file{doc/examples}
> > @end itemize
> >
> > -You can use the FFmpeg libraries in your commercial program, but you
> > -are encouraged to @emph{publish any patch you make}. In this case
> > the
> > -best way to proceed is to send your patches to the ffmpeg-devel
> > -mailing list following the guidelines illustrated in the remainder
> > of
> > -this document.
> > +If you modify FFmpeg code for your own use case, you are highly
> > encouraged to
> > +@emph{submit your changes back to us}, using this document as a
> > guide. There are
> > +both pragmatic and ideological reasons to do so:
> > +@itemize @bullet
> > +@item
> > +Maintaining external changes to keep up with upstream development is
> > +time-consuming and error-prone. With your code in the main tree, it
> > will be
> > +maintained by FFmpeg developers.
>
> You should mention that sometimes it's not really worth to take the effort,
> because waiting for reviews and permanent rebasing and re-submitting,
> explaining, defending, getting insulted or ignored and whatsoever,
> might end up taking much more time than just to keep and maintain your
> changes privately. Eventually you might regret that you have even
> started going that way.
Sorry, but you problems are entirely self-inflicted. You have been told
what changes need to happen right from the beginning, repeatedly, and by
several developers independently. Instead of implementing them you chose
to compose ever-more-elaborate explanations and justifications that, as
far as I can tell, boil down to "doing things properly is too much
work". Seems to me that actually doing this work would take less time
than you have already spent arguing.
--
Anton Khirnov
___
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".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Anton Khirnov (12022-11-14): > If noone has further objections, I'll push this patch soonish. You will do no scu thing since it is bogus, as I explained. -- 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 10:53 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
>
> Quoting Soft Works (2022-11-14 10:35:40)
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Anton Khirnov
> > > Sent: Monday, November 14, 2022 10:13 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the
> > > argument for submitting patches
> > >
> > > Stop talking about commercial programs, since this applies to any
> > > downstream user.
> > > ---
> > > doc/developer.texi | 20 +++-
> > > 1 file changed, 15 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index 5cf3b19ee0..2f0d2b7daa 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -24,11 +24,21 @@ generated from the headers
> > > the examples under @file{doc/examples}
> > > @end itemize
> > >
> > > -You can use the FFmpeg libraries in your commercial program, but
> you
> > > -are encouraged to @emph{publish any patch you make}. In this
> case
> > > the
> > > -best way to proceed is to send your patches to the ffmpeg-devel
> > > -mailing list following the guidelines illustrated in the
> remainder
> > > of
> > > -this document.
> > > +If you modify FFmpeg code for your own use case, you are highly
> > > encouraged to
> > > +@emph{submit your changes back to us}, using this document as a
> > > guide. There are
> > > +both pragmatic and ideological reasons to do so:
> > > +@itemize @bullet
> > > +@item
> > > +Maintaining external changes to keep up with upstream
> development is
> > > +time-consuming and error-prone. With your code in the main tree,
> it
> > > will be
> > > +maintained by FFmpeg developers.
> >
> > You should mention that sometimes it's not really worth to take the
> effort,
> > because waiting for reviews and permanent rebasing and re-
> submitting,
> > explaining, defending, getting insulted or ignored and whatsoever,
> > might end up taking much more time than just to keep and maintain
> your
> > changes privately. Eventually you might regret that you have even
> > started going that way.
>
> Sorry, but you problems are entirely self-inflicted. You have been
> told
> what changes need to happen right from the beginning, repeatedly, and
> by
> several developers independently.
And those are completed and settled, like I had state multiple times.
It's ready for review for months already.
softworkz
___
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".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Quoting Nicolas George (2022-11-14 11:44:55) > Anton Khirnov (12022-11-14): > > If noone has further objections, I'll push this patch soonish. > > You will do no scu thing since it is bogus, as I explained. I do not see any objections from you to this patch. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Anton Khirnov (12022-11-14): > I do not see any objections from you to this patch. My explanations for the other patch apply to this one, obviously: if you treat EAGAIN as REDO, you introduce a busy wait. -- 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Quoting Soft Works (2022-11-14 11:46:49) > > Sorry, but you problems are entirely self-inflicted. You have been > > told what changes need to happen right from the beginning, > > repeatedly, and by several developers independently. > > And those are completed and settled, like I had state multiple times. > It's ready for review for months already. Your stating something does not make it true, no matter how many times you do it. My objections were not addressed. In your last resend, Hendrik yet again raised the start_pts question. As far as I can tell, your explanation for why it's supposedly needed did not convince ANYONE. Some random quotes from IRC: 2022-09-01 00:25:21 @Lynne elenril: I never retracted my insistence on using the native frame fields for subtitles 2022-09-01 00:25:27 @Lynne not sure how softworks got that idea 2022-09-01 02:23:50 @BBBsubtitle.start_pts is really the emblem of the whole problem, I feel 2022-09-01 02:24:04 @BBBthere's many issues. but that one demonstrates it -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Wednesday, August 31, 2022 6:02 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Anton Khirnov
> > Sent: Wednesday, August 31, 2022 3:40 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering
> 2022
> >
> > Quoting Soft Works (2022-08-27 00:48:01)
> > > 2. "There's no reason why this cannot be handled using the buffer
> > > and data fields"
> > >
> > > I had explained the reasons and in conversation on IRC, Lynne was
> > > no longer insisting on this AFAIR.
> >
> > I did not see this explanation, can you restate it here?
>
You had asked me to restate the explanation.
I did that (below) but you never responded.
Thanks,
softworkz
> Sure. Let's look at the AVSubtitleArea struct first:
>
>
> typedef struct AVSubtitleArea {
>
> enum AVSubtitleType type;
> int flags;
>
> int x; ///< top left corner of area.
> int y; ///< top left corner of area.
> int w; ///< widthof area.
> int h; ///< height of area.
> int nb_colors; ///< number of colors in bitmap palette (@ref
> pal).
>
> /**
> * Buffers and line sizes for the bitmap of this subtitle.
> *
> * @{
> */
> AVBufferRef *buf[AV_NUM_BUFFER_POINTERS];
> int linesize[AV_NUM_BUFFER_POINTERS];
> /**
> * @}
> */
>
> uint32_t pal[256]; ///< RGBA palette for the bitmap.
>
> char *text;///< 0-terminated plain UTF-8 text
> char *ass; ///< 0-terminated ASS/SSA compatible event
> line.
>
> } AVSubtitleArea;
>
>
>
> These structs are stored in AVFrame like this:
>
>
> /**
> * Number of items in the @ref subtitle_areas array.
> */
> unsigned num_subtitle_areas;
>
> /**
> * Array of subtitle areas, may be empty.
> */
> AVSubtitleArea **subtitle_areas;
>
>
>
> The question was "why this cannot be handled using the buffer
> and data fields?" - there are multiple reasons:
>
> 1. Area Count
>
> In ASS subtitles it's not uncommon that animations are defined
> through subtitle events (regular ass events). This can go as
> far as that dust particles are flying around on the screen and
> each particle has its own subtitle event/line which defines
> how it flies from x to y and how fast, etc.
> Not yet, but in a future update, the ass decoder should be
> improved in a way that it doesn't emit an individual AVFrame
> for each event line but bundles subsequent events together
> when these would have the same start time and duration.
> As a result, we can have AVFrames with dozens or even a hundred
> AVSubtitleArea items in extreme cases.
>
> The buffer and data fields are an array of fixed size (currently
> 8). Increasing to 16 or 32 would not help: there will still be
> cases where this does not suffice.
>
> 2. What exactly should be stored in frame->buf[]?
>
> Should we store the AVSubtitleArea structs as AVBuffer there?
>
> Or should we only store data in those buffers? If yes, which
> data? The subtitle bitmap probably. How about the subtitle
> text - maybe and area has even both. And should we also
> store the palette in some frame->buf[n]?
> If yes, how to keep track of which data is stored in which
> buffer?
> Further, there's a documented convention that requires that
> non-zero buffers are contiguous, i.e. there must not be
> an empty buffer pointer between two other a non-empty buffer
> pointers. This would require to re-arrange the buffers to
> close any gap when some subtitle area data is removed, zeroed
> out or has been converted to another format.
> Closing such gap also require to update any mapping information
> ("which buffer is related to which area?")
>
> That's a lot of tedious work and every API user (or codec/filter
> developer) would need to do it in the right way.
>
>
>
> 3. AVFrame Code Logic Mistmatch
>
> A subtitle frame can have 0 to N areas, which means that a
> frame without any area is still valid. Opposed to that, existing
> (code all over the place in ffmpeg) is treating an AVFrame
> as invalid when the first data buffer is empty,
> i.e. frame->buf[0] != NULL
>
> To accommodate to this situation, subtitle frames are always
> creating a 1-byte buffer for buf[0].
>
> When we would want subtitle data to be stored in those buffers,
> every developer would need to be aware about the requirement
> to have that dummy buffer in the first array element. When something
> is to be stored, the dummy buffer would need to be freed first
> before storing the actual data.
> And when the last buffer gets deleted, API users would need to
> know to create a new dummy buffer.
>
>
> That fixed siz
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Quoting Nicolas George (2022-11-14 12:05:10) > Anton Khirnov (12022-11-14): > > I do not see any objections from you to this patch. > > My explanations for the other patch apply to this one, obviously: if you > treat EAGAIN as REDO, you introduce a busy wait. In what specific case would this supposed busy wait happen and why is it wrong? -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Monday, November 14, 2022 12:08 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > Quoting Soft Works (2022-11-14 11:46:49) > > > Sorry, but you problems are entirely self-inflicted. You have > been > > > told what changes need to happen right from the beginning, > > > repeatedly, and by several developers independently. > > > > And those are completed and settled, like I had state multiple > times. > > It's ready for review for months already. > > Your stating something does not make it true, no matter how many > times > you do it. > > My objections were not addressed. > > In your last resend, Hendrik yet again raised the start_pts question. > As > far as I can tell, your explanation for why it's supposedly needed > did > not convince ANYONE. What means "as far as I can tell" here? Do you have something to say about it, then please do? I cannot talk and respond to any "ghost" statements which I'm not aware of. And regarding the IRC snippet: Well, interesting, but I can neither know not respond to anything I'm not aware of. I had taken the effort to explain the reasons this in this article: https://github.com/softworkz/SubtitleFilteringDemos/issues/1 and Hendrik didn't respond. So whom should I talk to, in order to find a solution, especially, considering the fact, that nobody has really taken the effort to ACTUALLY understand what the problem is? Thanks, softworkz ___ 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".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
On 11/14/2022 2:58 AM, Wang, Bin wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Monday, November 14, 2022 10:43 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI On 11/4/2022 5:29 AM, bin.wang-at-intel@ffmpeg.org wrote: +%macro FILTER_SOBEL 0 +%if UNIX64 +cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, +c3, c4, c5, c6, c7, c8, r, x %else cglobal filter_sobel, 4, 15, 7, +dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, +c8, r, x %endif %if WIN64 +SWAP xmm0, xmm2 +SWAP xmm1, xmm3 +mov r2q, matrixmp +mov r3q, ptrmp +DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, +c7, c8, r, x %endif +movsxdifnidn widthq, widthd +VBROADCASTSS m0, xmm0 +VBROADCASTSS m1, xmm1 + This and every other xmm# case should instead be xm#, to ensure the swapping is taken into account. Sorry, I can't get your point, could you please help to explain why I have to use xm# to ensure the swapping operation(swap xmm# can't work in WIN64 asm)? And How to do it ? SWAP only affects the x86inc defined macros m#, xm#, ym#, and zm#, so those instructions above end up encoded as vbroadcastss zmm2, xmm0 and vbroadcastss zmm3, xmm1 on WIN64. In fact, now that i check it they end up as vbroadcastss zmm18, xmm0 and vbroadcastss zmm19, xmm1 because x86inc is purposely using the higher 16 regs with these macros on all targets to avoid having to call vzeroupper at the end. This works on unix64 by pure chance because the floats were effectively in xmm0 and xmm1 and all calculations then happen on m#, xm# and ym#. So you'll have to duplicate the VBROADCASTSS lines to broadcast xmm2 and xmm3 to m0 and m1 on WIN64 instead of using SWAP. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Monday, November 14, 2022 12:08 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > Quoting Soft Works (2022-11-14 11:46:49) > > > Sorry, but you problems are entirely self-inflicted. You have > been > > > told what changes need to happen right from the beginning, > > > repeatedly, and by several developers independently. > > > > And those are completed and settled, like I had state multiple > times. > > It's ready for review for months already. [...] > > Some random quotes from IRC: > 2022-09-01 00:25:21 @Lynne elenril: I never retracted my > insistence on using the native frame fields for subtitles > 2022-09-01 00:25:27 @Lynne not sure how softworks got that idea I got that "idea" from this discussion: Jan 14 02:46:02 can't you really not hide away everything to do with repetition, subtitle pts, and subtitle duration all into the private opqaue field, and give the user what they expect when the frames go out of lavfi? Jan 14 02:46:55 worth a thought, but I'm not sure Jan 14 02:49:32 I think it's better to make it more transparent. the heartbeat mechanism has been a hidden thing and that's why it wasn't an ideal solution Jan 14 02:50:10 when you already need to understand when and why you need to insert a subfeed filter, then there's no point in hiding the effect imo Jan 14 02:50:53 I think that's worth a really good look Jan 14 02:50:56 the good thing is, that often none of that is needed at all Jan 14 02:51:15 (say sometimes..) Jan 14 02:52:04 if you could hide all of that into the opaque field, I'd be happy with the patch This IS a retraction from the "insistence on using the native frame fields for subtitles." (because the actual subtitle timings would be in that opaque field) Regards, softworkz ___ 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".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Anton Khirnov (12022-11-14): > In what specific case would this supposed busy wait happen and why is it > wrong? See my mail from 9 Nov 2022 13:42:24 +0100 for explanations about the semantic of EAGAIN. -- 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Anton Khirnov (12022-11-14): > In your last resend, Hendrik yet again raised the start_pts question. As > far as I can tell, your explanation for why it's supposedly needed did > not convince ANYONE. Not only that: this series is completely broken with regard to negotiation, scheduling and utility filters. Not remotely ready for review. -- 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".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
On 11/4/2022 5:29 AM, bin.wang-at-intel@ffmpeg.org wrote: +.loop2: +xor rd, rd +pxor m4, m4 + +;Gx +SOBEL_MUL 0, data_n1 +SOBEL_MUL 1, data_n2 +SOBEL_MUL 2, data_n1 +SOBEL_ADD 6 +SOBEL_MUL 7, data_p2 +SOBEL_ADD 8 + +cvtsi2ss xmm4, rd +mulssxmm4, xmm4 + +xor rd, rd +;Gy +SOBEL_MUL 0, data_n1 +SOBEL_ADD 2 +SOBEL_MUL 3, data_n2 +SOBEL_MUL 5, data_p2 +SOBEL_MUL 6, data_n1 +SOBEL_ADD 8 + +cvtsi2ss xmm5, rd +fmaddss xmm4, xmm5, xmm5, xmm4 + +sqrtpsxmm4, xmm4 +fmaddss xmm4, xmm4, xmm0, xmm1 ;sum = sum * rdiv + bias By using xmm# you're not taking into account any x86inc SWAPing, so this is using xmm0 and xmm1 where the single scalar float input arguments reside (at least on unix64), instead of xm0 and xm1 (xmm16 and xmm17) where the broadcasted scalars were stored. This, again, only worked by chance on unix64 because you're using scalar fmadd, and shouldn't work at all on win64. Also, all these as is are being encoded as VEX, not EVEX, but it should be fine leaving them untouched instead of using xm#, since they will be shorter (five bytes instead of six for some) by using the lower, non callee-saved regs. +cvttps2dq xmm4, xmm4 ; trunc to integer +packssdw xmm4, xmm4 +packuswb xmm4, xmm4 +movd rd, xmm4 +mov [dstq + xq], rb + +add xq, 1 +cmp xq, widthq +jl .loop2 +.end: +RET ___ 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".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
> By using xmm# you're not taking into account any x86inc SWAPing, so this is > using xmm0 and xmm1 where the single scalar float input arguments reside (at > least on unix64), instead of xm0 and xm1 (xmm16 and xmm17) where the > broadcasted scalars were stored. > This, again, only worked by chance on unix64 because you're using scalar > fmadd, > and shouldn't work at all on win64. > > Also, all these as is are being encoded as VEX, not EVEX, but it should be > fine > leaving them untouched instead of using xm#, since they will be shorter (five > bytes instead of six for some) by using the lower, non callee-saved regs. Thanks for the help. I'm not familiar with WIN64 asm. So what I need to do is change the WIN64 swap from: SWAP xmm0, xmm2 SWAP xmm1, xmm3 To: VBROADCASTSS m0, xmm2 VBROADCASTSS m1, xmm3 Is that correct? ___ 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". ___ 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".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
On 11/14/2022 10:30 AM, Wang, Bin wrote: By using xmm# you're not taking into account any x86inc SWAPing, so this is using xmm0 and xmm1 where the single scalar float input arguments reside (at least on unix64), instead of xm0 and xm1 (xmm16 and xmm17) where the broadcasted scalars were stored. This, again, only worked by chance on unix64 because you're using scalar fmadd, and shouldn't work at all on win64. Also, all these as is are being encoded as VEX, not EVEX, but it should be fine leaving them untouched instead of using xm#, since they will be shorter (five bytes instead of six for some) by using the lower, non callee-saved regs. Thanks for the help. I'm not familiar with WIN64 asm. So what I need to do is change the WIN64 swap from: SWAP xmm0, xmm2 SWAP xmm1, xmm3 To: VBROADCASTSS m0, xmm2 VBROADCASTSS m1, xmm3 Is that correct? Yes, that will ultimately broadcast the two scalars in xmm2 and xmm3 to zmm16 and zmm17. After that what you need to do is either change the fmaddss instruction to use xm0 and xm1 macros instead of xmm0 and xmm1 (so xmm16 and xmm17 with EVEX encoding is used), or much like the broadcast above use xmm2 and xmm3 explicitly on win64, so it remains VEX encoded. ___ 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".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
> -Original Message- > From: ffmpeg-devel On Behalf Of James > Almer > Sent: Monday, November 14, 2022 9:36 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add > sobel filter optimization and unit test with intel AVX512 VNNI > > On 11/14/2022 10:30 AM, Wang, Bin wrote: > >> By using xmm# you're not taking into account any x86inc SWAPing, so > >> this is using xmm0 and xmm1 where the single scalar float input > >> arguments reside (at least on unix64), instead of xm0 and xm1 (xmm16 > >> and xmm17) where the broadcasted scalars were stored. > >> This, again, only worked by chance on unix64 because you're using > >> scalar fmadd, and shouldn't work at all on win64. > >> > >> Also, all these as is are being encoded as VEX, not EVEX, but it > >> should be fine leaving them untouched instead of using xm#, since > >> they will be shorter (five bytes instead of six for some) by using the > >> lower, > non callee-saved regs. > > > > Thanks for the help. I'm not familiar with WIN64 asm. So what I need to do > > is > change the WIN64 swap from: > > SWAP xmm0, xmm2 > > SWAP xmm1, xmm3 > > To: > > VBROADCASTSS m0, xmm2 > > VBROADCASTSS m1, xmm3 > > > > Is that correct? > > Yes, that will ultimately broadcast the two scalars in xmm2 and xmm3 to > zmm16 and zmm17. > After that what you need to do is either change the fmaddss instruction to use > xm0 and xm1 macros instead of xmm0 and xmm1 (so xmm16 and xmm17 with > EVEX encoding is used), or much like the broadcast above use xmm2 and xmm3 > explicitly on win64, so it remains VEX encoded. So, to fix the issue, does this 2 changes looks good for you? First change the WIN64 swap from: SWAP xmm0, xmm2 SWAP xmm1, xmm3 To: VBROADCASTSS m0, xmm2 VBROADCASTSS m1, xmm3 Second change the fmaddss from: fmaddss xmm4, xmm4, xmm0, xmm1 To: fmaddss xmm4, xmm4, xm0, xm1 > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
On 11/14/2022 10:54 AM, Wang, Bin wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Monday, November 14, 2022 9:36 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI On 11/14/2022 10:30 AM, Wang, Bin wrote: By using xmm# you're not taking into account any x86inc SWAPing, so this is using xmm0 and xmm1 where the single scalar float input arguments reside (at least on unix64), instead of xm0 and xm1 (xmm16 and xmm17) where the broadcasted scalars were stored. This, again, only worked by chance on unix64 because you're using scalar fmadd, and shouldn't work at all on win64. Also, all these as is are being encoded as VEX, not EVEX, but it should be fine leaving them untouched instead of using xm#, since they will be shorter (five bytes instead of six for some) by using the lower, non callee-saved regs. Thanks for the help. I'm not familiar with WIN64 asm. So what I need to do is change the WIN64 swap from: SWAP xmm0, xmm2 SWAP xmm1, xmm3 To: VBROADCASTSS m0, xmm2 VBROADCASTSS m1, xmm3 Is that correct? Yes, that will ultimately broadcast the two scalars in xmm2 and xmm3 to zmm16 and zmm17. After that what you need to do is either change the fmaddss instruction to use xm0 and xm1 macros instead of xmm0 and xmm1 (so xmm16 and xmm17 with EVEX encoding is used), or much like the broadcast above use xmm2 and xmm3 explicitly on win64, so it remains VEX encoded. So, to fix the issue, does this 2 changes looks good for you? First change the WIN64 swap from: SWAP xmm0, xmm2 SWAP xmm1, xmm3 To: VBROADCASTSS m0, xmm2 VBROADCASTSS m1, xmm3 Second change the fmaddss from: fmaddss xmm4, xmm4, xmm0, xmm1 To: fmaddss xmm4, xmm4, xm0, xm1 Yes. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Quoting Soft Works (2022-11-14 12:20:00) > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Monday, November 14, 2022 12:08 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > > the argument for submitting patches > > > > Quoting Soft Works (2022-11-14 11:46:49) > > > > Sorry, but you problems are entirely self-inflicted. You have > > been > > > > told what changes need to happen right from the beginning, > > > > repeatedly, and by several developers independently. > > > > > > And those are completed and settled, like I had state multiple > > times. > > > It's ready for review for months already. > > > > Your stating something does not make it true, no matter how many > > times > > you do it. > > > > My objections were not addressed. > > > > In your last resend, Hendrik yet again raised the start_pts question. > > As > > far as I can tell, your explanation for why it's supposedly needed > > did > > not convince ANYONE. > > What means "as far as I can tell" here? Do you have something to > say about it, then please do? It means that I am not aware of anyone who changed their stance based on your arguments, but cannot prove that no such person exists. > > I cannot talk and respond to any "ghost" statements which I'm not > aware of. > > And regarding the IRC snippet: Well, interesting, but I can neither > know not respond to anything I'm not aware of. > > > I had taken the effort to explain the reasons this in this article: > > https://github.com/softworkz/SubtitleFilteringDemos/issues/1 > > and Hendrik didn't respond. So whom should I talk to, in order > to find a solution, especially, considering the fact, that > nobody has really taken the effort to ACTUALLY understand what > the problem is? I did read your document, and my takeaway message from it is "doing it properly is too hard". As long as that continues to be your position, you might as well not bother. -- Anton Khirnov ___ 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".
[FFmpeg-devel] [PATCH v1] libavfilter/x86/vf_convolution: fix sobel swap issue on WIN64
From: "Wang, Bin" Signed-off-by: Wang, Bin --- libavfilter/x86/vf_convolution.asm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavfilter/x86/vf_convolution.asm b/libavfilter/x86/vf_convolution.asm index c912d56752..a6be95690b 100644 --- a/libavfilter/x86/vf_convolution.asm +++ b/libavfilter/x86/vf_convolution.asm @@ -189,8 +189,8 @@ cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x %endif %if WIN64 -SWAP xmm0, xmm2 -SWAP xmm1, xmm3 +VBROADCASTSS m0, xmm2 +VBROADCASTSS m1, xmm3 mov r2q, matrixmp mov r3q, ptrmp DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x @@ -281,7 +281,7 @@ cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, fmaddss xmm4, xmm5, xmm5, xmm4 sqrtpsxmm4, xmm4 -fmaddss xmm4, xmm4, xmm0, xmm1 ;sum = sum * rdiv + bias +fmaddss xmm4, xmm4, xm0, xm1 ;sum = sum * rdiv + bias cvttps2dq xmm4, xmm4 ; trunc to integer packssdw xmm4, xmm4 packuswb xmm4, xmm4 -- 2.27.0 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Monday, November 14, 2022 3:35 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > Quoting Soft Works (2022-11-14 12:20:00) > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Monday, November 14, 2022 12:08 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: > extend > > > the argument for submitting patches > > > > > > Quoting Soft Works (2022-11-14 11:46:49) > > > > > Sorry, but you problems are entirely self-inflicted. You have > > > been > > > > > told what changes need to happen right from the beginning, > > > > > repeatedly, and by several developers independently. > > > > > > > > And those are completed and settled, like I had state multiple > > > times. > > > > It's ready for review for months already. > > > > > > Your stating something does not make it true, no matter how many > > > times > > > you do it. > > > > > > My objections were not addressed. > > > > > > In your last resend, Hendrik yet again raised the start_pts > question. > > > As > > > far as I can tell, your explanation for why it's supposedly > needed > > > did > > > not convince ANYONE. > > > > What means "as far as I can tell" here? Do you have something to > > say about it, then please do? > > It means that I am not aware of anyone who changed their stance based > on > your arguments, but cannot prove that no such person exists. I'm afraid, but everything you are writing is making references to others and what they would think or what you are assuming that they might think. > I did read your document, and my takeaway message from it is "doing > it > properly is too hard". As long as that continues to be your position, > you might as well not bother. This is ridiculous, and you know that. Or at least you would know if you would have really tried to understand the problem. And that unfortunately applies to some others as well. Nobody is willing to go deep enough to the point where it becomes clear that a "perfect" solution would only be possible by making fundamental changes to libavfilter, which are complex, risky and something that would never be accepted from me, even when it would be the most excellent solution. I think this is pretty clear to everybody here, and trying to present this in a light as if I would just be too lazy to go for it, is just despicable, I'm afraid. I wish you could stop referring to others potential opinions and get yourself as much into the subject as it is required to understand the actual problem and talk for yourself. Because I would happily discuss alternatives with you and follow your advice, no matter when it takes a little more effort - as long as it will still be possible to handle all cases like with the current patchset. But I mean substantial and detailed advice based on an understanding of the problems, not the kind of "no, that's bad, I don't believe you that it couldn't be done like I think it's gotta be". I will happily, gladly and friendly work and converse with anybody who would be so kind to leave one's peripheral spectator position and get down with me to the core problem and discuss potential solutions. Thanks, softworkz ___ 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".
[FFmpeg-devel] [PATCH 1/8] fftools/ffmpeg: simplify ost_iter()
The inner loop never goes through more than 1 iteration, and so can be
replaced by an if().
Found-by: Andreas Rheinhardt
---
fftools/ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e6f6773f6a..0fa2fe8c52 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -612,7 +612,7 @@ static OutputStream *ost_iter(OutputStream *prev)
for (; of_idx < nb_output_files; of_idx++) {
OutputFile *of = output_files[of_idx];
-for (; ost_idx < of->nb_streams; ost_idx++)
+if (ost_idx < of->nb_streams)
return of->streams[ost_idx];
ost_idx = 0;
--
2.35.1
___
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".
[FFmpeg-devel] [PATCH 6/8] fftools/ffmpeg_mux_init: do not call av{codec, format}_get_class() repeatedly
---
fftools/ffmpeg_mux_init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 7ccaf9da78..6ed30eb498 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1727,6 +1727,8 @@ static int set_dispositions(OutputFile *of,
AVFormatContext *ctx)
static void validate_enc_avopt(const Muxer *mux, const AVDictionary
*codec_avopt)
{
+const AVClass *class = avcodec_get_class();
+const AVClass *fclass = avformat_get_class();
const OutputFile *of = &mux->of;
AVDictionary *unused_opts;
@@ -1742,10 +1744,8 @@ static void validate_enc_avopt(const Muxer *mux, const
AVDictionary *codec_avopt
e = NULL;
while ((e = av_dict_get(unused_opts, "", e, AV_DICT_IGNORE_SUFFIX))) {
-const AVClass *class = avcodec_get_class();
const AVOption *option = av_opt_find(&class, e->key, NULL, 0,
AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
-const AVClass *fclass = avformat_get_class();
const AVOption *foption = av_opt_find(&fclass, e->key, NULL, 0,
AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
if (!option || foption)
--
2.35.1
___
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".
[FFmpeg-devel] [PATCH 8/8] fftools/ffmpeg_mux_init: drop an always-false check
It cannot be true since 1959351aecf. Effectively reverts 6a3833e1411.
---
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_demux.c| 2 --
fftools/ffmpeg_mux_init.c | 6 --
fftools/ffmpeg_opt.c | 5 -
4 files changed, 14 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index b9262b373f..a96ff0d723 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -674,7 +674,6 @@ extern HWDevice *filter_hw_device;
extern unsigned nb_output_dumped;
extern int main_return_code;
-extern int input_stream_potentially_available;
extern int ignore_unknown_streams;
extern int copy_unknown_streams;
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 94fd604fd9..595a56a590 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -1097,7 +1097,5 @@ int ifile_open(const OptionsContext *o, const char
*filename)
}
}
-input_stream_potentially_available = 1;
-
return 0;
}
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 277cbd1f64..db45fa09fa 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1911,12 +1911,6 @@ int of_open(const OptionsContext *o, const char
*filename)
}
}
-if (!(oc->oformat->flags & AVFMT_NOSTREAMS) &&
!input_stream_potentially_available) {
-av_log(NULL, AV_LOG_ERROR,
- "No input streams but output needs an input stream\n");
-exit_program(1);
-}
-
if (!(oc->oformat->flags & AVFMT_NOFILE)) {
/* test if it already exists to avoid losing precious files */
assert_file_overwrite(filename);
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 5ab296828b..61aa0be0ab 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -95,7 +95,6 @@ static int no_file_overwrite = 0;
#if FFMPEG_OPT_PSNR
int do_psnr= 0;
#endif
-int input_stream_potentially_available = 0;
int ignore_unknown_streams = 0;
int copy_unknown_streams = 0;
int recast_media = 0;
@@ -1114,8 +1113,6 @@ static int opt_filter_complex(void *optctx, const char
*opt, const char *arg)
if (!fg->graph_desc)
return AVERROR(ENOMEM);
-input_stream_potentially_available = 1;
-
return 0;
}
@@ -1130,8 +1127,6 @@ static int opt_filter_complex_script(void *optctx, const
char *opt, const char *
fg->index = nb_filtergraphs - 1;
fg->graph_desc = graph_desc;
-input_stream_potentially_available = 1;
-
return 0;
}
--
2.35.1
___
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".
[FFmpeg-devel] [PATCH 3/8] fftools/ffmpeg: stop handling max_frames in do_video_out()
Frame limiting is now handled using sync queues. This code prevents the sync queue from triggering EOF, resulting in unnecessarily many frames being decoded, filtered, and then discarded. Found-by: U. Artie Eoff --- fftools/ffmpeg.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 0fa2fe8c52..dfdfad3ce4 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -1206,14 +1206,6 @@ static void do_video_out(OutputFile *of, } } -/* - * For video, number of frames in == number of packets out. - * But there may be reordering, so we can't throw away frames on encoder - * flush, we need to limit them here, before they go into encoder. - */ -nb_frames = FFMIN(nb_frames, ost->max_frames - ost->vsync_frame_number); -nb0_frames = FFMIN(nb0_frames, nb_frames); - memmove(ost->last_nb0_frames + 1, ost->last_nb0_frames, sizeof(ost->last_nb0_frames[0]) * (FF_ARRAY_ELEMS(ost->last_nb0_frames) - 1)); @@ -1262,7 +1254,9 @@ static void do_video_out(OutputFile *of, in_picture->pict_type = forced_kf_apply(ost, in_picture, i); ret = submit_encode_frame(of, ost, in_picture); -if (ret < 0 && ret != AVERROR_EOF) +if (ret == AVERROR_EOF) +break; +else if (ret < 0) exit_program(1); ost->next_pts++; -- 2.35.1 ___ 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".
[FFmpeg-devel] [PATCH 5/8] fftools/ffmpeg_mux_init: move validating codec avoptions to a separate function
---
fftools/ffmpeg.h | 2 +-
fftools/ffmpeg_mux_init.c | 91 +--
fftools/ffmpeg_opt.c | 2 +-
3 files changed, 51 insertions(+), 44 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index ad53ad4ce8..b9262b373f 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -694,7 +694,7 @@ void assert_avoptions(AVDictionary *m);
void assert_file_overwrite(const char *filename);
char *file_read(const char *filename);
-AVDictionary *strip_specifiers(AVDictionary *dict);
+AVDictionary *strip_specifiers(const AVDictionary *dict);
const AVCodec *find_codec_or_die(const char *name, enum AVMediaType type, int
encoder);
int parse_and_set_vsync(const char *arg, int *vsync_var, int file_idx, int
st_idx, int is_global);
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 150eb77ee2..7ccaf9da78 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1725,14 +1725,60 @@ static int set_dispositions(OutputFile *of,
AVFormatContext *ctx)
return 0;
}
+static void validate_enc_avopt(const Muxer *mux, const AVDictionary
*codec_avopt)
+{
+const OutputFile *of = &mux->of;
+
+AVDictionary *unused_opts;
+const AVDictionaryEntry *e;
+
+unused_opts = strip_specifiers(codec_avopt);
+for (int i = 0; i < of->nb_streams; i++) {
+e = NULL;
+while ((e = av_dict_get(of->streams[i]->encoder_opts, "", e,
+AV_DICT_IGNORE_SUFFIX)))
+av_dict_set(&unused_opts, e->key, NULL, 0);
+}
+
+e = NULL;
+while ((e = av_dict_get(unused_opts, "", e, AV_DICT_IGNORE_SUFFIX))) {
+const AVClass *class = avcodec_get_class();
+const AVOption *option = av_opt_find(&class, e->key, NULL, 0,
+ AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
+const AVClass *fclass = avformat_get_class();
+const AVOption *foption = av_opt_find(&fclass, e->key, NULL, 0,
+ AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
+if (!option || foption)
+continue;
+
+if (!(option->flags & AV_OPT_FLAG_ENCODING_PARAM)) {
+av_log(NULL, AV_LOG_ERROR, "Codec AVOption %s (%s) specified for "
+ "output file #%d (%s) is not an encoding option.\n", e->key,
+ option->help ? option->help : "", nb_output_files - 1,
+ mux->fc->url);
+exit_program(1);
+}
+
+// gop_timecode is injected by generic code but not always used
+if (!strcmp(e->key, "gop_timecode"))
+continue;
+
+av_log(NULL, AV_LOG_WARNING, "Codec AVOption %s (%s) specified for "
+ "output file #%d (%s) has not been used for any stream. The
most "
+ "likely reason is either wrong type (e.g. a video option with "
+ "no video streams) or that it is a private option of some
encoder "
+ "which was not actually used for any stream.\n", e->key,
+ option->help ? option->help : "", nb_output_files - 1,
mux->fc->url);
+}
+av_dict_free(&unused_opts);
+}
+
int of_open(const OptionsContext *o, const char *filename)
{
Muxer *mux;
AVFormatContext *oc;
int err;
OutputFile *of;
-AVDictionary *unused_opts = NULL;
-const AVDictionaryEntry *e = NULL;
int64_t recording_time = o->recording_time;
int64_t stop_time = o->stop_time;
@@ -1795,46 +1841,7 @@ int of_open(const OptionsContext *o, const char
*filename)
create_streams(mux, o);
/* check if all codec options have been used */
-unused_opts = strip_specifiers(o->g->codec_opts);
-for (int i = 0; i < of->nb_streams; i++) {
-e = NULL;
-while ((e = av_dict_get(of->streams[i]->encoder_opts, "", e,
-AV_DICT_IGNORE_SUFFIX)))
-av_dict_set(&unused_opts, e->key, NULL, 0);
-}
-
-e = NULL;
-while ((e = av_dict_get(unused_opts, "", e, AV_DICT_IGNORE_SUFFIX))) {
-const AVClass *class = avcodec_get_class();
-const AVOption *option = av_opt_find(&class, e->key, NULL, 0,
- AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
-const AVClass *fclass = avformat_get_class();
-const AVOption *foption = av_opt_find(&fclass, e->key, NULL, 0,
- AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
-if (!option || foption)
-continue;
-
-
-if (!(option->flags & AV_OPT_FLAG_ENCODING_PARAM)) {
-av_log(NULL, AV_LOG_ERROR, "Codec AVOption %s (%s) specified for "
- "output file #%d (%s) is not an encoding option.\n", e->key,
- option->help ? option->help : "", nb_output_files - 1,
- filename);
-exit_program(1);
-}
-
-//
[FFmpeg-devel] [PATCH 2/8] fftools/ffmpeg_mux_init: move more code from of_open() to create_streams()
Specificaly, the of_add_attachments() call (which can add attachment
streams to the output) and the check whether the output file contains
any streams. They both logically belong in create_streams().
---
fftools/ffmpeg_mux_init.c | 99 ---
1 file changed, 50 insertions(+), 49 deletions(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 4755a2cc38..303bf25096 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1062,8 +1062,50 @@ loop_end:
}
}
+static void of_add_attachments(Muxer *mux, const OptionsContext *o)
+{
+OutputStream *ost;
+int err;
+
+for (int i = 0; i < o->nb_attachments; i++) {
+AVIOContext *pb;
+uint8_t *attachment;
+const char *p;
+int64_t len;
+
+if ((err = avio_open2(&pb, o->attachments[i], AVIO_FLAG_READ, &int_cb,
NULL)) < 0) {
+av_log(NULL, AV_LOG_FATAL, "Could not open attachment file %s.\n",
+ o->attachments[i]);
+exit_program(1);
+}
+if ((len = avio_size(pb)) <= 0) {
+av_log(NULL, AV_LOG_FATAL, "Could not get size of the attachment
%s.\n",
+ o->attachments[i]);
+exit_program(1);
+}
+if (len > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE ||
+!(attachment = av_malloc(len + AV_INPUT_BUFFER_PADDING_SIZE))) {
+av_log(NULL, AV_LOG_FATAL, "Attachment %s too large.\n",
+ o->attachments[i]);
+exit_program(1);
+}
+avio_read(pb, attachment, len);
+memset(attachment + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+ost = new_attachment_stream(mux, o, -1);
+ost->attachment_filename = o->attachments[i];
+ost->st->codecpar->extradata = attachment;
+ost->st->codecpar->extradata_size = len;
+
+p = strrchr(o->attachments[i], '/');
+av_dict_set(&ost->st->metadata, "filename", (p && *p) ? p + 1 :
o->attachments[i], AV_DICT_DONT_OVERWRITE);
+avio_closep(&pb);
+}
+}
+
static void create_streams(Muxer *mux, const OptionsContext *o)
{
+AVFormatContext *oc = mux->fc;
int auto_disable_v = o->video_disable;
int auto_disable_a = o->audio_disable;
int auto_disable_s = o->subtitle_disable;
@@ -1101,6 +1143,14 @@ static void create_streams(Muxer *mux, const
OptionsContext *o)
for (int i = 0; i < o->nb_stream_maps; i++)
map_manual(mux, o, &o->stream_maps[i]);
}
+
+of_add_attachments(mux, o);
+
+if (!oc->nb_streams && !(oc->oformat->flags & AVFMT_NOSTREAMS)) {
+av_dump_format(oc, nb_output_files - 1, oc->url, 1);
+av_log(NULL, AV_LOG_ERROR, "Output file #%d does not contain any
stream\n", nb_output_files - 1);
+exit_program(1);
+}
}
static int setup_sync_queues(Muxer *mux, AVFormatContext *oc, int64_t
buf_size_us)
@@ -1194,47 +1244,6 @@ static int setup_sync_queues(Muxer *mux, AVFormatContext
*oc, int64_t buf_size_u
return 0;
}
-static void of_add_attachments(Muxer *mux, const OptionsContext *o)
-{
-OutputStream *ost;
-int err;
-
-for (int i = 0; i < o->nb_attachments; i++) {
-AVIOContext *pb;
-uint8_t *attachment;
-const char *p;
-int64_t len;
-
-if ((err = avio_open2(&pb, o->attachments[i], AVIO_FLAG_READ, &int_cb,
NULL)) < 0) {
-av_log(NULL, AV_LOG_FATAL, "Could not open attachment file %s.\n",
- o->attachments[i]);
-exit_program(1);
-}
-if ((len = avio_size(pb)) <= 0) {
-av_log(NULL, AV_LOG_FATAL, "Could not get size of the attachment
%s.\n",
- o->attachments[i]);
-exit_program(1);
-}
-if (len > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE ||
-!(attachment = av_malloc(len + AV_INPUT_BUFFER_PADDING_SIZE))) {
-av_log(NULL, AV_LOG_FATAL, "Attachment %s too large.\n",
- o->attachments[i]);
-exit_program(1);
-}
-avio_read(pb, attachment, len);
-memset(attachment + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
-
-ost = new_attachment_stream(mux, o, -1);
-ost->attachment_filename = o->attachments[i];
-ost->st->codecpar->extradata = attachment;
-ost->st->codecpar->extradata_size = len;
-
-p = strrchr(o->attachments[i], '/');
-av_dict_set(&ost->st->metadata, "filename", (p && *p) ? p + 1 :
o->attachments[i], AV_DICT_DONT_OVERWRITE);
-avio_closep(&pb);
-}
-}
-
static void of_add_programs(AVFormatContext *oc, const OptionsContext *o)
{
/* process manually set programs */
@@ -1782,14 +1791,6 @@ int of_open(const OptionsContext *o, const char
*filename)
/* create all output streams for this file */
create_streams(mux, o);
-of_add_attachments(mux, o);
-
-if (!oc->nb_streams && !(oc->oformat->flags & AVFMT_N
[FFmpeg-devel] [PATCH 4/8] fftools/ffmpeg: move OutputStream.max_frames to MuxStream
It no longer needs to be visible outside of the muxing code.
---
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_mux.c | 5 -
fftools/ffmpeg_mux.h | 7 +++
fftools/ffmpeg_mux_init.c | 23 +--
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 23850c7573..ad53ad4ce8 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -508,7 +508,6 @@ typedef struct OutputStream {
AVRational enc_timebase;
AVCodecContext *enc_ctx;
-int64_t max_frames;
AVFrame *filtered_frame;
AVFrame *last_frame;
AVFrame *sq_frame;
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 778626e20f..ad04f5049d 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -45,11 +45,6 @@ static Muxer *mux_from_of(OutputFile *of)
return (Muxer*)of;
}
-static MuxStream *ms_from_ost(OutputStream *ost)
-{
-return (MuxStream*)ost;
-}
-
static int64_t filesize(AVIOContext *pb)
{
int64_t ret = -1;
diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
index 6ea7c692ef..6a72b9dc91 100644
--- a/fftools/ffmpeg_mux.h
+++ b/fftools/ffmpeg_mux.h
@@ -42,6 +42,8 @@ typedef struct MuxStream {
AVBSFContext *bsf_ctx;
+int64_t max_frames;
+
/*
* The size of the AVPackets' buffers in queue.
* Updated when a packet is either pushed or pulled from the queue.
@@ -84,4 +86,9 @@ extern int want_sdp;
int mux_check_init(Muxer *mux);
+static MuxStream *ms_from_ost(OutputStream *ost)
+{
+return (MuxStream*)ost;
+}
+
#endif /* FFTOOLS_FFMPEG_MUX_H */
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 303bf25096..150eb77ee2 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -295,8 +295,8 @@ static OutputStream *new_output_stream(Muxer *mux, const
OptionsContext *o,
ost->enc_timebase = q;
}
-ost->max_frames = INT64_MAX;
-MATCH_PER_STREAM_OPT(max_frames, i64, ost->max_frames, oc, st);
+ms->max_frames = INT64_MAX;
+MATCH_PER_STREAM_OPT(max_frames, i64, ms->max_frames, oc, st);
for (i = 0; inb_max_frames; i++) {
char *p = o->max_frames[i].specifier;
if (!*p && type != AVMEDIA_TYPE_VIDEO) {
@@ -1165,6 +1165,7 @@ static int setup_sync_queues(Muxer *mux, AVFormatContext
*oc, int64_t buf_size_u
for (int i = 0; i < oc->nb_streams; i++) {
OutputStream *ost = of->streams[i];
+MuxStream *ms = ms_from_ost(ost);
enum AVMediaType type = ost->st->codecpar->codec_type;
ost->sq_idx_encode = -1;
@@ -1173,8 +1174,8 @@ static int setup_sync_queues(Muxer *mux, AVFormatContext
*oc, int64_t buf_size_u
nb_interleaved += IS_INTERLEAVED(type);
nb_av_enc += IS_AV_ENC(ost, type);
-limit_frames|= ost->max_frames < INT64_MAX;
-limit_frames_av_enc |= (ost->max_frames < INT64_MAX) && IS_AV_ENC(ost,
type);
+limit_frames|= ms->max_frames < INT64_MAX;
+limit_frames_av_enc |= (ms->max_frames < INT64_MAX) && IS_AV_ENC(ost,
type);
}
if (!((nb_interleaved > 1 && of->shortest) ||
@@ -1191,13 +1192,14 @@ static int setup_sync_queues(Muxer *mux,
AVFormatContext *oc, int64_t buf_size_u
for (int i = 0; i < oc->nb_streams; i++) {
OutputStream *ost = of->streams[i];
+MuxStream *ms = ms_from_ost(ost);
enum AVMediaType type = ost->st->codecpar->codec_type;
if (!IS_AV_ENC(ost, type))
continue;
ost->sq_idx_encode = sq_add_stream(of->sq_encode,
- of->shortest || ost->max_frames
< INT64_MAX);
+ of->shortest || ms->max_frames
< INT64_MAX);
if (ost->sq_idx_encode < 0)
return ost->sq_idx_encode;
@@ -1205,8 +1207,8 @@ static int setup_sync_queues(Muxer *mux, AVFormatContext
*oc, int64_t buf_size_u
if (!ost->sq_frame)
return AVERROR(ENOMEM);
-if (ost->max_frames != INT64_MAX)
-sq_limit_frames(of->sq_encode, ost->sq_idx_encode,
ost->max_frames);
+if (ms->max_frames != INT64_MAX)
+sq_limit_frames(of->sq_encode, ost->sq_idx_encode,
ms->max_frames);
}
}
@@ -1223,18 +1225,19 @@ static int setup_sync_queues(Muxer *mux,
AVFormatContext *oc, int64_t buf_size_u
for (int i = 0; i < oc->nb_streams; i++) {
OutputStream *ost = of->streams[i];
+MuxStream *ms = ms_from_ost(ost);
enum AVMediaType type = ost->st->codecpar->codec_type;
if (!IS_INTERLEAVED(type))
continue;
ost->sq_idx_mux = sq_add_stream(mux->sq_mux,
-of->shortest || ost->max_frames <
INT64_MAX);
+of->shortest || ms->max_frames <
INT6
[FFmpeg-devel] [PATCH 7/8] fftools/ffmpeg_mux_init: use av_dict_iterate() where appropriate
---
fftools/ffmpeg_mux_init.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 6ed30eb498..277cbd1f64 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1737,13 +1737,12 @@ static void validate_enc_avopt(const Muxer *mux, const
AVDictionary *codec_avopt
unused_opts = strip_specifiers(codec_avopt);
for (int i = 0; i < of->nb_streams; i++) {
e = NULL;
-while ((e = av_dict_get(of->streams[i]->encoder_opts, "", e,
-AV_DICT_IGNORE_SUFFIX)))
+while ((e = av_dict_iterate(of->streams[i]->encoder_opts, e)))
av_dict_set(&unused_opts, e->key, NULL, 0);
}
e = NULL;
-while ((e = av_dict_get(unused_opts, "", e, AV_DICT_IGNORE_SUFFIX))) {
+while ((e = av_dict_iterate(unused_opts, e))) {
const AVOption *option = av_opt_find(&class, e->key, NULL, 0,
AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
const AVOption *foption = av_opt_find(&fclass, e->key, NULL, 0,
--
2.35.1
___
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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
On 11/14/22, Soft Works wrote: > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> Anton Khirnov >> Sent: Monday, November 14, 2022 3:35 PM >> To: FFmpeg development discussions and patches > de...@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend >> the argument for submitting patches >> >> Quoting Soft Works (2022-11-14 12:20:00) >> > >> > >> > > -Original Message- >> > > From: ffmpeg-devel On Behalf Of >> > > Anton Khirnov >> > > Sent: Monday, November 14, 2022 12:08 PM >> > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> >> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: >> extend >> > > the argument for submitting patches >> > > >> > > Quoting Soft Works (2022-11-14 11:46:49) >> > > > > Sorry, but you problems are entirely self-inflicted. You have >> > > been >> > > > > told what changes need to happen right from the beginning, >> > > > > repeatedly, and by several developers independently. >> > > > >> > > > And those are completed and settled, like I had state multiple >> > > times. >> > > > It's ready for review for months already. >> > > >> > > Your stating something does not make it true, no matter how many >> > > times >> > > you do it. >> > > >> > > My objections were not addressed. >> > > >> > > In your last resend, Hendrik yet again raised the start_pts >> question. >> > > As >> > > far as I can tell, your explanation for why it's supposedly >> needed >> > > did >> > > not convince ANYONE. >> > >> > What means "as far as I can tell" here? Do you have something to >> > say about it, then please do? >> >> It means that I am not aware of anyone who changed their stance based >> on >> your arguments, but cannot prove that no such person exists. > > I'm afraid, but everything you are writing is making references to > others and what they would think or what you are assuming that they > might think. > >> I did read your document, and my takeaway message from it is "doing >> it >> properly is too hard". As long as that continues to be your position, >> you might as well not bother. > > This is ridiculous, and you know that. Or at least you would know > if you would have really tried to understand the problem. > > And that unfortunately applies to some others as well. Nobody is > willing to go deep enough to the point where it becomes clear > that a "perfect" solution would only be possible by making fundamental > changes to libavfilter, which are complex, risky and something > that would never be accepted from me, even when it would be > the most excellent solution. I think this is pretty clear to > everybody here, and trying to present this in a light as if > I would just be too lazy to go for it, is just despicable, > I'm afraid. > > I wish you could stop referring to others potential opinions > and get yourself as much into the subject as it is required to > understand the actual problem and talk for yourself. > > Because I would happily discuss alternatives > with you and follow your advice, no matter when it takes > a little more effort - as long as it will still be possible > to handle all cases like with the current patchset. > But I mean substantial and detailed advice based on an > understanding of the problems, not the kind of "no, that's > bad, I don't believe you that it couldn't be done like I > think it's gotta be". > > I will happily, gladly and friendly work and converse with > anybody who would be so kind to leave one's peripheral > spectator position and get down with me to the core > problem and discuss potential solutions. They can not admit they have zero understanding why and how code works Instead they propose some nonsense that hardly can be implemented. > > Thanks, > softworkz > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
> >> On 11/14/2022 10:30 AM, Wang, Bin wrote: > By using xmm# you're not taking into account any x86inc SWAPing, so > this is using xmm0 and xmm1 where the single scalar float input > arguments reside (at least on unix64), instead of xm0 and xm1 > (xmm16 and xmm17) where the broadcasted scalars were stored. > This, again, only worked by chance on unix64 because you're using > scalar fmadd, and shouldn't work at all on win64. > > Also, all these as is are being encoded as VEX, not EVEX, but it > should be fine leaving them untouched instead of using xm#, since > they will be shorter (five bytes instead of six for some) by using > the lower, > >> non callee-saved regs. > >>> > >>> Thanks for the help. I'm not familiar with WIN64 asm. So what I need > >>> to do is > >> change the WIN64 swap from: > >>> SWAP xmm0, xmm2 > >>> SWAP xmm1, xmm3 > >>> To: > >>> VBROADCASTSS m0, xmm2 > >>> VBROADCASTSS m1, xmm3 > >>> > >>> Is that correct? > >> > >> Yes, that will ultimately broadcast the two scalars in xmm2 and xmm3 > >> to > >> zmm16 and zmm17. > >> After that what you need to do is either change the fmaddss > >> instruction to use > >> xm0 and xm1 macros instead of xmm0 and xmm1 (so xmm16 and xmm17 > with > >> EVEX encoding is used), or much like the broadcast above use xmm2 and > >> xmm3 explicitly on win64, so it remains VEX encoded. > > > > So, to fix the issue, does this 2 changes looks good for you? > > First change the WIN64 swap from: > > SWAP xmm0, xmm2 > > SWAP xmm1, xmm3 > > To: > > VBROADCASTSS m0, xmm2 > > VBROADCASTSS m1, xmm3 > > > > Second change the fmaddss from: > > fmaddss xmm4, xmm4, xmm0, xmm1 > > To: > > fmaddss xmm4, xmm4, xm0, xm1 > > Yes. Appreciate for your help, I commit new patch here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20221114143551.9740-1-bin.w...@intel.com/ > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH v1] libavfilter/x86/vf_convolution: fix sobel swap issue on WIN64
On 11/14/2022 11:35 AM, bin.wang-at-intel@ffmpeg.org wrote: From: "Wang, Bin" Signed-off-by: Wang, Bin --- libavfilter/x86/vf_convolution.asm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavfilter/x86/vf_convolution.asm b/libavfilter/x86/vf_convolution.asm index c912d56752..a6be95690b 100644 --- a/libavfilter/x86/vf_convolution.asm +++ b/libavfilter/x86/vf_convolution.asm @@ -189,8 +189,8 @@ cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x %endif %if WIN64 -SWAP xmm0, xmm2 -SWAP xmm1, xmm3 +VBROADCASTSS m0, xmm2 +VBROADCASTSS m1, xmm3 The other two VBROADCASTSS below should be used on UNIX64 only. Otherwise they will overwrite m0 and m1 on WIN64. mov r2q, matrixmp mov r3q, ptrmp DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x @@ -281,7 +281,7 @@ cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, fmaddss xmm4, xmm5, xmm5, xmm4 sqrtpsxmm4, xmm4 -fmaddss xmm4, xmm4, xmm0, xmm1 ;sum = sum * rdiv + bias +fmaddss xmm4, xmm4, xm0, xm1 ;sum = sum * rdiv + bias cvttps2dq xmm4, xmm4 ; trunc to integer packssdw xmm4, xmm4 packuswb xmm4, xmm4 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Paul B Mahol > Sent: Monday, November 14, 2022 4:18 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > On 11/14/22, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> Anton Khirnov > >> Sent: Monday, November 14, 2022 3:35 PM > >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > >> the argument for submitting patches > >> > >> Quoting Soft Works (2022-11-14 12:20:00) > >> > > >> > > >> > > -Original Message- > >> > > From: ffmpeg-devel On Behalf > Of > >> > > Anton Khirnov > >> > > Sent: Monday, November 14, 2022 12:08 PM > >> > > To: FFmpeg development discussions and patches >> > > de...@ffmpeg.org> > >> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: > >> extend > >> > > the argument for submitting patches > >> > > > >> > > Quoting Soft Works (2022-11-14 11:46:49) > >> > > > > Sorry, but you problems are entirely self-inflicted. You > have > >> > > been > >> > > > > told what changes need to happen right from the beginning, > >> > > > > repeatedly, and by several developers independently. > >> > > > > >> > > > And those are completed and settled, like I had state > multiple > >> > > times. > >> > > > It's ready for review for months already. > >> > > > >> > > Your stating something does not make it true, no matter how > many > >> > > times > >> > > you do it. > >> > > > >> > > My objections were not addressed. > >> > > > >> > > In your last resend, Hendrik yet again raised the start_pts > >> question. > >> > > As > >> > > far as I can tell, your explanation for why it's supposedly > >> needed > >> > > did > >> > > not convince ANYONE. > >> > > >> > What means "as far as I can tell" here? Do you have something to > >> > say about it, then please do? > >> > >> It means that I am not aware of anyone who changed their stance > based > >> on > >> your arguments, but cannot prove that no such person exists. > > > > I'm afraid, but everything you are writing is making references to > > others and what they would think or what you are assuming that they > > might think. > > > >> I did read your document, and my takeaway message from it is > "doing > >> it > >> properly is too hard". As long as that continues to be your > position, > >> you might as well not bother. > > > > This is ridiculous, and you know that. Or at least you would know > > if you would have really tried to understand the problem. > > > > And that unfortunately applies to some others as well. Nobody is > > willing to go deep enough to the point where it becomes clear > > that a "perfect" solution would only be possible by making > fundamental > > changes to libavfilter, which are complex, risky and something > > that would never be accepted from me, even when it would be > > the most excellent solution. I think this is pretty clear to > > everybody here, and trying to present this in a light as if > > I would just be too lazy to go for it, is just despicable, > > I'm afraid. > > > > I wish you could stop referring to others potential opinions > > and get yourself as much into the subject as it is required to > > understand the actual problem and talk for yourself. > > > > Because I would happily discuss alternatives > > with you and follow your advice, no matter when it takes > > a little more effort - as long as it will still be possible > > to handle all cases like with the current patchset. > > But I mean substantial and detailed advice based on an > > understanding of the problems, not the kind of "no, that's > > bad, I don't believe you that it couldn't be done like I > > think it's gotta be". > > > > I will happily, gladly and friendly work and converse with > > anybody who would be so kind to leave one's peripheral > > spectator position and get down with me to the core > > problem and discuss potential solutions. > > They can not admit they have zero understanding why and how code > works > Instead they propose some nonsense that hardly can be implemented. I'm not saying that and I have no doubt they could.. sw ___ 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".
[FFmpeg-devel] [PATCH v2] libavfilter/x86/vf_convolution: fix sobel swap issue on WIN64
From: "Wang, Bin" Signed-off-by: Wang, Bin --- libavfilter/x86/vf_convolution.asm | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/libavfilter/x86/vf_convolution.asm b/libavfilter/x86/vf_convolution.asm index c912d56752..9ac9ef5d73 100644 --- a/libavfilter/x86/vf_convolution.asm +++ b/libavfilter/x86/vf_convolution.asm @@ -189,15 +189,16 @@ cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x %endif %if WIN64 -SWAP xmm0, xmm2 -SWAP xmm1, xmm3 +VBROADCASTSS m0, xmm2 +VBROADCASTSS m1, xmm3 mov r2q, matrixmp mov r3q, ptrmp DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x -%endif -movsxdifnidn widthq, widthd +%else VBROADCASTSS m0, xmm0 VBROADCASTSS m1, xmm1 +%endif +movsxdifnidn widthq, widthd pxor m6, m6 mov c0q, [ptrq + 0*gprsize] mov c1q, [ptrq + 1*gprsize] @@ -281,7 +282,7 @@ cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, fmaddss xmm4, xmm5, xmm5, xmm4 sqrtpsxmm4, xmm4 -fmaddss xmm4, xmm4, xmm0, xmm1 ;sum = sum * rdiv + bias +fmaddss xmm4, xmm4, xm0, xm1 ;sum = sum * rdiv + bias cvttps2dq xmm4, xmm4 ; trunc to integer packssdw xmm4, xmm4 packuswb xmm4, xmm4 -- 2.27.0 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Paul B Mahol > Sent: Monday, November 14, 2022 4:18 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > On 11/14/22, Soft Works wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> Anton Khirnov > >> Sent: Monday, November 14, 2022 3:35 PM > >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > >> the argument for submitting patches > >> > >> Quoting Soft Works (2022-11-14 12:20:00) > >> > > >> > > >> > > -Original Message- > >> > > From: ffmpeg-devel On Behalf > Of > >> > > Anton Khirnov > >> > > Sent: Monday, November 14, 2022 12:08 PM > >> > > To: FFmpeg development discussions and patches >> > > de...@ffmpeg.org> > >> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: > >> extend > >> > > the argument for submitting patches > >> > > > >> > > Quoting Soft Works (2022-11-14 11:46:49) > >> > > > > Sorry, but you problems are entirely self-inflicted. You > have > >> > > been > >> > > > > told what changes need to happen right from the beginning, > >> > > > > repeatedly, and by several developers independently. > >> > > > > >> > > > And those are completed and settled, like I had state > multiple > >> > > times. > >> > > > It's ready for review for months already. > >> > > > >> > > Your stating something does not make it true, no matter how > many > >> > > times > >> > > you do it. > >> > > > >> > > My objections were not addressed. > >> > > > >> > > In your last resend, Hendrik yet again raised the start_pts > >> question. > >> > > As > >> > > far as I can tell, your explanation for why it's supposedly > >> needed > >> > > did > >> > > not convince ANYONE. > >> > > >> > What means "as far as I can tell" here? Do you have something to > >> > say about it, then please do? > >> > >> It means that I am not aware of anyone who changed their stance > based > >> on > >> your arguments, but cannot prove that no such person exists. > > > > I'm afraid, but everything you are writing is making references to > > others and what they would think or what you are assuming that they > > might think. > > > >> I did read your document, and my takeaway message from it is > "doing > >> it > >> properly is too hard". As long as that continues to be your > position, > >> you might as well not bother. > > > > This is ridiculous, and you know that. Or at least you would know > > if you would have really tried to understand the problem. > > > > And that unfortunately applies to some others as well. Nobody is > > willing to go deep enough to the point where it becomes clear > > that a "perfect" solution would only be possible by making > fundamental > > changes to libavfilter, which are complex, risky and something > > that would never be accepted from me, even when it would be > > the most excellent solution. I think this is pretty clear to > > everybody here, and trying to present this in a light as if > > I would just be too lazy to go for it, is just despicable, > > I'm afraid. > > > > I wish you could stop referring to others potential opinions > > and get yourself as much into the subject as it is required to > > understand the actual problem and talk for yourself. > > > > Because I would happily discuss alternatives > > with you and follow your advice, no matter when it takes > > a little more effort - as long as it will still be possible > > to handle all cases like with the current patchset. > > But I mean substantial and detailed advice based on an > > understanding of the problems, not the kind of "no, that's > > bad, I don't believe you that it couldn't be done like I > > think it's gotta be". > > > > I will happily, gladly and friendly work and converse with > > anybody who would be so kind to leave one's peripheral > > spectator position and get down with me to the core > > problem and discuss potential solutions. > > They can not admit they have zero understanding why and how code > works > Instead they propose some nonsense that hardly can be implemented. Nobody has actually proposed anything. I wish somebody had. "No, not like this, I don't care whether and how it can be done otherwise" - is not a proposal. sw ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Quoting Soft Works (2022-11-14 16:13:29) > > I did read your document, and my takeaway message from it is "doing > > it > > properly is too hard". As long as that continues to be your position, > > you might as well not bother. > > This is ridiculous, and you know that. Or at least you would know > if you would have really tried to understand the problem. > > And that unfortunately applies to some others as well. Nobody is > willing to go deep enough to the point where it becomes clear > that a "perfect" solution would only be possible by making fundamental > changes to libavfilter, which are complex, risky and something > that would never be accepted from me, even when it would be > the most excellent solution. Stop with the drama, please. You are not a persecuted misunderstood genius. Nobody here has a personal grudge against you. The reason people, including me, are objecting to your patches is that they are not fundamental enough. You want to redo the subtitle API in a major way, but keep it saddled with legacy hacks right from the start. We have enough of those already to know we don't want any more. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Quoting Nicolas George (2022-11-14 13:40:35) > Anton Khirnov (12022-11-14): > > In what specific case would this supposed busy wait happen and why is it > > wrong? > > See my mail from 9 Nov 2022 13:42:24 +0100 for explanations about the > semantic of EAGAIN. You wrote a whole lot of text and I don't see how any of it applies to this patch. The standard convention everywhere is that IO may return EAGAIN in non-blocking mode and blocks otherwise. And that is exactly what this patch implements. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Anton Khirnov (12022-11-14): > You wrote a whole lot of text and I don't see how any of it applies to > this patch. > > The standard convention everywhere is that IO may return EAGAIN in > non-blocking mode and blocks otherwise. And that is exactly what this > patch implements. To implement blocking on top of EAGAIN, a sleep is necessary. REDO must not sleep. -- 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".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/electronicarts: add option to return alpha channel in the main video stream in VP6A codec
Quoting Marton Balint (2022-11-13 19:44:41)
> Signed-off-by: Marton Balint
> ---
> doc/demuxers.texi| 18
> libavformat/electronicarts.c | 42 +++-
> libavformat/version.h| 2 +-
> 3 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 2b6dd86c2a..f07f3f5318 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -285,6 +285,24 @@ This demuxer accepts the following option:
>
> @end table
>
> +@section ea
> +
> +Electronic Arts Multimedia format demuxer.
> +
> +This format is used by various Electronic Arts games.
> +
> +@subsection Options
> +
> +@table @option
> +
> +@item merge_alpha @var{bool}
> +
> +Normally the VP6 alpha channel (if exists) is returned as a secondary video
> +stream,
Why? And why keep it as the default?
--
Anton Khirnov
___
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".
Re: [FFmpeg-devel] [PATCH v2] libavfilter/x86/vf_convolution: fix sobel swap issue on WIN64
On 11/14/2022 12:20 PM, bin.wang-at-intel@ffmpeg.org wrote: From: "Wang, Bin" Signed-off-by: Wang, Bin --- libavfilter/x86/vf_convolution.asm | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/libavfilter/x86/vf_convolution.asm b/libavfilter/x86/vf_convolution.asm index c912d56752..9ac9ef5d73 100644 --- a/libavfilter/x86/vf_convolution.asm +++ b/libavfilter/x86/vf_convolution.asm @@ -189,15 +189,16 @@ cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x %endif %if WIN64 -SWAP xmm0, xmm2 -SWAP xmm1, xmm3 +VBROADCASTSS m0, xmm2 +VBROADCASTSS m1, xmm3 mov r2q, matrixmp mov r3q, ptrmp DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x -%endif -movsxdifnidn widthq, widthd +%else VBROADCASTSS m0, xmm0 VBROADCASTSS m1, xmm1 +%endif +movsxdifnidn widthq, widthd pxor m6, m6 mov c0q, [ptrq + 0*gprsize] mov c1q, [ptrq + 1*gprsize] @@ -281,7 +282,7 @@ cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, fmaddss xmm4, xmm5, xmm5, xmm4 sqrtpsxmm4, xmm4 -fmaddss xmm4, xmm4, xmm0, xmm1 ;sum = sum * rdiv + bias +fmaddss xmm4, xmm4, xm0, xm1 ;sum = sum * rdiv + bias cvttps2dq xmm4, xmm4 ; trunc to integer packssdw xmm4, xmm4 packuswb xmm4, xmm4 Should be ok. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Monday, November 14, 2022 5:14 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > Quoting Soft Works (2022-11-14 16:13:29) > > > I did read your document, and my takeaway message from it is > "doing > > > it > > > properly is too hard". As long as that continues to be your > position, > > > you might as well not bother. > > > > This is ridiculous, and you know that. Or at least you would know > > if you would have really tried to understand the problem. > > > > And that unfortunately applies to some others as well. Nobody is > > willing to go deep enough to the point where it becomes clear > > that a "perfect" solution would only be possible by making > fundamental > > changes to libavfilter, which are complex, risky and something > > that would never be accepted from me, even when it would be > > the most excellent solution. > > Stop with the drama, please. You are not a persecuted misunderstood > genius. Nobody here has a personal grudge against you. The reason > people, including me, are objecting to your patches is that they are > not > fundamental enough. You want to redo the subtitle API in a major way, > but keep it saddled with legacy hacks right from the start. We have > enough of those already to know we don't want any more. This is so disgusting! Why can't you just point at those "legacy hacks" and tell how you want to have it done instead? "not fundamental enough"? Where why and how? And why do you keep bullshitting me with such nonsense statements? What are your points? Which are your objections? Please show the code that you think is wrong and say how it should be done instead. Thanks, softworkz ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Soft Works (12022-11-14): > What are your points? Which are your objections? Please show the > code that you think is wrong and say how it should be done instead. For the record, I have, multiple times. -- 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".
Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec encoder and NDK MediaCodec support
Hello here is the work I have pushed in a fork of FFmpeg integrated in source code of xuggler (a Java/C++ wrapper of FFmpeg) https://github.com/olivierayache/xuggle-xuggler/commit/98469ebea59c921f46a114bd954f7a27a7c95a41 For the limitations of NDK I agree with you and that is why I have made some backport to be able to support all needed features for FFmpeg (when I worked on that it was FFmpeg 3.4.x version). This backport allows support to these functions for Android devices since API 21 (which is more than 99% of devices). - AMediaCodec_createInputSurface - AMediaCodec_setParameters - ANativeWindow_toSurface For testing reviewing the patch I will make it as soon as I update FFmpeg to the current version. I will be able to do it this week. Olivier Le dim. 13 nov. 2022, 12:49, Zhao Zhili a écrit : > > > From: ffmpeg-devel On Behalf Of > Olivier Ayache > > Sent: 2022年11月12日 18:00 > > To: FFmpeg development discussions and patches > > Cc: matthieu.bou...@stupeflix.com; a...@tmm1.net > > Subject: Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec > encoder and NDK MediaCodec support > > > > Hello there I implemented that few years ago in > > https://github.com/olivierayache/xuggle-xuggler/ > > I can't find where is the patch or source code of FFmpeg. > > > And when I tried to submit a patch to FFmpeg for add support for NDK I > had > > received this answer. > > I think using NDK directly rather than JNI can be better in case of > > developing native application on Android. > > NDK is still missing some important features, and some features only > supported recently. > So the NDK implementation doesn't meant to be a replacement of the JNI > version: > 1. JNI version has more features and supports more devices > 2. NDK implementation combined with some JNI functions has almost the same > feature > As JNI version on new devices. > 3. In the environment where JVM is unavailable, the NDK version is the > only choice. > > > If I can help on these subjects I would be really happy > > Welcome to review and/or test the patch. > > > > > Olivier Ayache > > > > > > > > -- Forwarded message - > > From: Olivier Ayache > > Date: Sun, Jun 28, 2020 at 2:48 PM > > Subject: Re: [FFmpeg-devel] [PATCH] add support to Android ndk MediaCodec > > for encoding/decoding > > To: > > > > > > Thank for your replies I choose the NDK approach in order to be able to > be > > independant from the JVM, to maximize performance and to be sure to > detect > > compatibility issues (using JNI approach can compile and crash at > runtime). > > Concerning the version of Android it is compatible from API 21 (94% of > > devices) > > I agree that JNI overhead is not big but in combinaison with Xuggler it > > seems to me a little weird because Xuggler (Java part) already use JNI to > > interact with Xuggler (C++) and FFmpeg. If FFmpeg uses JNI in the other > way > > (from c to Java) it seems to me an anti pattern. > > > > If you think it is better to begin to use JNI I could transform my > encoder > > and we could discuss about NDK after > > > > Olivier > > > > > > > > Le sam. 27 juin 2020 à 20:55, Martin Storsjö a écrit > : > > > > > On Sat, 27 Jun 2020, Olivier Ayache wrote: > > > > > > > Hi everyone this is the first time I post on this mailing list. I am > > > > working since several years on a fork of Xuggler for manipulating > ffmpeg > > > > API with Java/Kotlin. > > > > This work leads me to develop encoder and decoder based on Android > NDK > > > > MediaCodec. > > > > > > > > This work can be found on my Github repository > > > > > > > > https://github.com/olivierayache/xuggle-xuggler > > > > > > > > > > > > I know that FFmpeg already integrate MediaCodec for decoding via Jni > > > > wrappers since version 3.1. I began this work on FFmpeg 2.8.x and I > > > choose > > > > the NDK in order to achieve optimum performance. > > > > > > If you mean you used the NDK MediaCodec API, I'd suggest you use the > same > > > JNI wrappers as ffmpeg has already, for consistency. The overhead of a > few > > > JNI calls per encoded frame is generally negligible. If it, at a later > > > time, is decided to drop support for older versions at some point, it > > > should be straightforward to convert it to use the NDK MediaCodec API > > > instead. > > > > > > // Martin > > > > > > ___ > > > 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". > > > > > > On Sat, Nov 12, 2022 at 6:07 AM Zhao Zhili > wrote: > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > Chema > > > Gonzalez > > > > Sent: 2022年11月12日 0:55 > > > > To: FFmpeg development discussions and patches < > ffmpeg-devel@ffmpeg.org> > > > > Cc: matthieu.bou...@stupeflix.com; a...@tmm1.net > > > > Subject
Re: [FFmpeg-devel] [PATCH v2] avcodec/tiff: add read support for compressed rgb floating point formats
Quoting mindm...@gmail.com (2022-10-02 01:05:12) > From: Mark Reid > > floating point uses a slightly different predictor technique describe here > http://chriscox.org/TIFFTN3d1.pdf > > Here is a link the test files, if someone could add them to fate me > https://www.dropbox.com/s/fg59h2os4gb4wug/tiff_fate_samples.zip > > > --- > libavcodec/tiff.c | 68 ++ > tests/fate/image.mak | 20 ++- > tests/ref/fate/tiff-lzw-rgbaf32le | 6 ++ > tests/ref/fate/tiff-lzw-rgbf32le | 6 ++ > tests/ref/fate/tiff-uncompressed-rgbaf32le | 6 ++ > tests/ref/fate/tiff-uncompressed-rgbf32le | 6 ++ > tests/ref/fate/tiff-zip-rgbaf32le | 6 ++ > tests/ref/fate/tiff-zip-rgbf32le | 6 ++ > 8 files changed, 123 insertions(+), 1 deletion(-) > create mode 100644 tests/ref/fate/tiff-lzw-rgbaf32le > create mode 100644 tests/ref/fate/tiff-lzw-rgbf32le > create mode 100644 tests/ref/fate/tiff-uncompressed-rgbaf32le > create mode 100644 tests/ref/fate/tiff-uncompressed-rgbf32le > create mode 100644 tests/ref/fate/tiff-zip-rgbaf32le > create mode 100644 tests/ref/fate/tiff-zip-rgbf32le Looks acceptable, will push in a few days if nobody objects. But decode_frame() is starting to look very long and smelly and could definitely use some refactoring. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Monday, November 14, 2022 5:40 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > Soft Works (12022-11-14): > > What are your points? Which are your objections? Please show the > > code that you think is wrong and say how it should be done instead. > > For the record, I have, multiple times. You’ve been destructive from the very first moment when you realized that I was going to do something that you had been planning for a long time. You haven't missed a single occasion to discredit me or my work, keeping it vague just like Anton does right now, to keep things at a level where credibility weighs - instead than a technical facts. Ah, wait - there's one occasion where you never jumped on, never mentioned, talked about or objected: The separate subtitle timing fields. You know exactly why I have them and why these are needed, but you would rather bite your tongue than saying it, and so you kept quiet each time when others were criticizing it. Now you'll have to say that I'm wrong. I'm curious how you'll say it. PS: I'm sorry that I got in your way, I understood that much later only. It was just that I needed this functionality, not that I would have had a choice. Thanks, softworkz ___ 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".
Re: [FFmpeg-devel] [PATCH 1/8] fftools/ffmpeg: simplify ost_iter()
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 4:14 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/8] fftools/ffmpeg: simplify
> ost_iter()
>
> The inner loop never goes through more than 1 iteration, and so can
> be
> replaced by an if().
>
> Found-by: Andreas Rheinhardt
> ---
> fftools/ffmpeg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index e6f6773f6a..0fa2fe8c52 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -612,7 +612,7 @@ static OutputStream *ost_iter(OutputStream *prev)
>
> for (; of_idx < nb_output_files; of_idx++) {
> OutputFile *of = output_files[of_idx];
> -for (; ost_idx < of->nb_streams; ost_idx++)
> +if (ost_idx < of->nb_streams)
> return of->streams[ost_idx];
>
> ost_idx = 0;
> --
> 2.35.1
I'm objecting the whole patchset.
I think it's not fundamental enough.
softworkz
___
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".
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
Soft Works (12022-11-14): > You’ve been destructive from the very first moment when you realized > that I was going to do something that you had been planning for a > long time. I would have been very happy if you had worked on doing properly, or at least in a way compatible with doing it properly. This is exactly what Anton says. I have not read the rest of your message, since it is built on a lie. -- 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".
Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
On Sun, Nov 13, 2022 at 22:57:22 +0100, Oneric wrote:
> On Sun, Nov 13, 2022 at 21:01:34 +, Soft Works wrote:
> > I am unable to apply any of those patches. Neither v1 nor v2 neither
> > when downloading the series mbox or [2/3] from patchwork nor when
> > saving [2/3] from the e-mail.
>
> Re patchwork, yes I rechecked and it appears all downloads are now broken
> (see prev message). Regarding applying the mails, all I can say is it
> works for me.
I now know why the mbox files from patchwork don’t work for v1.
For whatever reason patchwork thought it a good idea to reorder the binary
diffs and while doing so separated diff headers from diff content so
nothing makes sense to git anymore. This gives a plausible explanation for
the loongarch error message, but now I’m not sure how the x86 FATE box
manages to apply anything (but whatever it does apply is probably
corrupted explaining the test failures).
The mails received from the list — apart from v3-patch3 — or the archive
with format-patches I sent, ofc still work.
For illustration here’s a truncated bit of the difference between the
received mail after base64 decoding and what patchwork offers as a
download for v1 patch number 2:
diff --git a/tmp/0002-from-mail_v1__decoded_data.patch
b/tmp/FFmpeg-devel-2-3-avcodec-ass-accurately-preserve-colours
.patch
index b2a7a93d7a..4691059715 100644
--- a/tmp/0002-from-mail_v1__decoded_data-.patch
+++ b/tmp/FFmpeg-devel-2-3-avcodec-ass-accurately-preserve-colours.patch
@@ -44,6 +154,95 @@ Link to libass’ docs regarding colour mangling:
tests/ref/fate/sub-webvtt2 | Bin 1648 -> 1668 bytes
25 files changed, 2 insertions(+)
+index
13f393cc86b9f797be24f37a07aafc7272c22e59..516d26af9ab09613f939d004826e44c80b3b1054
100644
+GIT binary patch
+delta 29
+kcmX@kcAITNgHWV%l5>%QZ(>PNW`&i4Uw&Td#=4VC0HTfx{Qv*}
+
+delta 10
+Rcmcc3cARZO!^SDcnE)Fg1kC^d
+
+index
be28084887a9b7fb80ae4ff3369cf7192a978919..a97d29f70ba1d3984887eacb6e833abb8a406902
100644
+GIT binary patch
+delta 29
+kcmdnUew2MegHWV%l5>%QZ(>PNW`&i4Uw&Td#yVqW0G!DRJ^%m!
+
+delta 10
+RcmX@gzL9-G!^SCw%m5g91P%ZI
+
[.. and a bunch more additions like this]
@@ -66,14 +265,6 @@ delta 10
RcmZ1|*(*7rVdE5D9sm~71J3{e
diff --git a/tests/ref/fate/sub-cc b/tests/ref/fate/sub-cc
-index
13f393cc86b9f797be24f37a07aafc7272c22e59..516d26af9ab09613f939d004826e44c80b3b1054
100644
-GIT binary patch
-delta 29
-kcmX@kcAITNgHWV%l5>%QZ(>PNW`&i4Uw&Td#=4VC0HTfx{Qv*}
-
-delta 10
-Rcmcc3cARZO!^SDcnE)Fg1kC^d
-
diff --git a/tests/ref/fate/sub-cc-realtime b/tests/ref/fate/sub-cc-realtime
index
169361f540e4dff43a132df395e55a19ff73..98dfef55019719911d6c5d9faa0c057cc324f227
100644
GIT binary patch
@@ -84,14 +275,6 @@ delta 10
RcmeC+`NBP+VdIn%Rsb0Q1Y!UH
diff --git a/tests/ref/fate/sub-cc-scte20 b/tests/ref/fate/sub-cc-scte20
-index
be28084887a9b7fb80ae4ff3369cf7192a978919..a97d29f70ba1d3984887eacb6e833abb8a406902
100644
-GIT binary patch
-delta 29
-kcmdnUew2MegHWV%l5>%QZ(>PNW`&i4Uw&Td#yVqW0G!DRJ^%m!
-
-delta 10
-RcmX@gzL9-G!^SCw%m5g91P%ZI
-
diff --git a/tests/ref/fate/sub-charenc b/tests/ref/fate/sub-charenc
index
4efacb073d14b43002b58ab0b4aa55e9d34de029..339137ae0b5485c4c954f859316cf8b413b01505
100644
GIT binary patch
[.. and more]
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".
Re: [FFmpeg-devel] [PATCH 3/7] avcodec/bonk: Remove special 32bit case from read_uint_max()
On 11/14/22, Michael Niedermayer wrote: > On Sun, Nov 06, 2022 at 07:28:48PM +0100, Paul B Mahol wrote: >> On 11/6/22, Michael Niedermayer wrote: >> > This case seems not to match the reference decoder and it also >> > seems not reachable >> > >> > Signed-off-by: Michael Niedermayer >> > --- >> > libavcodec/bonk.c | 3 +-- >> > 1 file changed, 1 insertion(+), 2 deletions(-) >> > >> > diff --git a/libavcodec/bonk.c b/libavcodec/bonk.c >> > index 04ea4def2f..fca8c246aa 100644 >> > --- a/libavcodec/bonk.c >> > +++ b/libavcodec/bonk.c >> > @@ -136,8 +136,7 @@ static unsigned read_uint_max(BonkContext *s, >> > uint32_t >> > max) >> > if (max == 0) >> > return 0; >> > >> > -if (max >> 31) >> > -return 32; >> > +av_assert0(max >> 31 == 0); >> > >> > for (unsigned i = 1; i <= max - value; i+=i) >> > if (get_bits1(&s->gb)) >> > -- >> > 2.17.1 >> >> >> Not sure, at your risk. >> >> Test lossy mode too. > > piotr provided me with a larger testset including lossy files > they are all unchanged > > will apply this and the other remaining patches. > They look all correct to me, if i am wrong which is always a possibility > iam human ... then you can revert whats wrong of course > Its not for valid, but for fuzzed files. > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If you drop bombs on a foreign country and kill a hundred thousand > innocent people, expect your government to call the consequence > "unprovoked inhuman terrorist attacks" and use it to justify dropping > more bombs and killing more people. The technology changed, the idea is > old. > ___ 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".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/electronicarts: add option to return alpha channel in the main video stream in VP6A codec
On Mon, 14 Nov 2022, Anton Khirnov wrote:
Quoting Marton Balint (2022-11-13 19:44:41)
Signed-off-by: Marton Balint
---
doc/demuxers.texi| 18
libavformat/electronicarts.c | 42 +++-
libavformat/version.h| 2 +-
3 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 2b6dd86c2a..f07f3f5318 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -285,6 +285,24 @@ This demuxer accepts the following option:
@end table
+@section ea
+
+Electronic Arts Multimedia format demuxer.
+
+This format is used by various Electronic Arts games.
+
+@subsection Options
+
+@table @option
+
+@item merge_alpha @var{bool}
+
+Normally the VP6 alpha channel (if exists) is returned as a secondary video
+stream,
Why? And why keep it as the default?
VP6 alpha in EA format is a second VP6 encoded video stream where only the
Y component is used and is interpreted as the alpha channel of the first
VP6 stream. The alpha VP6 stream is muxed separately from the main VP6
stream, has its own stream headers and packet headers. In theory the two
streams might not even have the same resolution (although most likely
that is not something that is seen or supported in the wild), but the
format is capable of doing it.
Merged VP6 alpha (also known as the VP6A codec) means that a packet of the
video stream contains the corresponding packet of both VP6 substreams like
this:
{OffsetOfAlpha, DataPacket, AlphaDataPacet}
So data and alpha data of a frame is merged to a single packet, this is
how VP6 video with alpha is muxed in FLV and SWF.
So the first approach is more like how the demuxer sees data in the EA
format, unfortunately it is different to what the FLV or SWF format
expects, so - having no better place for it in the framework - I decided
to do an optional format conversion in the EA demuxer.
I did not want to change the default, but certainly doable if people
prefer it.
Regards,
Marton
___
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".
Re: [FFmpeg-devel] [PATCH v3 1/4] swscale/input: add rgbaf32 input support
On Mon, Nov 14, 2022 at 1:08 PM Michael Niedermayer
wrote:
> On Sun, Nov 13, 2022 at 05:50:37PM -0800, Mark Reid wrote:
> > On Sun, Nov 13, 2022 at 1:25 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Wed, Nov 02, 2022 at 09:00:07PM -0700, mindm...@gmail.com wrote:
> > > > From: Mark Reid
> > > >
> > > > ---
> > > > libswscale/input.c | 172
> +
> > > > libswscale/utils.c | 4 ++
> > > > 2 files changed, 176 insertions(+)
> > > >
> > > > diff --git a/libswscale/input.c b/libswscale/input.c
> > > > index 7ff7bfaa01..4683284b0b 100644
> > > > --- a/libswscale/input.c
> > > > +++ b/libswscale/input.c
> > > > @@ -1284,6 +1284,136 @@ static void
> rgbaf16##endian_name##ToA_c(uint8_t
> > > *_dst, const uint8_t *_src, cons
> > > > rgbaf16_funcs_endian(le, 0)
> > > > rgbaf16_funcs_endian(be, 1)
> > > >
> > > > +#define rdpx(src) (is_be ? av_int2float(AV_RB32(&src)):
> > > av_int2float(AV_RL32(&src)))
> > > > +
> > > > +static av_always_inline void rgbaf32ToUV_half_endian(uint16_t *dstU,
> > > uint16_t *dstV, int is_be,
> > > > + const float
> *src,
> > > int width,
> > > > + int32_t
> *rgb2yuv,
> > > int comp)
> > > > +{
> > > > +int32_t ru = rgb2yuv[RU_IDX], gu = rgb2yuv[GU_IDX], bu =
> > > rgb2yuv[BU_IDX];
> > > > +int32_t rv = rgb2yuv[RV_IDX], gv = rgb2yuv[GV_IDX], bv =
> > > rgb2yuv[BV_IDX];
> > > > +int i;
> > > > +for (i = 0; i < width; i++) {
> > >
> > > > +int r = (lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+0]),
> > > 0.0f, 65535.0f)) +
> > > > + lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+4]),
> > > 0.0f, 65535.0f))) >> 1;
> > > > +int g = (lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+1]),
> > > 0.0f, 65535.0f)) +
> > > > + lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+5]),
> > > 0.0f, 65535.0f))) >> 1;
> > > > +int b = (lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+2]),
> > > 0.0f, 65535.0f)) +
> > > > + lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+6]),
> > > 0.0f, 65535.0f))) >> 1;
> > > > +
> > > > +dstU[i] = (ru*r + gu*g + bu*b +
> (0x10001<<(RGB2YUV_SHIFT-1)))
> > > >> RGB2YUV_SHIFT;
> > > > +dstV[i] = (rv*r + gv*g + bv*b +
> (0x10001<<(RGB2YUV_SHIFT-1)))
> > > >> RGB2YUV_SHIFT;
> > >
> > > I would expect this sort of code to use 2 lrintf() and 2 av_clipf()
> not 6
> > >
> > >
> > ya it is a bit excessive, I'll just remove the _half conversions for now,
> > they aren't strictly necessary as far as I can tell.
>
> do you see a problem with just factorizing them out ?
> it shouldnt be hard to reorder the operations
>
It's just fate checksums and float math that make me apprehensive :p.
hmm this code path doesn't actually seem to get tested by fate.
Now that I relook at it, the indexing looks wrong for the 3 channel formats
too.
>
> >
> >
> > >
> > > > +}
> > > > +}
> > > > +
> > > > +static av_always_inline void rgbaf32ToUV_endian(uint16_t *dstU,
> > > uint16_t *dstV, int is_be,
> > > > +const float *src,
> int
> > > width,
> > > > +int32_t *rgb2yuv,
> int
> > > comp)
> > > > +{
> > > > +int32_t ru = rgb2yuv[RU_IDX], gu = rgb2yuv[GU_IDX], bu =
> > > rgb2yuv[BU_IDX];
> > > > +int32_t rv = rgb2yuv[RV_IDX], gv = rgb2yuv[GV_IDX], bv =
> > > rgb2yuv[BV_IDX];
> > > > +int i;
> > > > +for (i = 0; i < width; i++) {
> > > > +int r = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+0]),
> 0.0f,
> > > 65535.0f));
> > > > +int g = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+1]),
> 0.0f,
> > > 65535.0f));
> > > > +int b = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+2]),
> 0.0f,
> > > 65535.0f));
> > > > +
> > > > +dstU[i] = (ru*r + gu*g + bu*b +
> (0x10001<<(RGB2YUV_SHIFT-1)))
> > > >> RGB2YUV_SHIFT;
> > > > +dstV[i] = (rv*r + gv*g + bv*b +
> (0x10001<<(RGB2YUV_SHIFT-1)))
> > > >> RGB2YUV_SHIFT;
> > > > +}
> > > > +}
> > > > +
> > >
> > > > +static av_always_inline void rgbaf32ToY_endian(uint16_t *dst, const
> > > float *src, int is_be,
> > > > + int width, int32_t
> > > *rgb2yuv, int comp)
> > > > +{
> > > > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by =
> > > rgb2yuv[BY_IDX];
> > > > +int i;
> > > > +for (i = 0; i < width; i++) {
> > > > +int r = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+0]),
> 0.0f,
> > > 65535.0f));
> > > > +int g = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+1]),
> 0.0f,
> > > 65535.0f));
> > > > +int b = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+2]),
> 0.0f,
> > > 65535.0f));
> > > > +
> > >
> > > > +dst[i] = (ry*r + gy*g + by*b + (0x2001<<(RGB2YUV_SHIFT-1)))
> >>
> > > RGB2YUV_SHIFT;
> > >
> > > there is one output so there should be only need f
Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Monday, November 14, 2022 11:06 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > On Mon, Nov 14, 2022 at 05:13:40PM +0100, Anton Khirnov wrote: > > Quoting Soft Works (2022-11-14 16:13:29) > > > > I did read your document, and my takeaway message from it is > "doing > > > > it > > > > properly is too hard". As long as that continues to be your > position, > > > > you might as well not bother. > > > > > > This is ridiculous, and you know that. Or at least you would know > > > if you would have really tried to understand the problem. > > > > > > And that unfortunately applies to some others as well. Nobody is > > > willing to go deep enough to the point where it becomes clear > > > that a "perfect" solution would only be possible by making > fundamental > > > changes to libavfilter, which are complex, risky and something > > > that would never be accepted from me, even when it would be > > > the most excellent solution. > > > > Stop with the drama, please. You are not a persecuted misunderstood > > genius. Nobody here has a personal grudge against you. The reason > > people, including me, are objecting to your patches is that they > are not > > fundamental enough. You want to redo the subtitle API in a major > way, > > but keep it saddled with legacy hacks right from the start. We have > > enough of those already to know we don't want any more. > > Maybe people should take a step back and together discuss with > softworks > what changes need to be done. > > This thread is a bit odd becasue from reading just it its very clear > there > are objections but what exactly needs to be done to move this forward > is > not so clear (to me at least). To me neither. Until today. > I think a patch review should result in a clear list of things that > need > to be done. > Then these things can be gone through one by one. What can be done > what not > where there is consensus, where not and why ... > > If a request to a fundamental redesign is there then thats what it is > and maybe noone will do it but IMHO it should be clear so everyone > understands > what is requested > > As it is, this thread simply makes me sad because its deadlocked, > there is > some will and effort on one side and that isnt directed into anything > that > goes into the ffmpeg codebase ... I had a friendly chat with Anton on IRC about it. Bottom line is that he insists that I re-work libavfilter filtering from the ground up to support non-monotonous pts values in graph processing. The reason is that the single time_64t field that I want to add as a member to AVFrame would not be acceptable because it would make timestamp handling "too messy". Other objections haven't been made. I asked multiple times whether he would be serious about this, demanding me to take on a possibly multi- month work for the reason that having a single additional field in AVFrame would be messy, which he confirmed. I said it would be a huge amount of work and too much for me to take. He doubted, saying it can't be that much, I asked what he would expect me to change and how: Nov 14 19:08:02i can't say what to change exactly without actually doing it Nov 14 19:08:22i didn't write that code, I only have a very rought idea what it does Full transcript on request. I got no more words. Except about the irony that reveals when looking at the subject and who wrote it. Thanks, Michael! softworkz ___ 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".
