Re: [FFmpeg-devel] [PATCH] Moves yuv2yuvX_sse3 to yasm, unrolls main loop and other small optimizations for ~20% speedup.

2021-01-11 Thread Alan Kelly
It's a bug in the patch. The tail not processed by the sse3/avx2 version is
done by the mmx version. I used offset to account for the src pixels
already processed, however, dither is modified if offset is not 0. In cases
where there is a tail and offset is 0, this bug appears. I am working on a
solution.

On Sun, Jan 10, 2021 at 4:26 PM Michael Niedermayer 
wrote:

> On Thu, Jan 07, 2021 at 10:41:19AM +0100, Alan Kelly wrote:
> > ---
> >  Replaces mova with movdqu due to alignment issues
> >  libswscale/x86/Makefile |   1 +
> >  libswscale/x86/swscale.c| 106 +---
> >  libswscale/x86/yuv2yuvX.asm | 117 
> >  tests/checkasm/sw_scale.c   |  98 ++
> >  4 files changed, 246 insertions(+), 76 deletions(-)
> >  create mode 100644 libswscale/x86/yuv2yuvX.asm
>
> I have one / some ? cases where this changes output
>  ./ffmpeg -i utvideo-yuv422p10le_UQY2_crc32-A431CD5F.avi -bitexact avi.avi
>
>  i dont know if theres a decoder bug or bug in the patch or something else
>
> -rw-r- 1 michael michael 246218 Jan 10 16:23 avi.avi
> -rw-r- 1 michael michael 245824 Jan 10 16:23 avi-ref.avi
>
> file should be at:
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4044/
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
> ___
> 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] Add support for "omp simd" pragma.

2021-01-11 Thread Paul B Mahol
On Mon, Jan 11, 2021 at 1:26 AM Carl Eugen Hoyos  wrote:

> Am So., 10. Jan. 2021 um 19:55 Uhr schrieb Lynne :
> >
> > Jan 10, 2021, 17:43 by reimar.doeffin...@gmx.de:
> >
> > > From: Reimar Döffinger 
> > >
> > > This requests loops to be vectorized using SIMD
> > > instructions.
> > > The performance increase is far from hand-optimized
> > > assembly but still significant over the plain C version.
> > > Typical values are a 2-4x speedup where a hand-written
> > > version would achieve 4x-10x.
> > > So it is far from a replacement, however some architures
> > > will get hand-written assembler quite late or not at all,
> > > and this is a good improvement for a trivial amount of work.
> > > The cause, besides the compiler being a compiler, is
> > > usually that it does not manage to use saturating instructions
> > > and thus has to use 32-bit operations where actually
> > > saturating 16-bit operations would be sufficient.
> > > Other causes are for example the av_clip functions that
> > > are not ideal for vectorization (and even as scalar code
> > > not optimal for any modern CPU that has either CSEL or
> > > MAX/MIN instructions).
> > > And of course this only works for relatively simple
> > > loops, the IDCT functions for example seemed not possible
> > > to optimize that way.
> > > Also note that while clang may accept the code and sometimes
> > > produces warnings, it does not seem to do anything actually
> > > useful at all.
> > > Here are example measurements using gcc 10 under Linux (in a VM
> unfortunately)
> > > on AArch64 on Apple M1:
> > > Commad:
> > > time ./ffplay_g LG\ 4K\ HDR\ Demo\ -\ New\ York.ts -t 10 -autoexit
> -threads 1 -noframedrop
> > >
> > > Original code:
> > > real0m19.572s
> > > user0m23.386s
> > > sys 0m0.213s
> > >
> > > Changing all put_hevc:
> > > real0m15.648s
> > > user0m19.503s (83.4% of original)
> > > sys 0m0.186s
> > >
> > > In addition changing add_residual:
> > > real0m15.424s
> > > user0m19.278s (82.4% of original)
> > > sys 0m0.133s
> > >
> > > In addition changing planar copy dither:
> > > real0m15.040s
> > > user0m18.874s (80.7% of original)
> > > sys 0m0.168s
> > >
> >
> > I think I have to disagree.
>
> > The performance gains are marginal
>
> This sounds wrong.
>

I disagree with Carl.


>
> Carl Eugen
> ___
> 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] [RFC] Tech Resolution Process

2021-01-11 Thread Jean-Baptiste Kempf
On Sun, 6 Dec 2020, at 15:10, Nicolas George wrote:
> I think another clause is needed around here:

Added.

> > +Further replies to answers are permitted, as long as they conform to the
> > +community standards of politeness, they are limited to 100 words, and are 
> > not
> > +nested more than once. (max-depth=2)
> > +
> > +After the end-date, no mail on the thread is accepted.
> > +
> > +Violations of this rule will give a ban of the mailing-list.
> 
> This sounds harsh and unnecessary. What are the reasons for these
> limits?

Removed for the ban part.

The limits are to ensure this does not get into another discussion/fight on the 
topic, which should have been done before.
This is to collect opinions, not restart the discussion.

> > +The reasons for the decisions from the TC can be kept internal by the TC,
> > +if deemed necessary.
> 
> This feels shady. I suggest to reverse the wording, and make it much
> stronger:
> 
> # The decision of the TC is published along with a summary of the reasons
> # that lead to the decision, 

Added.

> and the archives of the internal discussion
> # are made available. 

Personal emails must stay personal.
And it can be done through other communications means, like Phone, or RTC, or 
IRC queries...

They must explain their reasons, but they should be allow to discuss freely.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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] [RFC][v2] Tech Resolution Process

2021-01-11 Thread Jean-Baptiste Kempf
---
 doc/dev_community/resolution_process.md | 89 +
 1 file changed, 89 insertions(+)
 create mode 100644 doc/dev_community/resolution_process.md

diff --git a/doc/dev_community/resolution_process.md 
b/doc/dev_community/resolution_process.md
new file mode 100644
index 00..91999202cb
--- /dev/null
+++ b/doc/dev_community/resolution_process.md
@@ -0,0 +1,89 @@
+# Technical Committee
+
+_This document only makes sense with the rules from [the community 
document](community)_.
+
+The Technical Committee (**TC**) is here to arbitrate and make decisions when
+technical conflicts occur in the project.
+
+The TC main role is to resolve technical conflicts.
+It is therefore not a technical steering committee, but it is understood that
+some decisions might impact the future of the project.
+
+# Process
+
+## Seizing
+
+The TC can take possession of any technical matter that it sees fit.
+
+To involve the TC in a matter, email tc@ or CC them on an ongoing discussion.
+
+As members of TC are developers, they also can email tc@ to raise an issue.
+
+## Announcement
+
+The TC, once seized, must announce itself on the main mailing list, with a 
_[TC]_ tag.
+
+The TC has 2 modes of operation: a RFC one and an internal one.
+
+If the TC thinks it needs the input from the larger community, the TC can call
+for a RFC. Else, it can decide by itself.
+
+If the disagreement involves a member of the TC, that member should recuse
+themselves from the decision.
+
+The decision to use a RFC process or an internal discussion is a discretionary
+decision of the TC.
+
+The TC can also reject a seizure for a few reasons such as:
+the matter was not discussed enough previously; it lacks expertise to reach a
+beneficial decision on the matter; or the matter is too trivial.
+
+### RFC call
+
+In the RFC mode, one person from the TC posts on the mailing list the
+technical question and will request input from the community.
+
+The mail will have the following specification:
+* a precise title
+* a specific tag [TC RFC]
+* a top-level email
+* contain a precise question that does not exceed 100 words and that is 
answerable by developers
+* contain a precise end date for the answers.
+
+The answers from the community must be on the main mailing list and must have
+the following specification:
+* keep the tag and the title unchanged
+* limited to 400 words
+* a first-level, answering directly to the main email
+* answering to the question.
+
+Further replies to answers are permitted, as long as they conform to the
+community standards of politeness, they are limited to 100 words, and are not
+nested more than once. (max-depth=2)
+
+After the end-date, no mail on the thread is accepted.
+
+Violations of this rule will escalated through the Community Committee.
+
+After all the emails are in, the TC has 96 hours to give its final decision.
+Exceptionally, the TC can request an extra delay.
+
+### Within TC
+
+In the internal case, the TC has 96 hours to give its final decision.
+Exceptionally, the TC can request an extra delay.
+
+
+## Decisions
+
+The decisions from the TC will be sent on the mailing list, with the _[TC]_ 
tag.
+
+Internally, the TC should take decisions with a majority, or using
+ranked-choice voting.
+
+The decision from the TC should be published with a summary of the reasons that
+lead to this decision.
+
+The decisions from the TC are final, until the matters are reopened after
+no less than one year, the GA or the TC auto-seizing.
+
-- 
2.30.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] avcodec/cbs: constify decompose_unit_types

2021-01-11 Thread James Almer

On 1/10/2021 8:04 PM, Andreas Rheinhardt wrote:

James Almer:

CBS doesn't change its contents in any way whatsoever internally, and most
users already set it to a const array.

Signed-off-by: James Almer 
---
  libavcodec/av1_frame_split_bsf.c | 2 +-
  libavcodec/av1_parser.c  | 2 +-
  libavcodec/cbs.h | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/av1_frame_split_bsf.c b/libavcodec/av1_frame_split_bsf.c
index 13bebe19f5..fa8b887b6c 100644
--- a/libavcodec/av1_frame_split_bsf.c
+++ b/libavcodec/av1_frame_split_bsf.c
@@ -214,7 +214,7 @@ static int av1_frame_split_init(AVBSFContext *ctx)
  if (ret < 0)
  return ret;
  
-s->cbc->decompose_unit_types= (CodedBitstreamUnitType*)decompose_unit_types;

+s->cbc->decompose_unit_types= decompose_unit_types;
  s->cbc->nb_decompose_unit_types = FF_ARRAY_ELEMS(decompose_unit_types);
  
  if (!ctx->par_in->extradata_size)

diff --git a/libavcodec/av1_parser.c b/libavcodec/av1_parser.c
index 181ff3a1be..6a76ffb7bc 100644
--- a/libavcodec/av1_parser.c
+++ b/libavcodec/av1_parser.c
@@ -191,7 +191,7 @@ static av_cold int av1_parser_init(AVCodecParserContext 
*ctx)
  if (ret < 0)
  return ret;
  
-s->cbc->decompose_unit_types= (CodedBitstreamUnitType *)decompose_unit_types;

+s->cbc->decompose_unit_types= decompose_unit_types;
  s->cbc->nb_decompose_unit_types = FF_ARRAY_ELEMS(decompose_unit_types);
  
  return 0;

diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index 3fd0a0ef33..f022282b75 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -196,7 +196,7 @@ typedef struct CodedBitstreamContext {
   * Types not in this list will be available in bitstream form only.
   * If NULL, all supported types will be decomposed.
   */
-CodedBitstreamUnitType *decompose_unit_types;
+const CodedBitstreamUnitType *decompose_unit_types;
  /**
   * Length of the decompose_unit_types array.
   */


LGTM.

- Andreas


Applied, thanks.
___
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 0/3] Initial implementation of TTML encoding/muxing

2021-01-11 Thread Jan Ekström
I've intentionally kept this initial version simple (no styling etc) to focus
on the basics. As this goes through review, additional features can be added
(I had initial PoC for styling implemented some time around previous VDD), and
there is another patch set in my queue which would then add support for muxing
TTML into MP4.

Changes from the initial version:
  - Switched to the initial idea posted on IRC that by having *any* extradata
the muxing mode is switched to document based as opposed to paragraph
based in the muxer.

Additionally, the muxer now blocks writing of multiple documents into a
single output.

My alternative idea would have been to attach side data specifying that
this is a TTML paragraph (as opposed to a full XML document that would come
out of demuxing) to the returned AVPacket, but it seems like I keep
forgetting that subtitle encoding currently does not return AVPackets,
but buffers.
  - Improved error codes (AVERROR_BUFFER_TOO_SMALL, EINVAL instead of ENOSYS,
error handling in ttml_encode_init)
  - Switched to av_strlcpy in order to properly null-terminate the output
buffers from the TTML encoder.
  - Renamed AVStream called s to st as it indeed was confusing.
  - Switched to utilizing avio_w8 when writing a single byte in the muxer.

Jan

Jan Ekström (2):
  ffprobe: switch to av_bprint_escape for XML escaping
  {avcodec,avformat}: add TTML encoder and muxer

Stefano Sabatini (1):
  avutil/{avstring,bprint}: add XML escaping from ffprobe to avutil

 Changelog  |   1 +
 doc/general_contents.texi  |   1 +
 fftools/ffprobe.c  |  29 ++
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/ttmlenc.c   | 178 +
 libavcodec/version.h   |   4 +-
 libavformat/Makefile   |   1 +
 libavformat/allformats.c   |   1 +
 libavformat/ttmlenc.c  | 166 ++
 libavformat/version.h  |   4 +-
 libavutil/avstring.h   |   1 +
 libavutil/bprint.c |  14 +++
 tests/fate/subtitles.mak   |   3 +
 tests/ref/fate/sub-ttmlenc | 122 +
 tools/ffescape.c   |   1 +
 16 files changed, 503 insertions(+), 25 deletions(-)
 create mode 100644 libavcodec/ttmlenc.c
 create mode 100644 libavformat/ttmlenc.c
 create mode 100644 tests/ref/fate/sub-ttmlenc

-- 
2.29.2

___
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 2/3] ffprobe: switch to av_bprint_escape for XML escaping

2021-01-11 Thread Jan Ekström
From: Jan Ekström 

Signed-off-by: Jan Ekström 
---
 fftools/ffprobe.c | 29 -
 1 file changed, 8 insertions(+), 21 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 3453aa09ff..b1fccad65e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1672,24 +1672,6 @@ static av_cold int xml_init(WriterContext *wctx)
 return 0;
 }
 
-static const char *xml_escape_str(AVBPrint *dst, const char *src, void 
*log_ctx)
-{
-const char *p;
-
-for (p = src; *p; p++) {
-switch (*p) {
-case '&' : av_bprintf(dst, "%s", "&");  break;
-case '<' : av_bprintf(dst, "%s", "<");   break;
-case '>' : av_bprintf(dst, "%s", ">");   break;
-case '"' : av_bprintf(dst, "%s", """); break;
-case '\'': av_bprintf(dst, "%s", "'"); break;
-default: av_bprint_chars(dst, *p, 1);
-}
-}
-
-return dst->str;
-}
-
 #define XML_INDENT() printf("%*c", xml->indent_level * 4, ' ')
 
 static void xml_print_section_header(WriterContext *wctx)
@@ -1761,14 +1743,19 @@ static void xml_print_str(WriterContext *wctx, const 
char *key, const char *valu
 
 if (section->flags & SECTION_FLAG_HAS_VARIABLE_FIELDS) {
 XML_INDENT();
+av_bprint_escape(&buf, key, NULL, AV_ESCAPE_MODE_XML, 0);
 printf("<%s key=\"%s\"",
-   section->element_name, xml_escape_str(&buf, key, wctx));
+   section->element_name, buf.str);
 av_bprint_clear(&buf);
-printf(" value=\"%s\"/>\n", xml_escape_str(&buf, value, wctx));
+
+av_bprint_escape(&buf, value, NULL, AV_ESCAPE_MODE_XML, 0);
+printf(" value=\"%s\"/>\n", buf.str);
 } else {
 if (wctx->nb_item[wctx->level])
 printf(" ");
-printf("%s=\"%s\"", key, xml_escape_str(&buf, value, wctx));
+
+av_bprint_escape(&buf, value, NULL, AV_ESCAPE_MODE_XML, 0);
+printf("%s=\"%s\"", key, buf.str);
 }
 
 av_bprint_finalize(&buf, NULL);
-- 
2.29.2

___
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 1/3] avutil/{avstring, bprint}: add XML escaping from ffprobe to avutil

2021-01-11 Thread Jan Ekström
From: Stefano Sabatini 

---
 libavutil/avstring.h |  1 +
 libavutil/bprint.c   | 14 ++
 tools/ffescape.c |  1 +
 3 files changed, 16 insertions(+)

diff --git a/libavutil/avstring.h b/libavutil/avstring.h
index ee225585b3..79bb920a70 100644
--- a/libavutil/avstring.h
+++ b/libavutil/avstring.h
@@ -324,6 +324,7 @@ enum AVEscapeMode {
 AV_ESCAPE_MODE_AUTO,  ///< Use auto-selected escaping mode.
 AV_ESCAPE_MODE_BACKSLASH, ///< Use backslash escaping.
 AV_ESCAPE_MODE_QUOTE, ///< Use single-quote escaping.
+AV_ESCAPE_MODE_XML,   ///< Use XML non-markup character data escaping.
 };
 
 /**
diff --git a/libavutil/bprint.c b/libavutil/bprint.c
index 2f059c5ba6..d825b61b14 100644
--- a/libavutil/bprint.c
+++ b/libavutil/bprint.c
@@ -283,6 +283,20 @@ void av_bprint_escape(AVBPrint *dstbuf, const char *src, 
const char *special_cha
 av_bprint_chars(dstbuf, '\'', 1);
 break;
 
+case AV_ESCAPE_MODE_XML:
+/* escape XML non-markup character data as per 2.4 */
+for (; *src; src++) {
+switch (*src) {
+case '&' : av_bprintf(dstbuf, "%s", "&");  break;
+case '<' : av_bprintf(dstbuf, "%s", "<");   break;
+case '>' : av_bprintf(dstbuf, "%s", ">");   break;
+case '"' : av_bprintf(dstbuf, "%s", """); break;
+case '\'': av_bprintf(dstbuf, "%s", "'"); break;
+default: av_bprint_chars(dstbuf, *src, 1);
+}
+}
+break;
+
 /* case AV_ESCAPE_MODE_BACKSLASH or unknown mode */
 default:
 /* \-escape characters */
diff --git a/tools/ffescape.c b/tools/ffescape.c
index 0530d28c6d..8537235d5e 100644
--- a/tools/ffescape.c
+++ b/tools/ffescape.c
@@ -104,6 +104,7 @@ int main(int argc, char **argv)
 if  (!strcmp(optarg, "auto"))  escape_mode = 
AV_ESCAPE_MODE_AUTO;
 else if (!strcmp(optarg, "backslash")) escape_mode = 
AV_ESCAPE_MODE_BACKSLASH;
 else if (!strcmp(optarg, "quote")) escape_mode = 
AV_ESCAPE_MODE_QUOTE;
+else if (!strcmp(optarg, "xml"))   escape_mode = 
AV_ESCAPE_MODE_XML;
 else {
 av_log(NULL, AV_LOG_ERROR,
"Invalid value '%s' for option -m, "
-- 
2.29.2

___
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] avformat/fifo: utilize a clone packet for muxing

2021-01-11 Thread Jan Ekström
On Tue, Dec 8, 2020 at 2:54 PM Jan Ekström  wrote:
>
> From: Jan Ekström 
>
> This way the timestamp adjustments do not have to be manually
> undone in case of failure and need to recover/retry.
>
> Fixes an issue where the timestamp adjustment would be re-done over
> and over again when recovery by muxing the same AVPacket again is
> attempted. Would become visible if the fifo muxer's time base and
> the output muxer's time base do not match (by the value either
> becoming smaller and smaller, or larger and larger).
>
> Signed-off-by: Jan Ekström 

Ping.

Unless someone finds some disgruntling points in this patch, I will
soon move towards applying this.

My initial plan was to make a simplified v2 where the output AVPacket
was on stack limited to the fifo_thread_write_packet context, but
apparently gradual removal of stack usage of AVPackets is being
planned, so I decided to not to.

Best regards,
Jan
___
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 0/5] FIFO meta muxer related improvements

2021-01-11 Thread Jan Ekström
On Mon, Dec 7, 2020 at 12:08 PM Jan Ekström  wrote:
>
> The primary parts of this are patches 1,4,5. 2 and 3 were just noticed when
> poking at the recovery timestamp logic, where the stream-time comparison logic
> seemed somewhat weird (such as comparing the pts to last_recovery_ts only if
> last_recovery_ts == AV_NOPTS_VALUE). If they seem incorrectly understood,
> they can be left out.
>
> As for the rest of the patches, they address the following issues:
> 1. Even if the header and the first packet get written out, the muxer might
>still fail at writing to a server when it actually decides to do I/O.
>Currently (for example with the MP4 muxer) this leads to a constant retry
>loop as each recovery is actually "successful". This patch makes sure that
>even if a recovery is "successful", the following recovery will only happen
>after the configured time, easing the load on any receiving server.
> 4. In case of avformat_write_header failing, the fifo muxer until now would 
> not
>close the avformat context and its underlying I/O. This is now added, so
>that file sockets do not keep creeping up.
> 5. Unset a configured codec_tag if it is not supported by the underlying 
> muxer,
>as the API client has no visibility regarding whether a codec tag is
>acceptable in cases of meta-muxers such as fifo.
>
> Jan
>
> Bernard Boulay (1):
>   avformat/fifo: always wait recovery_wait_time between recoveries
>
> Jan Ekström (4):
>   avformat/fifo: fix handling of stream-time non-NOPTS recovery
>   avformat/fifo: cause immediate stream-time recovery if time went
> backwards
>   avformat/fifo: close IO in case header writing fails
>   avformat/fifo: unset codec tag if unsupported by underlying muxer
>
>  libavformat/fifo.c | 77 ++
>  1 file changed, 51 insertions(+), 26 deletions(-)
>

Ping for this patch set.

Jan
___
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] [RFC][v2] Tech Resolution Process

2021-01-11 Thread Lynne
Jan 11, 2021, 14:03 by j...@videolan.org:

> ---
>  doc/dev_community/resolution_process.md | 89 +
>  1 file changed, 89 insertions(+)
>  create mode 100644 doc/dev_community/resolution_process.md
>
> diff --git a/doc/dev_community/resolution_process.md 
> b/doc/dev_community/resolution_process.md
> new file mode 100644
> index 00..91999202cb
> --- /dev/null
> +++ b/doc/dev_community/resolution_process.md
> @@ -0,0 +1,89 @@
> +# Technical Committee
> +
> +_This document only makes sense with the rules from [the community 
> document](community)_.
> +
> +The Technical Committee (**TC**) is here to arbitrate and make decisions when
> +technical conflicts occur in the project.
> +
> +The TC main role is to resolve technical conflicts.
> +It is therefore not a technical steering committee, but it is understood that
> +some decisions might impact the future of the project.
> +
> +# Process
> +
> +## Seizing
> +
> +The TC can take possession of any technical matter that it sees fit.
> +
> +To involve the TC in a matter, email tc@ or CC them on an ongoing discussion.
> +
> +As members of TC are developers, they also can email tc@ to raise an issue.
> +
> +## Announcement
> +
> +The TC, once seized, must announce itself on the main mailing list, with a 
> _[TC]_ tag.
> +
> +The TC has 2 modes of operation: a RFC one and an internal one.
> +
> +If the TC thinks it needs the input from the larger community, the TC can 
> call
> +for a RFC. Else, it can decide by itself.
> +
> +If the disagreement involves a member of the TC, that member should recuse
> +themselves from the decision.
> +
> +The decision to use a RFC process or an internal discussion is a 
> discretionary
> +decision of the TC.
> +
> +The TC can also reject a seizure for a few reasons such as:
> +the matter was not discussed enough previously; it lacks expertise to reach a
> +beneficial decision on the matter; or the matter is too trivial.
> +
> +### RFC call
> +
> +In the RFC mode, one person from the TC posts on the mailing list the
> +technical question and will request input from the community.
> +
> +The mail will have the following specification:
> +* a precise title
> +* a specific tag [TC RFC]
> +* a top-level email
> +* contain a precise question that does not exceed 100 words and that is 
> answerable by developers
> +* contain a precise end date for the answers.
>
Add a line like "may have a description of unlimited length".
So only the question part is limited to 100 words, while the description
may be as long as necessary as long as its separate (e.g. in another paragraph).



> +The answers from the community must be on the main mailing list and must have
> +the following specification:
> +* keep the tag and the title unchanged
> +* limited to 400 words
> +* a first-level, answering directly to the main email
> +* answering to the question.
> +
> +Further replies to answers are permitted, as long as they conform to the
> +community standards of politeness, they are limited to 100 words, and are not
> +nested more than once. (max-depth=2)
> +
> +After the end-date, no mail on the thread is accepted.
> +
> +Violations of this rule will escalated through the Community Committee.
>
That seems a bit harsh. Posting after the end-date should be acceptable
so long as a reasonable standard of conversation is maintained.
Working around this by not posting on the thread would also work.
Just remove this rule or modify it like "posts after the end-date will
be ignored by the TC".



> +
> +After all the emails are in, the TC has 96 hours to give its final decision.
> +Exceptionally, the TC can request an extra delay.
> +
> +### Within TC
> +
> +In the internal case, the TC has 96 hours to give its final decision.
> +Exceptionally, the TC can request an extra delay.
> +
> +
> +## Decisions
> +
> +The decisions from the TC will be sent on the mailing list, with the _[TC]_ 
> tag.
> +
> +Internally, the TC should take decisions with a majority, or using
> +ranked-choice voting.
> +
> +The decision from the TC should be published with a summary of the reasons 
> that
> +lead to this decision.
> +
> +The decisions from the TC are final, until the matters are reopened after
> +no less than one year, the GA or the TC auto-seizing.
>

What was the GA again?
And the one year limit doesn't apply for the TC or the GA, right?
___
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 3/3] {avcodec, avformat}: add TTML encoder and muxer

2021-01-11 Thread Jan Ekström
From: Jan Ekström 

Enables encoding of other subtitle formats into TTML and writing
them out as such documents.

Signed-off-by: Jan Ekström 
---
 Changelog  |   1 +
 doc/general_contents.texi  |   1 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/ttmlenc.c   | 178 +
 libavcodec/version.h   |   4 +-
 libavformat/Makefile   |   1 +
 libavformat/allformats.c   |   1 +
 libavformat/ttmlenc.c  | 166 ++
 libavformat/version.h  |   4 +-
 tests/fate/subtitles.mak   |   3 +
 tests/ref/fate/sub-ttmlenc | 122 +
 12 files changed, 479 insertions(+), 4 deletions(-)
 create mode 100644 libavcodec/ttmlenc.c
 create mode 100644 libavformat/ttmlenc.c
 create mode 100644 tests/ref/fate/sub-ttmlenc

diff --git a/Changelog b/Changelog
index dcb80e0ed9..11a67fcc02 100644
--- a/Changelog
+++ b/Changelog
@@ -55,6 +55,7 @@ version :
 - asuperpass and asuperstop filter
 - shufflepixels filter
 - tmidequalizer filter
+- TTML subtitle encoder and muxer
 
 
 version 4.3:
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 443e8ed8d1..d799382f84 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -1334,6 +1334,7 @@ performance on systems without hardware floating point 
support).
 @item SubViewer v1 @tab   @tab X @tab   @tab X
 @item SubViewer@tab   @tab X @tab   @tab X
 @item TED Talks captions @tab @tab X @tab   @tab X
+@item TTML @tab X @tab   @tab X @tab
 @item VobSub (IDX+SUB) @tab   @tab X @tab   @tab X
 @item VPlayer  @tab   @tab X @tab   @tab X
 @item WebVTT   @tab X @tab X @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 35318f4f4d..34d3d4bb0a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -666,6 +666,7 @@ OBJS-$(CONFIG_TSCC_DECODER)+= tscc.o msrledec.o
 OBJS-$(CONFIG_TSCC2_DECODER)   += tscc2.o
 OBJS-$(CONFIG_TTA_DECODER) += tta.o ttadata.o ttadsp.o
 OBJS-$(CONFIG_TTA_ENCODER) += ttaenc.o ttaencdsp.o ttadata.o
+OBJS-$(CONFIG_TTML_ENCODER)+= ttmlenc.o ass_split.o
 OBJS-$(CONFIG_TWINVQ_DECODER)  += twinvqdec.o twinvq.o metasound_data.o
 OBJS-$(CONFIG_TXD_DECODER) += txd.o
 OBJS-$(CONFIG_ULTI_DECODER)+= ulti.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f00d524747..81d20c44ec 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -686,6 +686,7 @@ extern AVCodec ff_subviewer_decoder;
 extern AVCodec ff_subviewer1_decoder;
 extern AVCodec ff_text_encoder;
 extern AVCodec ff_text_decoder;
+extern AVCodec ff_ttml_encoder;
 extern AVCodec ff_vplayer_decoder;
 extern AVCodec ff_webvtt_encoder;
 extern AVCodec ff_webvtt_decoder;
diff --git a/libavcodec/ttmlenc.c b/libavcodec/ttmlenc.c
new file mode 100644
index 00..8c8e503c5f
--- /dev/null
+++ b/libavcodec/ttmlenc.c
@@ -0,0 +1,178 @@
+/*
+ * TTML subtitle encoder
+ * Copyright (c) 2020 24i
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * TTML subtitle encoder
+ * @see https://www.w3.org/TR/ttml1/
+ * @see https://www.w3.org/TR/ttml2/
+ * @see https://www.w3.org/TR/ttml-imsc/rec
+ */
+
+#include "avcodec.h"
+#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
+#include "ass_split.h"
+#include "ass.h"
+
+typedef struct {
+AVCodecContext *avctx;
+ASSSplitContext *ass_ctx;
+AVBPrint buffer;
+} TTMLContext;
+
+static void ttml_text_cb(void *priv, const char *text, int len)
+{
+TTMLContext *s = priv;
+AVBPrint cur_line = { 0 };
+AVBPrint *buffer = &s->buffer;
+
+av_bprint_init(&cur_line, len, AV_BPRINT_SIZE_UNLIMITED);
+
+av_bprint_append_data(&cur_line, text, len);
+if (!av_bprint_is_complete(&cur_line)) {
+av_log(s->avctx, AV_LOG_ERROR,
+   "Failed to move the current subtitle dialog to AVBPrint!\n");
+av_bprint_finalize(&cur_line, NULL);
+return;
+}
+
+
+av_bprint_escape(buffer, cur_line.str, NULL, AV_ESCAPE_MODE_XML, 0);
+
+av_bprint_finalize(&cur_line, NULL);
+}
+
+static void ttml_new_line_cb(void *priv, int forced)
+{
+TTMLContext *s 

[FFmpeg-devel] [PATCH v3 00/11] add vvc raw demuxer, muxer, parser, metadata bsf

2021-01-11 Thread Nuo Mi
Changes since v2:
Set resolution and format in vvc_parser. It makes metadata bsf working without 
vvdec decoder.
Metadata passthrough test gets 100% syntax match with  vtm 11 conformance clips
Change VVC_MAX_TILE_ROWS to 22, print error if it's larger than this.
Remove unused vps and sei types.
Move zero bytes append check to a stand-alone function
Change VVC_MAX_DPB_SIZE + 13 to  VVC_MAX_REF_ENTRIES
Change vvc_metadata_bsf.c to h266_metadata_bsf.c


Nuo Mi (11):
  avcodec/vvc: add shared header for vvc
  avcodec: add vvc codec id and profiles
  avformat: add vvc raw demux
  avcodec: add SEI enum for vvc
  avcodec/cbs_h265: fix undef SEI_TYPE_X
  avcodec/cbs_h2645: reface, move zero bytes check to a function
  avcodec: add cbs for h266/vvc
  avcodec/h2645_parse: add nal header parser for h266/vvc
  avcodec: add vvc parser
  avformat: add h266/vvc muxer
  avcodec: add vvc metadata bsf

 configure |4 +
 libavcodec/Makefile   |3 +
 libavcodec/avcodec.h  |2 +
 libavcodec/bitstream_filters.c|1 +
 libavcodec/cbs.c  |6 +
 libavcodec/cbs_h2645.c|  397 +++-
 libavcodec/cbs_h265_syntax_template.c |4 +-
 libavcodec/cbs_h266.h |  758 +++
 libavcodec/cbs_h266_syntax_template.c | 2774 +
 libavcodec/cbs_internal.h |3 +-
 libavcodec/codec_desc.c   |8 +
 libavcodec/codec_id.h |2 +
 libavcodec/h2645_parse.c  |   74 +-
 libavcodec/h266_metadata_bsf.c|  243 +++
 libavcodec/parsers.c  |1 +
 libavcodec/profiles.c |5 +
 libavcodec/profiles.h |1 +
 libavcodec/vvc.h  |  130 ++
 libavcodec/vvc_parser.c   |  299 +++
 libavcodec/vvc_sei.h  |   47 +
 libavformat/Makefile  |2 +
 libavformat/allformats.c  |2 +
 libavformat/rawenc.c  |   25 +
 libavformat/vvcdec.c  |   61 +
 24 files changed, 4839 insertions(+), 13 deletions(-)
 create mode 100644 libavcodec/cbs_h266.h
 create mode 100644 libavcodec/cbs_h266_syntax_template.c
 create mode 100644 libavcodec/h266_metadata_bsf.c
 create mode 100644 libavcodec/vvc.h
 create mode 100644 libavcodec/vvc_parser.c
 create mode 100644 libavcodec/vvc_sei.h
 create mode 100644 libavformat/vvcdec.c

-- 
2.25.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 v3 06/11] avcodec/cbs_h2645: reface, move zero bytes check to a function

2021-01-11 Thread Nuo Mi
---
 libavcodec/cbs_h2645.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 434322492c..5d7ae95931 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1207,6 +1207,20 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext 
*ctx,
 return 0;
 }
 
+//defined in B.2.2 zero_byte section
+static int cbs_h2645_unit_requires_zero_byte(enum AVCodecID codec_id,
+ CodedBitstreamUnitType type,
+ int i)
+{
+if (i == 0)
+return 1; /* (Assume this is the start of an access unit.) */
+if (codec_id == AV_CODEC_ID_H264)
+return type == H264_NAL_SPS || type == H264_NAL_PPS;
+if (codec_id == AV_CODEC_ID_HEVC)
+return type == HEVC_NAL_VPS || type == HEVC_NAL_SPS || type == 
HEVC_NAL_PPS;
+return 0;
+}
+
 static int cbs_h2645_assemble_fragment(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag)
 {
@@ -1241,14 +1255,7 @@ static int 
cbs_h2645_assemble_fragment(CodedBitstreamContext *ctx,
 frag->data_bit_padding = unit->data_bit_padding;
 }
 
-if ((ctx->codec->codec_id == AV_CODEC_ID_H264 &&
- (unit->type == H264_NAL_SPS ||
-  unit->type == H264_NAL_PPS)) ||
-(ctx->codec->codec_id == AV_CODEC_ID_HEVC &&
- (unit->type == HEVC_NAL_VPS ||
-  unit->type == HEVC_NAL_SPS ||
-  unit->type == HEVC_NAL_PPS)) ||
-i == 0 /* (Assume this is the start of an access unit.) */) {
+if (cbs_h2645_unit_requires_zero_byte(ctx->codec->codec_id, 
unit->type, i)) {
 // zero_byte
 data[dp++] = 0;
 }
-- 
2.25.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 v3 08/11] avcodec/h2645_parse: add nal header parser for h266/vvc

2021-01-11 Thread Nuo Mi
---
 libavcodec/h2645_parse.c | 74 ++--
 1 file changed, 71 insertions(+), 3 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index a36ef4f5a0..35f9d035a9 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -1,5 +1,5 @@
 /*
- * H.264/HEVC common parsing code
+ * H.264/HEVC/VVC common parsing code
  *
  * This file is part of FFmpeg.
  *
@@ -27,6 +27,7 @@
 #include "libavutil/mem.h"
 
 #include "bytestream.h"
+#include "vvc.h"
 #include "hevc.h"
 #include "h264.h"
 #include "h2645_parse.h"
@@ -146,6 +147,47 @@ nsc:
 return si;
 }
 
+static const char *const vvc_nal_type_name[32] = {
+"TRAIL_NUT", // VVC_TRAIL_NUT
+"STSA_NUT", // VVC_STSA_NUT
+"RADL_NUT", // VVC_RADL_NUT
+"RASL_NUT", // VVC_RASL_NUT
+"RSV_VCL_4", // VVC_RSV_VCL_4
+"RSV_VCL_5", // VVC_RSV_VCL_5
+"RSV_VCL_6", // VVC_RSV_VCL_6
+"IDR_W_RADL", // VVC_IDR_W_RADL
+"IDR_N_LP", // VVC_IDR_N_LP
+"CRA_NUT", // VVC_CRA_NUT
+"GDR_NUT", // VVC_GDR_NUT
+"RSV_IRAP_11", // VVC_RSV_IRAP_11
+"OPI_NUT", // VVC_OPI_NUT
+"DCI_NUT", // VVC_DCI_NUT
+"VPS_NUT", // VVC_VPS_NUT
+"SPS_NUT", // VVC_SPS_NUT
+"PPS_NUT", // VVC_PPS_NUT
+"PREFIX_APS_NUT",// VVC_PREFIX_APS_NUT
+"SUFFIX_APS_NUT",// VVC_SUFFIX_APS_NUT
+"PH_NUT", // VVC_PH_NUT
+"AUD_NUT", // VVC_AUD_NUT
+"EOS_NUT", // VVC_EOS_NUT
+"EOB_NUT", // VVC_EOB_NUT
+"PREFIX_SEI_NUT",// VVC_PREFIX_SEI_NUT
+"SUFFIX_SEI_NUT",// VVC_SUFFIX_SEI_NUT
+"FD_NUT", // VVC_FD_NUT
+"RSV_NVCL_26", // VVC_RSV_NVCL_26
+"RSV_NVCL_27", // VVC_RSV_NVCL_27
+"UNSPEC_28", // VVC_UNSPEC_28
+"UNSPEC_29", // VVC_UNSPEC_29
+"UNSPEC_30", // VVC_UNSPEC_30
+"UNSPEC_31", // VVC_UNSPEC_31
+};
+
+static const char *vvc_nal_unit_name(int nal_type)
+{
+av_assert0(nal_type >= 0 && nal_type < 32);
+return vvc_nal_type_name[nal_type];
+}
+
 static const char *const hevc_nal_type_name[64] = {
 "TRAIL_N", // HEVC_NAL_TRAIL_N
 "TRAIL_R", // HEVC_NAL_TRAIL_R
@@ -289,6 +331,31 @@ static int get_bit_length(H2645NAL *nal, int 
skip_trailing_zeros)
  * @return AVERROR_INVALIDDATA if the packet is not a valid NAL unit,
  * 0 otherwise
  */
+static int vvc_parse_nal_header(H2645NAL *nal, void *logctx)
+{
+GetBitContext *gb = &nal->gb;
+
+if (get_bits1(gb) != 0) //forbidden_zero_bit
+return AVERROR_INVALIDDATA;
+
+skip_bits1(gb); //nuh_reserved_zero_bit
+
+nal->nuh_layer_id = get_bits(gb, 6);
+nal->type = get_bits(gb, 5);
+nal->temporal_id = get_bits(gb, 3) - 1;
+if (nal->temporal_id < 0)
+return AVERROR_INVALIDDATA;
+
+if ((nal->type >= VVC_IDR_W_RADL && nal->type <= VVC_RSV_IRAP_11) && 
nal->temporal_id)
+return AVERROR_INVALIDDATA;
+
+av_log(logctx, AV_LOG_DEBUG,
+  "nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
+   nal->type, vvc_nal_unit_name(nal->type), nal->nuh_layer_id, 
nal->temporal_id);
+
+return 0;
+}
+
 static int hevc_parse_nal_header(H2645NAL *nal, void *logctx)
 {
 GetBitContext *gb = &nal->gb;
@@ -503,8 +570,9 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 
 /* Reset type in case it contains a stale value from a previously 
parsed NAL */
 nal->type = 0;
-
-if (codec_id == AV_CODEC_ID_HEVC)
+if (codec_id == AV_CODEC_ID_VVC)
+ret = vvc_parse_nal_header(nal, logctx);
+else if (codec_id == AV_CODEC_ID_HEVC)
 ret = hevc_parse_nal_header(nal, logctx);
 else
 ret = h264_parse_nal_header(nal, logctx);
-- 
2.25.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 v3 09/11] avcodec: add vvc parser

2021-01-11 Thread Nuo Mi
---
 configure   |   1 +
 libavcodec/Makefile |   1 +
 libavcodec/parsers.c|   1 +
 libavcodec/vvc_parser.c | 299 
 4 files changed, 302 insertions(+)
 create mode 100644 libavcodec/vvc_parser.c

diff --git a/configure b/configure
index 4935625260..5ff743d9c2 100755
--- a/configure
+++ b/configure
@@ -3167,6 +3167,7 @@ mpegaudio_parser_select="mpegaudioheader"
 mpegvideo_parser_select="mpegvideo"
 mpeg4video_parser_select="h263dsp mpegvideo qpeldsp"
 vc1_parser_select="vc1dsp"
+vcc_parser_select="cbs_h266"
 
 # bitstream_filters
 aac_adtstoasc_bsf_select="adts_header"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 4b406adfce..30e9a92e9f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1123,6 +1123,7 @@ OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o 
vc1.o vc1data.o  \
 OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
 OBJS-$(CONFIG_VP8_PARSER)  += vp8_parser.o
 OBJS-$(CONFIG_VP9_PARSER)  += vp9_parser.o
+OBJS-$(CONFIG_VVC_PARSER)  += vvc_parser.o
 OBJS-$(CONFIG_WEBP_PARSER) += webp_parser.o
 OBJS-$(CONFIG_XMA_PARSER)  += xma_parser.o
 
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index 83271d95a3..060c0931b6 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -70,6 +70,7 @@ extern AVCodecParser ff_vorbis_parser;
 extern AVCodecParser ff_vp3_parser;
 extern AVCodecParser ff_vp8_parser;
 extern AVCodecParser ff_vp9_parser;
+extern AVCodecParser ff_vvc_parser;
 extern AVCodecParser ff_webp_parser;
 extern AVCodecParser ff_xma_parser;
 
diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
new file mode 100644
index 00..9435977eb0
--- /dev/null
+++ b/libavcodec/vvc_parser.c
@@ -0,0 +1,299 @@
+/*
+ * VVC parser
+ *
+ * Copyright (C) 2029 Nuo Mi 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "cbs.h"
+#include "cbs_h266.h"
+#include "internal.h"
+#include "parser.h"
+
+#define START_CODE 0x01 ///< start_code_prefix_one_3bytes
+
+#define IS_SLICE(nut) (nut <= VVC_RASL_NUT || (nut >= VVC_IDR_W_RADL && nut <= 
VVC_GDR_NUT))
+
+typedef struct VVCParserContext {
+ParseContext pc;
+CodedBitstreamContext *cbc;
+CodedBitstreamFragment picture_unit;
+int parsed_extradata;
+} VVCParserContext;
+
+static const enum AVPixelFormat pix_fmts_8bit[] = {
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P
+};
+
+static const enum AVPixelFormat pix_fmts_10bit[] = {
+AV_PIX_FMT_GRAY10, AV_PIX_FMT_YUV420P10,
+AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10
+};
+
+static int get_format(const H266RawSPS* sps)
+{
+switch (sps->sps_bitdepth_minus8) {
+case 0:
+return pix_fmts_8bit[sps->sps_chroma_format_idc];
+case 2:
+return pix_fmts_10bit[sps->sps_chroma_format_idc];
+}
+return AV_PIX_FMT_NONE;
+}
+
+/**
+ * Find the end of the current frame in the bitstream.
+ * @return the position of the first byte of the next frame, or END_NOT_FOUND
+ */
+static int find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
+   int buf_size)
+{
+VVCParserContext *ctx = s->priv_data;
+ParseContext   *pc = &ctx->pc;
+int i;
+
+for (i = 0; i < buf_size; i++) {
+int nut;
+
+pc->state64 = (pc->state64 << 8) | buf[i];
+
+if (((pc->state64 >> 3 * 8) & 0xFF) != START_CODE)
+continue;
+
+nut = (pc->state64 >> (8 + 3)) & 0x1F;
+// Beginning of access unit
+if ((nut >= VVC_OPI_NUT && nut <= VVC_EOB_NUT && nut != VVC_PH_NUT) ||
+nut == VVC_PREFIX_SEI_NUT ||
+(nut >= VVC_RSV_NVCL_26 && nut <= VVC_UNSPEC_31)) {
+if (pc->frame_start_found) {
+pc->frame_start_found = 0;
+return i - 5;
+}
+} else if (nut == VVC_PH_NUT  || IS_SLICE(nut)) {
+int sh_picture_header_in_slice_header_flag = buf[i] >> 7;
+
+if (nut == VVC_PH_NUT || sh_picture_header_in_slice_header_flag) {
+if (!pc->frame_start_found) {
+pc->frame_start_found = 1;
+} else { // First slice of nex

[FFmpeg-devel] [PATCH v3 10/11] avformat: add h266/vvc muxer

2021-01-11 Thread Nuo Mi
---
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/rawenc.c | 25 +
 3 files changed, 27 insertions(+)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 4a5406da38..0253aa7d5a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -564,6 +564,7 @@ OBJS-$(CONFIG_VPK_DEMUXER)   += vpk.o
 OBJS-$(CONFIG_VPLAYER_DEMUXER)   += vplayerdec.o subtitles.o
 OBJS-$(CONFIG_VQF_DEMUXER)   += vqf.o
 OBJS-$(CONFIG_VVC_DEMUXER)   += vvcdec.o rawdec.o
+OBJS-$(CONFIG_VVC_MUXER) += rawenc.o
 OBJS-$(CONFIG_W64_DEMUXER)   += wavdec.o w64.o pcm.o
 OBJS-$(CONFIG_W64_MUXER) += wavenc.o w64.o
 OBJS-$(CONFIG_WAV_DEMUXER)   += wavdec.o pcm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index fdbf424e31..ae9a98a18e 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -463,6 +463,7 @@ extern AVInputFormat  ff_vpk_demuxer;
 extern AVInputFormat  ff_vplayer_demuxer;
 extern AVInputFormat  ff_vqf_demuxer;
 extern AVInputFormat  ff_vvc_demuxer;
+extern AVOutputFormat ff_vvc_muxer;
 extern AVInputFormat  ff_w64_demuxer;
 extern AVOutputFormat ff_w64_muxer;
 extern AVInputFormat  ff_wav_demuxer;
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 32704f9bfd..5eb95f069c 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -372,6 +372,31 @@ AVOutputFormat ff_hevc_muxer = {
 };
 #endif
 
+#if CONFIG_VVC_MUXER
+static int vvc_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt)
+{
+if (pkt->size >= 5 && AV_RB32(pkt->data) != 0x001 &&
+  AV_RB24(pkt->data) != 0x01) {
+//TODO: fixed this after vvc codec defined in http://mp4ra.org/#/codecs
+av_log(s, AV_LOG_ERROR, "vvc: mp4 to annexb is not supported\n");
+return AVERROR_PATCHWELCOME;
+}
+return 1;
+}
+
+AVOutputFormat ff_vvc_muxer = {
+.name  = "vvc",
+.long_name = NULL_IF_CONFIG_SMALL("raw VVC video"),
+.extensions= "hevc,h266,266",
+.audio_codec   = AV_CODEC_ID_NONE,
+.video_codec   = AV_CODEC_ID_VVC,
+.write_header  = force_one_stream,
+.write_packet  = ff_raw_write_packet,
+.check_bitstream   = vvc_check_bitstream,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
 #if CONFIG_M4V_MUXER
 AVOutputFormat ff_m4v_muxer = {
 .name  = "m4v",
-- 
2.25.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 v3 11/11] avcodec: add vvc metadata bsf

2021-01-11 Thread Nuo Mi
use following command to test:
ffmpeg -i in.bin  -c:v copy -bsf vvc_metadata -f vvc out.bin

93.17%(232/249) can bit match with original clips
6.83%(17/249) are not bit match, the original clips has redundant emulation 
prevent bytes
---
 configure  |   1 +
 libavcodec/Makefile|   1 +
 libavcodec/bitstream_filters.c |   1 +
 libavcodec/h266_metadata_bsf.c | 243 +
 4 files changed, 246 insertions(+)
 create mode 100644 libavcodec/h266_metadata_bsf.c

diff --git a/configure b/configure
index 5ff743d9c2..b41f2af151 100755
--- a/configure
+++ b/configure
@@ -3184,6 +3184,7 @@ mjpeg2jpeg_bsf_select="jpegtables"
 mpeg2_metadata_bsf_select="cbs_mpeg2"
 trace_headers_bsf_select="cbs"
 vp9_metadata_bsf_select="cbs_vp9"
+vvc_metadata_bsf_select="cbs_h266"
 
 # external libraries
 aac_at_decoder_deps="audiotoolbox"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 30e9a92e9f..57554b5886 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1166,6 +1166,7 @@ OBJS-$(CONFIG_VP9_METADATA_BSF)   += 
vp9_metadata_bsf.o
 OBJS-$(CONFIG_VP9_RAW_REORDER_BSF)+= vp9_raw_reorder_bsf.o
 OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
 OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += vp9_superframe_split_bsf.o
+OBJS-$(CONFIG_VVC_METADATA_BSF)   += h266_metadata_bsf.o
 
 # thread libraries
 OBJS-$(HAVE_LIBC_MSVCRT)   += file_open.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index b26d6a910e..001a7bb3a4 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -60,6 +60,7 @@ extern const AVBitStreamFilter ff_vp9_metadata_bsf;
 extern const AVBitStreamFilter ff_vp9_raw_reorder_bsf;
 extern const AVBitStreamFilter ff_vp9_superframe_bsf;
 extern const AVBitStreamFilter ff_vp9_superframe_split_bsf;
+extern const AVBitStreamFilter ff_vvc_metadata_bsf;
 
 #include "libavcodec/bsf_list.c"
 
diff --git a/libavcodec/h266_metadata_bsf.c b/libavcodec/h266_metadata_bsf.c
new file mode 100644
index 00..c3e7a0ad53
--- /dev/null
+++ b/libavcodec/h266_metadata_bsf.c
@@ -0,0 +1,243 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "cbs.h"
+#include "cbs_h266.h"
+#include "vvc.h"
+
+enum {
+PASS,
+INSERT,
+REMOVE,
+};
+
+typedef struct VVCMetadataContext {
+const AVClass *class;
+
+CodedBitstreamContext *input;
+CodedBitstreamContext *output;
+CodedBitstreamFragment access_unit;
+
+H266RawAUD aud_nal;
+
+int aud;
+
+} VVCMetadataContext;
+
+static int vvc_metadata_update_side_data(AVBSFContext *bsf, AVPacket *pkt)
+{
+VVCMetadataContext *ctx = bsf->priv_data;
+CodedBitstreamFragment *au = &ctx->access_unit;
+uint8_t *side_data;
+int side_data_size;
+int err;
+
+side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+&side_data_size);
+if (!side_data_size)
+return 0;
+
+err = ff_cbs_read(ctx->input, au, side_data, side_data_size);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to read extradata from packet side 
data.\n");
+return err;
+}
+
+err = ff_cbs_write_fragment_data(ctx->output, au);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to write extradata into packet side 
data.\n");
+return err;
+}
+
+side_data = av_packet_new_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA, 
au->data_size);
+if (!side_data)
+return AVERROR(ENOMEM);
+memcpy(side_data, au->data, au->data_size);
+
+ff_cbs_fragment_reset(au);
+
+return 0;
+}
+
+static int vvc_metadata_filter(AVBSFContext *bsf, AVPacket *pkt)
+{
+VVCMetadataContext *ctx = bsf->priv_data;
+CodedBitstreamFragment *au = &ctx->access_unit;
+int err, i;
+
+err = ff_bsf_get_packet_ref(bsf, pkt);
+if (err < 0)
+return err;
+
+err = vvc_metadata_update_side_data(bsf, pkt);
+if (err < 0)
+goto fail;
+
+err = ff_cbs_read_packet(ctx->input, au, pkt);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n

[FFmpeg-devel] [PATCH v3 05/11] avcodec/cbs_h265: fix undef SEI_TYPE_X

2021-01-11 Thread Nuo Mi
---
 libavcodec/cbs_h265_syntax_template.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 48fae82d04..c0e94683a2 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -2197,7 +2197,9 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
  1, 0, 
alternative_transfer_characteristics);
 SEI_TYPE_N(ALPHA_CHANNEL_INFO,   1, 0, alpha_channel_info);
 
-#undef SEI_TYPE
+#undef SEI_TYPE_N
+#undef SEI_TYPE_S
+#undef SEI_TYPE_E
 default:
 {
 #ifdef READ
-- 
2.25.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 v3 04/11] avcodec: add SEI enum for vvc

2021-01-11 Thread Nuo Mi
---
 libavcodec/vvc_sei.h | 47 
 1 file changed, 47 insertions(+)
 create mode 100644 libavcodec/vvc_sei.h

diff --git a/libavcodec/vvc_sei.h b/libavcodec/vvc_sei.h
new file mode 100644
index 00..90724669de
--- /dev/null
+++ b/libavcodec/vvc_sei.h
@@ -0,0 +1,47 @@
+/*
+ * H.266/VVC Supplementary Enhancement Information messages
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_VVC_SEI_H
+#define AVCODEC_VVC_SEI_H
+
+/**
+ * SEI message types
+ */
+typedef enum {
+VVC_SEI_TYPE_BUFFERING_PERIOD = 0,
+VVC_SEI_TYPE_PICTURE_TIMING   = 1,
+VVC_SEI_TYPE_PAN_SCAN_RECT= 2,
+VVC_SEI_TYPE_FILLER_PAYLOAD   = 3,
+VVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35   = 4,
+VVC_SEI_TYPE_USER_DATA_UNREGISTERED   = 5,
+VVC_SEI_TYPE_FILM_GRAIN_CHARACTERISTICS   = 19,
+VVC_SEI_TYPE_FRAME_PACKING= 45,
+VVC_SEI_TYPE_PARAMETER_SETS_INCLUSION_INDICATION  = 129,
+VVC_SEI_TYPE_DECODING_UNIT_INFO   = 130,
+VVC_SEI_TYPE_DECODED_PICTURE_HASH = 132,
+VVC_SEI_TYPE_SCALABLE_NESTING = 133,
+VVC_SEI_TYPE_REGION_REFRESH_INFO  = 134,
+VVC_SEI_TYPE_TIME_CODE= 136,
+VVC_SEI_TYPE_MASTERING_DISPLAY_INFO   = 137,
+VVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144,
+VVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS = 147,
+} VVC_SEI_Type;
+
+#endif /* AVCODEC_VVC_SEI_H */
-- 
2.25.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] Moves yuv2yuvX_sse3 to yasm, unrolls main loop and other small optimizations for ~20% speedup.

2021-01-11 Thread Alan Kelly
---
 Fixes a bug where if there is no offset and a tail which is not processed by 
the
 sse3/avx2 version the dither is modified
 Deletes mmx/mmxext yuv2yuvX version from swscale_template and adds it
 to yuv2yuvX.asm to reduce code duplication and so that it may be used
 to process the tail from the larger cardinal simd versions.
 src argument of yuv2yuvX_* is now srcOffset, so that tails and offsets
 are accounted for correctly.
 Changes input size in checkasm so that this corner case is tested.

 libswscale/x86/Makefile   |   1 +
 libswscale/x86/swscale.c  | 130 
 libswscale/x86/swscale_template.c |  82 --
 libswscale/x86/yuv2yuvX.asm   | 136 ++
 tests/checkasm/sw_scale.c | 100 ++
 5 files changed, 291 insertions(+), 158 deletions(-)
 create mode 100644 libswscale/x86/yuv2yuvX.asm

diff --git a/libswscale/x86/Makefile b/libswscale/x86/Makefile
index 831d5359aa..bfe383364e 100644
--- a/libswscale/x86/Makefile
+++ b/libswscale/x86/Makefile
@@ -13,3 +13,4 @@ X86ASM-OBJS += x86/input.o
  \
x86/scale.o  \
x86/rgb_2_rgb.o  \
x86/yuv_2_rgb.o  \
+   x86/yuv2yuvX.o   \
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 15c0b22f20..3df193a067 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -63,6 +63,16 @@ DECLARE_ASM_ALIGNED(8, const uint64_t, ff_bgr2UVOffset) = 
0x8080808080808080ULL;
 DECLARE_ASM_ALIGNED(8, const uint64_t, ff_w)= 
0x0001000100010001ULL;
 
 
+#define YUV2YUVX_FUNC_DECL(opt)  \
+static void yuv2yuvX_ ##opt(const int16_t *filter, int filterSize, const 
int16_t **src, \
+   uint8_t *dest, int dstW, \
+   const uint8_t *dither, int offset); \
+
+YUV2YUVX_FUNC_DECL(mmx)
+YUV2YUVX_FUNC_DECL(mmxext)
+YUV2YUVX_FUNC_DECL(sse3)
+YUV2YUVX_FUNC_DECL(avx2)
+
 //MMX versions
 #if HAVE_MMX_INLINE
 #undef RENAME
@@ -198,81 +208,44 @@ void ff_updateMMXDitherTables(SwsContext *c, int dstY)
 }
 
 #if HAVE_MMXEXT
-static void yuv2yuvX_sse3(const int16_t *filter, int filterSize,
-   const int16_t **src, uint8_t *dest, int dstW,
-   const uint8_t *dither, int offset)
-{
-if(((uintptr_t)dest) & 15){
-yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither, offset);
-return;
-}
-filterSize--;
-#define MAIN_FUNCTION \
-"pxor   %%xmm0, %%xmm0 \n\t" \
-"punpcklbw  %%xmm0, %%xmm3 \n\t" \
-"movd   %4, %%xmm1 \n\t" \
-"punpcklwd  %%xmm1, %%xmm1 \n\t" \
-"punpckldq  %%xmm1, %%xmm1 \n\t" \
-"punpcklqdq %%xmm1, %%xmm1 \n\t" \
-"psllw  $3, %%xmm1 \n\t" \
-"paddw  %%xmm1, %%xmm3 \n\t" \
-"psraw  $4, %%xmm3 \n\t" \
-"movdqa %%xmm3, %%xmm4 \n\t" \
-"movdqa %%xmm3, %%xmm7 \n\t" \
-"movl   %3, %%ecx  \n\t" \
-"mov %0, %%"FF_REG_d"\n\t"\
-"mov(%%"FF_REG_d"), %%"FF_REG_S" \n\t"\
-".p2align 4 \n\t" /* FIXME 
Unroll? */\
-"1: \n\t"\
-"movddup  8(%%"FF_REG_d"), %%xmm0   \n\t" /* 
filterCoeff */\
-"movdqa  (%%"FF_REG_S", %%"FF_REG_c", 2), %%xmm2 \n\t" /* 
srcData */\
-"movdqa16(%%"FF_REG_S", %%"FF_REG_c", 2), %%xmm5 \n\t" /* 
srcData */\
-"add$16, %%"FF_REG_d"\n\t"\
-"mov(%%"FF_REG_d"), %%"FF_REG_S" \n\t"\
-"test %%"FF_REG_S", %%"FF_REG_S" \n\t"\
-"pmulhw   %%xmm0, %%xmm2  \n\t"\
-"pmulhw   %%xmm0, %%xmm5  \n\t"\
-"paddw%%xmm2, %%xmm3  \n\t"\
-"paddw%%xmm5, %%xmm4  \n\t"\
-" jnz1b \n\t"\
-"psraw   $3, %%xmm3  \n\t"\
-"psraw   $3, %%xmm4  \n\t"\
-"packuswb %%xmm4, %%xmm3  \n\t"\
-"movntdq  %%xmm3, (%1, %%"FF_REG_c") \n\t"\
-"add $16, %%"FF_REG_c"\n\t"\
-"cmp  %2, %%"FF_REG_c"\n\t"\
-"movdqa   %%xmm7, %%xmm3\n\t" \
-"movdqa   %%xmm7, %%xmm4\n\t" \
-"mov 

[FFmpeg-devel] [PATCH v3 03/11] avformat: add vvc raw demux

2021-01-11 Thread Nuo Mi
---
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/vvcdec.c | 61 
 3 files changed, 63 insertions(+)
 create mode 100644 libavformat/vvcdec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3a8fbcbe5f..4a5406da38 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -563,6 +563,7 @@ OBJS-$(CONFIG_VOC_MUXER) += vocenc.o voc.o
 OBJS-$(CONFIG_VPK_DEMUXER)   += vpk.o
 OBJS-$(CONFIG_VPLAYER_DEMUXER)   += vplayerdec.o subtitles.o
 OBJS-$(CONFIG_VQF_DEMUXER)   += vqf.o
+OBJS-$(CONFIG_VVC_DEMUXER)   += vvcdec.o rawdec.o
 OBJS-$(CONFIG_W64_DEMUXER)   += wavdec.o w64.o pcm.o
 OBJS-$(CONFIG_W64_MUXER) += wavenc.o w64.o
 OBJS-$(CONFIG_WAV_DEMUXER)   += wavdec.o pcm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0e0caaad39..fdbf424e31 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -462,6 +462,7 @@ extern AVOutputFormat ff_voc_muxer;
 extern AVInputFormat  ff_vpk_demuxer;
 extern AVInputFormat  ff_vplayer_demuxer;
 extern AVInputFormat  ff_vqf_demuxer;
+extern AVInputFormat  ff_vvc_demuxer;
 extern AVInputFormat  ff_w64_demuxer;
 extern AVOutputFormat ff_w64_muxer;
 extern AVInputFormat  ff_wav_demuxer;
diff --git a/libavformat/vvcdec.c b/libavformat/vvcdec.c
new file mode 100644
index 00..149f39f28e
--- /dev/null
+++ b/libavformat/vvcdec.c
@@ -0,0 +1,61 @@
+/*
+ * RAW VVC video demuxer
+ * Copyright (c) 2020 Nuo Mi 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavcodec/vvc.h"
+
+#include "avformat.h"
+#include "rawdec.h"
+
+static int vvc_probe(const AVProbeData *p)
+{
+uint32_t code = -1;
+int sps = 0, pps = 0, irap = 0;
+int i;
+
+for (i = 0; i < p->buf_size - 1; i++) {
+code = (code << 8) + p->buf[i];
+if ((code & 0xff00) == 0x100) {
+uint8_t nal2 = p->buf[i + 1];
+int type = (nal2 & 0xF8) >> 3;
+
+if (code & 0xc0) // forbidden_zero_bit and nuh_reserved_zero_bit
+return 0;
+
+if ((nal2 & 0x7) == 0) // nuh_temporal_id_plus1
+return 0;
+
+switch (type) {
+case VVC_SPS_NUT:   sps++;  break;
+case VVC_PPS_NUT:   pps++;  break;
+case VVC_IDR_N_LP:
+case VVC_IDR_W_RADL:
+case VVC_CRA_NUT:
+case VVC_GDR_NUT:   irap++; break;
+}
+}
+}
+
+if (sps && pps && irap)
+return AVPROBE_SCORE_EXTENSION + 1; // 1 more than .mpg
+return 0;
+}
+
+FF_DEF_RAWVIDEO_DEMUXER(vvc, "raw VVC video", vvc_probe, "h266,266,vvc", 
AV_CODEC_ID_VVC)
-- 
2.25.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 v3 01/11] avcodec/vvc: add shared header for vvc

2021-01-11 Thread Nuo Mi
---
 libavcodec/vvc.h | 130 +++
 1 file changed, 130 insertions(+)
 create mode 100644 libavcodec/vvc.h

diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
new file mode 100644
index 00..e25924b35d
--- /dev/null
+++ b/libavcodec/vvc.h
@@ -0,0 +1,130 @@
+/*
+ * VVC shared code
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_VVC_H
+#define AVCODEC_VVC_H
+
+/**
+ * Table 5 – NAL unit type codes and NAL unit type classes
+ * in T-REC-H.266-202008
+ */
+enum VVCNALUnitType {
+VVC_TRAIL_NUT  = 0,
+VVC_STSA_NUT   = 1,
+VVC_RADL_NUT   = 2,
+VVC_RASL_NUT   = 3,
+VVC_RSV_VCL_4  = 4,
+VVC_RSV_VCL_5  = 5,
+VVC_RSV_VCL_6  = 6,
+VVC_IDR_W_RADL = 7,
+VVC_IDR_N_LP   = 8,
+VVC_CRA_NUT= 9,
+VVC_GDR_NUT= 10,
+VVC_RSV_IRAP_11= 11,
+VVC_OPI_NUT= 12,
+VVC_DCI_NUT= 13,
+VVC_VPS_NUT= 14,
+VVC_SPS_NUT= 15,
+VVC_PPS_NUT= 16,
+VVC_PREFIX_APS_NUT = 17,
+VVC_SUFFIX_APS_NUT = 18,
+VVC_PH_NUT = 19,
+VVC_AUD_NUT= 20,
+VVC_EOS_NUT= 21,
+VVC_EOB_NUT= 22,
+VVC_PREFIX_SEI_NUT = 23,
+VVC_SUFFIX_SEI_NUT = 24,
+VVC_FD_NUT = 25,
+VVC_RSV_NVCL_26= 26,
+VVC_RSV_NVCL_27= 27,
+VVC_UNSPEC_28  = 28,
+VVC_UNSPEC_29  = 29,
+VVC_UNSPEC_30  = 30,
+VVC_UNSPEC_31  = 31,
+};
+
+enum VVCSliceType {
+VVC_SLICE_TYPE_B = 0,
+VVC_SLICE_TYPE_P = 1,
+VVC_SLICE_TYPE_I = 2,
+};
+
+enum {
+VVC_MAX_PLANES = 3,
+//7.4.3.3 The value of vps_max_sublayers_minus1 shall be in the range of 0 
to 6, inclusive
+VVC_MAX_SUBLAYERS = 7,
+
+// 7.3.2.3: vps_video_parameter_set_id is u(4).
+VVC_MAX_VPS_COUNT = 16,
+// 7.3.2.4: sps_seq_parameter_set_id is u(4)
+VVC_MAX_SPS_COUNT = 16,
+// 7.3.2.5: pps_pic_parameter_set_id is u(6)
+VVC_MAX_PPS_COUNT = 64,
+
+// 7.4.4.1: ptl_num_sub_profiles is u(8)
+VVC_MAX_SUB_PROFILES = 256,
+
+// A.4.2: according to (1577), MaxDpbSize is bounded above by 2 * 
maxDpbPicBuf(8)
+VVC_MAX_DPB_SIZE = 16,
+
+//7.4.3.4 sps_num_ref_pic_lists in range [0, 64]
+VVC_MAX_REF_PIC_LISTS = 64,
+
+//7.4.11 num_ref_entries in range [0, MaxDpbSize + 13]
+VVC_MAX_REF_ENTRIES = VVC_MAX_DPB_SIZE + 13,
+
+//7.4.3.3 sps_num_points_in_qp_table_minus1[i] in range [0, 36 − 
sps_qp_table_start_minus26[i]],
+//sps_qp_table_start_minus26[i] in range [sps_qp_table_start_minus26[i] 
−26 − QpBdOffset, 36]
+//for 10 bitsQpBdOffset is 12, so sps_num_points_in_qp_table_minus1[i] in 
range [0, 74]
+VVC_MAX_POINTS_IN_QP_TABLE = 75,
+
+// 7.4.6.1: hrd_cpb_cnt_minus1 is in [0, 31].
+VVC_MAX_CPB_CNT = 32,
+
+// A.4.1: the highest level allows a MaxLumaPs of 35 651 584.
+VVC_MAX_LUMA_PS = 35651584,
+// A.4.1: pic_width_in_luma_samples and pic_height_in_luma_samples are
+// constrained to be not greater than sqrt(MaxLumaPs * 8).  Hence height/
+// width are bounded above by sqrt(8 * 35651584) = 16888.2 samples.
+VVC_MAX_WIDTH  = 16888,
+VVC_MAX_HEIGHT = 16888,
+
+// A.4.1: table A.1 did not define max tile rows.
+// we just follow hevc spec, 22 should enough for a normal case.
+VVC_MAX_TILE_ROWS= 22,
+// A.4.1: table A.1 allows at most 20 tile columns for any level.
+VVC_MAX_TILE_COLUMNS = 20,
+// A.4.1: table A.1 allows at most 440 tiles per au for any level.
+VVC_MAX_TILES_PER_AU = 440,
+
+// A.4.1 table A.1 allows at most 600 slice for any level.
+VVC_MAX_SLICES = 600,
+
+// 7.4.8: in the worst case (tiles_enabled_flag and
+// entropy_coding_sync_enabled_flag are both set), entry points can be
+// placed at the beginning of every Ctb row in every tile, giving an
+// upper bound of (num_tile_columns_minus1 + 1) * PicHeightInCtbsY - 1.
+// Only a stream with very high resolution and perverse parameters could
+// get near that, though, so set a lower limit here with the maximum
+// possible value for 8K video (at most 135 32x32 Ctb rows).
+VVC_MAX_ENTRY_POINTS = VVC_MAX_TILE_COLUMNS * 135,
+};
+
+#endif /* AVCODEC_VVC_H */

[FFmpeg-devel] [PATCH v3 02/11] avcodec: add vvc codec id and profiles

2021-01-11 Thread Nuo Mi
---
 libavcodec/avcodec.h| 2 ++
 libavcodec/codec_desc.c | 8 
 libavcodec/codec_id.h   | 2 ++
 libavcodec/profiles.c   | 5 +
 libavcodec/profiles.h   | 1 +
 5 files changed, 18 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1d3099d50a..13a3191b53 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1961,6 +1961,8 @@ typedef struct AVCodecContext {
 #define FF_PROFILE_HEVC_MAIN_STILL_PICTURE  3
 #define FF_PROFILE_HEVC_REXT4
 
+#define FF_PROFILE_VVC_MAIN_10  1
+
 #define FF_PROFILE_AV1_MAIN 0
 #define FF_PROFILE_AV1_HIGH 1
 #define FF_PROFILE_AV1_PROFESSIONAL 2
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 14757bf31b..a7594f9004 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1426,6 +1426,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("Microsoft Paint (MSP) version 2"),
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_VVC,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "vvc",
+.long_name = NULL_IF_CONFIG_SMALL("H.266 / VVC (Versatile Video 
Coding)"),
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
+.profiles  = NULL_IF_CONFIG_SMALL(ff_vvc_profiles),
+},
 {
 .id= AV_CODEC_ID_Y41P,
 .type  = AVMEDIA_TYPE_VIDEO,
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 6133e03bb9..7a8a896bfe 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -244,6 +244,8 @@ enum AVCodecID {
 AV_CODEC_ID_PGX,
 AV_CODEC_ID_AVS3,
 AV_CODEC_ID_MSP2,
+AV_CODEC_ID_VVC,
+#define AV_CODEC_ID_H266 AV_CODEC_ID_VVC
 
 AV_CODEC_ID_Y41P = 0x8000,
 AV_CODEC_ID_AVRP,
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index e59a3a5c12..6dd6594319 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -74,6 +74,11 @@ const AVProfile ff_h264_profiles[] = {
 { FF_PROFILE_UNKNOWN },
 };
 
+const AVProfile ff_vvc_profiles[] = {
+{ FF_PROFILE_VVC_MAIN_10, "Main 10" },
+{ FF_PROFILE_UNKNOWN },
+};
+
 const AVProfile ff_hevc_profiles[] = {
 { FF_PROFILE_HEVC_MAIN, "Main"},
 { FF_PROFILE_HEVC_MAIN_10,  "Main 10" },
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index 6baaba5701..41a19aa9ad 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -61,6 +61,7 @@ extern const AVProfile ff_dca_profiles[];
 extern const AVProfile ff_dnxhd_profiles[];
 extern const AVProfile ff_h264_profiles[];
 extern const AVProfile ff_hevc_profiles[];
+extern const AVProfile ff_vvc_profiles[];
 extern const AVProfile ff_jpeg2000_profiles[];
 extern const AVProfile ff_mpeg2_video_profiles[];
 extern const AVProfile ff_mpeg4_video_profiles[];
-- 
2.25.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 0/1] avformat/dolby_e: Add a parser

2021-01-11 Thread Nicolas Gaullier
Note: my first intend here is, afterwards, to provide s377m support to the wav 
demuxer,
(the actual code leads to pts issues : I sent a workaround
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201215171324.99-1-nicolas.gaullier@cji.paris/
that was rejected, so this new work for a Dolby E parser is simply a follow up).
I have tested that this patch actually fixes PTS generation when demuxing s337m 
wav samples.

This is a first try, so, yes, I kown it is missing Changelog and version 
updates. I think the review
will take some time so this could be updated lastly.

This is a single patch, I think it is easier for review anyway, but I expect 
you will ask me to split it in several files like
- dolby_e_parser.c/.h
- dolby_edec.c/.h
Anyway, if so, I think I would keep this first patch as is and simply add a new 
patch to just split all the things.
Unless you think it is better to split the parser code from the very 
beginning/first patch.

So, I keep listening about how this work should be presented, in term of number 
of patches etc.

Thank you in advance for the review
Nicolas

Nicolas Gaullier (1):
  avformat/dolby_e: Add a parser

 libavcodec/dolby_e.c | 260 ---
 libavcodec/dolby_e.h |  38 ++-
 libavcodec/parsers.c |   1 +
 3 files changed, 202 insertions(+), 97 deletions(-)

-- 
2.27.0.windows.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 1/1] avformat/dolby_e: Add a parser

2021-01-11 Thread Nicolas Gaullier
---
 libavcodec/dolby_e.c | 260 ---
 libavcodec/dolby_e.h |  38 ++-
 libavcodec/parsers.c |   1 +
 3 files changed, 202 insertions(+), 97 deletions(-)

diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
index 2b2f0a1640..1fc502e730 100644
--- a/libavcodec/dolby_e.c
+++ b/libavcodec/dolby_e.c
@@ -26,13 +26,15 @@
 #include "internal.h"
 #include "get_bits.h"
 #include "put_bits.h"
+#include "parser.h"
 #include "dolby_e.h"
 #include "fft.h"
 
 static int skip_input(DBEContext *s, int nb_words)
 {
 if (nb_words > s->input_size) {
-av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -44,7 +46,7 @@ static int skip_input(DBEContext *s, int nb_words)
 static int parse_key(DBEContext *s)
 {
 if (s->key_present) {
-uint8_t *key = s->input;
+const uint8_t *key = s->input;
 int  ret = skip_input(s, 1);
 if (ret < 0)
 return ret;
@@ -55,7 +57,7 @@ static int parse_key(DBEContext *s)
 
 static int convert_input(DBEContext *s, int nb_words, int key)
 {
-uint8_t *src = s->input;
+const uint8_t *src = s->input;
 uint8_t *dst = s->buffer;
 PutBitContext pb;
 int i;
@@ -63,7 +65,8 @@ static int convert_input(DBEContext *s, int nb_words, int key)
 av_assert0(nb_words <= 1024u);
 
 if (nb_words > s->input_size) {
-av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -89,7 +92,7 @@ static int convert_input(DBEContext *s, int nb_words, int key)
 return init_get_bits(&s->gb, s->buffer, nb_words * s->word_bits);
 }
 
-static int parse_metadata(DBEContext *s)
+static int parse_metadata(DBEContext *s, DolbyEHeaderInfo *hdr)
 {
 int i, ret, key, mtd_size;
 
@@ -101,7 +104,8 @@ static int parse_metadata(DBEContext *s)
 skip_bits(&s->gb, 4);
 mtd_size = get_bits(&s->gb, 10);
 if (!mtd_size) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid metadata size\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Invalid metadata size\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -109,49 +113,53 @@ static int parse_metadata(DBEContext *s)
 return ret;
 
 skip_bits(&s->gb, 14);
-s->prog_conf = get_bits(&s->gb, 6);
-if (s->prog_conf > MAX_PROG_CONF) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid program configuration\n");
+hdr->prog_conf = get_bits(&s->gb, 6);
+if (hdr->prog_conf > MAX_PROG_CONF) {
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Invalid program configuration\n");
 return AVERROR_INVALIDDATA;
 }
 
-s->nb_channels = nb_channels_tab[s->prog_conf];
-s->nb_programs = nb_programs_tab[s->prog_conf];
+hdr->nb_channels = nb_channels_tab[hdr->prog_conf];
+hdr->nb_programs = nb_programs_tab[hdr->prog_conf];
 
-s->fr_code  = get_bits(&s->gb, 4);
-s->fr_code_orig = get_bits(&s->gb, 4);
-if (!sample_rate_tab[s->fr_code] ||
-!sample_rate_tab[s->fr_code_orig]) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid frame rate code\n");
+hdr->fr_code  = get_bits(&s->gb, 4);
+hdr->fr_code_orig = get_bits(&s->gb, 4);
+if (!sample_rate_tab[hdr->fr_code] ||
+!sample_rate_tab[hdr->fr_code_orig]) {
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Invalid frame rate code\n");
 return AVERROR_INVALIDDATA;
 }
 
 skip_bits_long(&s->gb, 88);
-for (i = 0; i < s->nb_channels; i++)
-s->ch_size[i] = get_bits(&s->gb, 10);
-s->mtd_ext_size = get_bits(&s->gb, 8);
-s->meter_size   = get_bits(&s->gb, 8);
-
-skip_bits_long(&s->gb, 10 * s->nb_programs);
-for (i = 0; i < s->nb_channels; i++) {
-s->rev_id[i] = get_bits(&s->gb,  4);
+for (i = 0; i < hdr->nb_channels; i++)
+hdr->ch_size[i] = get_bits(&s->gb, 10);
+hdr->mtd_ext_size = get_bits(&s->gb, 8);
+hdr->meter_size   = get_bits(&s->gb, 8);
+
+skip_bits_long(&s->gb, 10 * hdr->nb_programs);
+for (i = 0; i < hdr->nb_channels; i++) {
+hdr->rev_id[i] = get_bits(&s->gb,  4);
 skip_bits1(&s->gb);
-s->begin_gain[i] = get_bits(&s->gb, 10);
-s->end_gain[i]   = get_bits(&s->gb, 10);
+hdr->begin_gain[i] = get_bits(&s->gb, 10);
+hdr->end_gain[i]   = get_bits(&s->gb, 10);
 }
 
 if (get_bits_left(&s->gb) < 0) {
-av_log(s->avctx, AV_LOG_ERROR, "Read past end of metadata\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Read past end of metadata\n");
 return AVERROR_INVALIDDATA;
 }
 
 return skip_input(s, mtd_size + 1);
 }
 
-static int parse_metadata_ext(DBEContext *s)
+static int parse_metadata_ext(DBEDecodeContext *s1)
 {
-if 

Re: [FFmpeg-devel] [PATCH v3 02/11] avcodec: add vvc codec id and profiles

2021-01-11 Thread James Almer

On 1/11/2021 1:33 PM, Nuo Mi wrote:

---
  libavcodec/avcodec.h| 2 ++
  libavcodec/codec_desc.c | 8 
  libavcodec/codec_id.h   | 2 ++
  libavcodec/profiles.c   | 5 +
  libavcodec/profiles.h   | 1 +
  5 files changed, 18 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1d3099d50a..13a3191b53 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1961,6 +1961,8 @@ typedef struct AVCodecContext {
  #define FF_PROFILE_HEVC_MAIN_STILL_PICTURE  3
  #define FF_PROFILE_HEVC_REXT4
  
+#define FF_PROFILE_VVC_MAIN_10  1

+
  #define FF_PROFILE_AV1_MAIN 0
  #define FF_PROFILE_AV1_HIGH 1
  #define FF_PROFILE_AV1_PROFESSIONAL 2
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 14757bf31b..a7594f9004 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1426,6 +1426,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
  .long_name = NULL_IF_CONFIG_SMALL("Microsoft Paint (MSP) version 2"),
  .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
  },
+{
+.id= AV_CODEC_ID_VVC,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "vvc",
+.long_name = NULL_IF_CONFIG_SMALL("H.266 / VVC (Versatile Video 
Coding)"),
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
+.profiles  = NULL_IF_CONFIG_SMALL(ff_vvc_profiles),
+},
  {
  .id= AV_CODEC_ID_Y41P,
  .type  = AVMEDIA_TYPE_VIDEO,
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 6133e03bb9..7a8a896bfe 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -244,6 +244,8 @@ enum AVCodecID {
  AV_CODEC_ID_PGX,
  AV_CODEC_ID_AVS3,
  AV_CODEC_ID_MSP2,
+AV_CODEC_ID_VVC,
+#define AV_CODEC_ID_H266 AV_CODEC_ID_VVC
  
  AV_CODEC_ID_Y41P = 0x8000,

  AV_CODEC_ID_AVRP,
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index e59a3a5c12..6dd6594319 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -74,6 +74,11 @@ const AVProfile ff_h264_profiles[] = {
  { FF_PROFILE_UNKNOWN },
  };
  
+const AVProfile ff_vvc_profiles[] = {

+{ FF_PROFILE_VVC_MAIN_10, "Main 10" },


Added Main 10 4:4:4 as well, since some of the conformance samples used 
it, and applied.



+{ FF_PROFILE_UNKNOWN },
+};
+
  const AVProfile ff_hevc_profiles[] = {
  { FF_PROFILE_HEVC_MAIN, "Main"},
  { FF_PROFILE_HEVC_MAIN_10,  "Main 10" },
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index 6baaba5701..41a19aa9ad 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -61,6 +61,7 @@ extern const AVProfile ff_dca_profiles[];
  extern const AVProfile ff_dnxhd_profiles[];
  extern const AVProfile ff_h264_profiles[];
  extern const AVProfile ff_hevc_profiles[];
+extern const AVProfile ff_vvc_profiles[];
  extern const AVProfile ff_jpeg2000_profiles[];
  extern const AVProfile ff_mpeg2_video_profiles[];
  extern const AVProfile ff_mpeg4_video_profiles[];



___
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 05/11] avcodec/cbs_h265: fix undef SEI_TYPE_X

2021-01-11 Thread James Almer

On 1/11/2021 1:33 PM, Nuo Mi wrote:

---
  libavcodec/cbs_h265_syntax_template.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 48fae82d04..c0e94683a2 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -2197,7 +2197,9 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx, 
RWContext *rw,
   1, 0, 
alternative_transfer_characteristics);
  SEI_TYPE_N(ALPHA_CHANNEL_INFO,   1, 0, alpha_channel_info);
  
-#undef SEI_TYPE

+#undef SEI_TYPE_N
+#undef SEI_TYPE_S
+#undef SEI_TYPE_E
  default:
  {
  #ifdef READ


Applied.
___
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 06/11] avcodec: add cbs for h266/vvc

2021-01-11 Thread Mark Thompson

On 10/01/2021 09:10, Nuo Mi wrote:

On Sun, Jan 10, 2021 at 5:34 AM Mark Thompson  wrote:

On 09/01/2021 07:34, Nuo Mi wrote:

---
   configure |2 +
   libavcodec/Makefile   |1 +
   libavcodec/cbs.c  |6 +
   libavcodec/cbs_h2645.c|  373 
   libavcodec/cbs_h266.h |  840 
   libavcodec/cbs_h266_syntax_template.c | 2761 +
   libavcodec/cbs_internal.h |3 +-
   7 files changed, 3985 insertions(+), 1 deletion(-)
   create mode 100644 libavcodec/cbs_h266.h
   create mode 100644 libavcodec/cbs_h266_syntax_template.c

...
@@ -920,6 +934,135 @@ static int

cbs_h265_read_nal_unit(CodedBitstreamContext *ctx,

   return 0;
   }

+static int cbs_h266_replace_ph(CodedBitstreamContext *ctx,
+   CodedBitstreamUnit *unit)
+{
+CodedBitstreamH266Context *priv = ctx->priv_data;
+int err;
+err = ff_cbs_make_unit_refcounted(ctx, unit);
+if (err < 0)
+return err;
+av_buffer_unref(&priv->ph_ref);
+av_assert0(unit->content_ref);
+priv->ph_ref = av_buffer_ref(unit->content_ref);
+if (!priv->ph_ref)
+return AVERROR(ENOMEM);
+priv->active_ph = priv->ph = (H266RawPH *)priv->ph_ref->data;


Why are there too variables here?  They seem to always be the same.


   priv->active_ph is read-only, priv->ph is writeable pointer. I can change
to priv->ph only if you prefer.


Reading more carefully, H.266 doesn't appear to have the concept of a parameter set being 
"active" any more (the term never appears).

Does it actually follow the same rules as H.26[45]?  Is there some newer 
terminology which we should be using in all of this?


+return 0;
+}
+
...
diff --git a/libavcodec/cbs_h266_syntax_template.c

b/libavcodec/cbs_h266_syntax_template.c

new file mode 100644
index 00..6a6defc8a5
--- /dev/null
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -0,0 +1,2761 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA

02110-1301 USA

+ */
+
+#ifndef H266_CEIL
+#define H266_CEIL(v, a) (((v) + (a) - 1) / (a))
+#endif


If it's useful to have this separately then put it in cbs_h2645.c rather
than doubled in the template.  (See for example cbs_av1_tile_log2().)


It's protected by ifdef, not doubled.


It would still make more sense to make it a(n inline?) function in cbs_h2645.c. 
 The template file is intended to contain the standard template code and not 
other stuff.


+
...
+
+static int FUNC(vui_parameters)(CodedBitstreamContext *ctx, RWContext

*rw,

+H266RawVUI *current)
+{
+int err;
+
+flag(vui_progressive_source_flag);
+flag(vui_interlaced_source_flag);
+flag(vui_non_packed_constraint_flag);
+flag(vui_non_projected_constraint_flag);
+flag(vui_aspect_ratio_info_present_flag);
+if (current->vui_aspect_ratio_info_present_flag) {
+flag(vui_aspect_ratio_constant_flag);
+ub(8, vui_aspect_ratio_idc);
+if (current->vui_aspect_ratio_idc == 255) {
+ub(16, vui_sar_width);
+ub(16, vui_sar_height);
+}
+} else {
+infer(vui_aspect_ratio_constant_flag, 0);
+infer(vui_aspect_ratio_idc, 0);
+}
+flag(vui_overscan_info_present_flag);
+if (current->vui_overscan_info_present_flag)
+flag(vui_overscan_appropriate_flag);
+flag(vui_colour_description_present_flag);
+if (current->vui_colour_description_present_flag) {
+ub(8, vui_colour_primaries);
+ub(8, vui_transfer_characteristics);
+ub(8, vui_matrix_coeffs);
+flag(vui_full_range_flag);
+} else {
+infer(vui_colour_primaries, 2);
+infer(vui_transfer_characteristics, 2);
+infer(vui_matrix_coeffs, 2);
+infer(vui_full_range_flag, 0);
+}
+flag(vui_chroma_loc_info_present_flag);
+if (current->vui_chroma_loc_info_present_flag) {
+if (current->vui_progressive_source_flag &&
+!current->vui_interlaced_source_flag) {
+ue(vui_chroma_sample_loc_type_frame, 0, 6);
+} else {
+ue(vui_chroma_sample_loc_type_top_field, 0, 6);
+ue(vui_chroma_sample_loc_type_bottom_field,  0, 6);
+  

Re: [FFmpeg-devel] [PATCH] avformat/fifo: utilize a clone packet for muxing

2021-01-11 Thread Andreas Rheinhardt
Jan Ekström:
> On Tue, Dec 8, 2020 at 2:54 PM Jan Ekström  wrote:
>>
>> From: Jan Ekström 
>>
>> This way the timestamp adjustments do not have to be manually
>> undone in case of failure and need to recover/retry.
>>
>> Fixes an issue where the timestamp adjustment would be re-done over
>> and over again when recovery by muxing the same AVPacket again is
>> attempted. Would become visible if the fifo muxer's time base and
>> the output muxer's time base do not match (by the value either
>> becoming smaller and smaller, or larger and larger).
>>
>> Signed-off-by: Jan Ekström 
> 
> Ping.
> 
> Unless someone finds some disgruntling points in this patch, I will
> soon move towards applying this.
> 
> My initial plan was to make a simplified v2 where the output AVPacket
> was on stack limited to the fifo_thread_write_packet context, but
> apparently gradual removal of stack usage of AVPackets is being
> planned, so I decided to not to.
> 
> Best regards,
> Jan

Can't you just record (in FifoMessage) whether the timestamps have
already been converted to the desired timebase? (Or why not just copy
the timebase chosen by the internal muxer to the user-visible stream so
that we don't even have to convert it? This is how muxers always operate.)

- Andreas
___
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 06/11] avcodec/cbs_h2645: reface, move zero bytes check to a function

2021-01-11 Thread Mark Thompson

On 11/01/2021 16:33, Nuo Mi wrote:

---
  libavcodec/cbs_h2645.c | 23 +++
  1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 434322492c..5d7ae95931 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1207,6 +1207,20 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext 
*ctx,
  return 0;
  }
  
+//defined in B.2.2 zero_byte section

+static int cbs_h2645_unit_requires_zero_byte(enum AVCodecID codec_id,
+ CodedBitstreamUnitType type,
+ int i)
+{
+if (i == 0)
+return 1; /* (Assume this is the start of an access unit.) */
+if (codec_id == AV_CODEC_ID_H264)
+return type == H264_NAL_SPS || type == H264_NAL_PPS;
+if (codec_id == AV_CODEC_ID_HEVC)
+return type == HEVC_NAL_VPS || type == HEVC_NAL_SPS || type == 
HEVC_NAL_PPS;
+return 0;
+}
+
  static int cbs_h2645_assemble_fragment(CodedBitstreamContext *ctx,
 CodedBitstreamFragment *frag)
  {
@@ -1241,14 +1255,7 @@ static int 
cbs_h2645_assemble_fragment(CodedBitstreamContext *ctx,
  frag->data_bit_padding = unit->data_bit_padding;
  }
  
-if ((ctx->codec->codec_id == AV_CODEC_ID_H264 &&

- (unit->type == H264_NAL_SPS ||
-  unit->type == H264_NAL_PPS)) ||
-(ctx->codec->codec_id == AV_CODEC_ID_HEVC &&
- (unit->type == HEVC_NAL_VPS ||
-  unit->type == HEVC_NAL_SPS ||
-  unit->type == HEVC_NAL_PPS)) ||
-i == 0 /* (Assume this is the start of an access unit.) */) {
+if (cbs_h2645_unit_requires_zero_byte(ctx->codec->codec_id, 
unit->type, i)) {
  // zero_byte
  data[dp++] = 0;
  }



I clarified the comments (the section reference is not the same for H.264) and 
applied.

Thanks,

- Mark
___
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 01/11] avcodec/vvc: add shared header for vvc

2021-01-11 Thread Mark Thompson

On 10/01/2021 08:35, Nuo Mi wrote:

On Sun, Jan 10, 2021 at 9:39 AM Nuo Mi  wrote:

On Sun, Jan 10, 2021 at 3:09 AM Mark Thompson  wrote:

On 09/01/2021 07:34, Nuo Mi wrote:

---
   libavcodec/vvc.h | 124 +++
   1 file changed, 124 insertions(+)
   create mode 100644 libavcodec/vvc.h

diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
new file mode 100644
index 00..0bd2acac1d
--- /dev/null
+++ b/libavcodec/vvc.h
@@ -0,0 +1,124 @@
...
+
+// A.4.1: the highest level allows a MaxLumaPs of 35 651 584.
+VVC_MAX_LUMA_PS = 35651584,
+// A.4.1: pic_width_in_luma_samples and pic_height_in_luma_samples

are

+// constrained to be not greater than sqrt(MaxLumaPs * 8).  Hence

height/

+// width are bounded above by sqrt(8 * 35651584) = 16888.2 samples.
+VVC_MAX_WIDTH  = 16888,
+VVC_MAX_HEIGHT = 16888,
+
+// A.4.1: table A.1 allows at most 440 tiles for any au.
+VVC_MAX_TILE_ROWS= 440,


Is this bound really the best we can do?

That is, is it actually possible to construct a valid stream with 440
tile rows?  It must have a single tile column and a height of at least
14080 (for 440 rows of 32x32 CTUs), which feels extreme enough that it
might hit some of the other level constraints.


The  VVC_MAX_HEIGHT is 16888, it's higher than 14080.
If we limit the VVC_MAX_HEIGHT to 4k, we can reduce it to 135.

>
> How about we define it as 20,  check the size and return error if > 20.
> 20 should enough for most of clips. hevc used 20.

I'm specifically asking whether any of the other limits imply a better bound on 
the number of columns.  Can a 32x14080 stream (or something similar) with 440 
tiles ever be valid given all of the constraints?

440 is not large enough that it would matter in terms of space used, so if there 
isn't actually a better implied limit then leave it as 440.  (<1kB - constrast 
that with the entry points, which are already >10kB of almost-never-used space 
with the current limit.)


+// A.4.1: table A.1 allows at most 20 tile columns for any level.
+VVC_MAX_TILE_COLUMNS = 20,
+
+// A.4.1 table A.1 allows at most 600 slice for any level.
+VVC_MAX_SLICES = 600,
...


- Mark
___
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 5/8] uavformat/rsd: check for EOF in extradata

2021-01-11 Thread Michael Niedermayer
On Fri, Oct 23, 2020 at 08:39:37PM +0200, Michael Niedermayer wrote:
> Fixes: OOM
> Fixes: 
> 26503/clusterfuzz-testcase-minimized-ffmpeg_dem_RSD_fuzzer-6530816735444992
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/rsd.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply

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

Democracy is the form of government in which you can choose your dictator


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 6/8] avformat/aaxdec: Check string before strcmp()

2021-01-11 Thread Michael Niedermayer
On Fri, Oct 23, 2020 at 08:39:38PM +0200, Michael Niedermayer wrote:
> Fixes: NULL ptr dereference
> Fixes: 
> 26508/clusterfuzz-testcase-minimized-ffmpeg_dem_AAX_fuzzer-5694725249826816
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/aaxdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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/5] avformat/utils: wrap_timestamp() is only needed for less than 64 bits

2021-01-11 Thread Michael Niedermayer
On Sun, Nov 08, 2020 at 12:17:08AM +0100, Michael Niedermayer wrote:
> Fixes: shift exponent 64 is too large for 64-bit type 'unsigned long long'
> Fixes: 
> 26497/clusterfuzz-testcase-minimized-ffmpeg_dem_AVI_fuzzer-5690188355076096
> Fixes: 
> 26903/clusterfuzz-testcase-minimized-ffmpeg_dem_LUODAT_fuzzer-5641466929741824
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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] avformat/mxfdec: Free all types for both Descriptors

2021-01-11 Thread Michael Niedermayer
On Fri, Jan 08, 2021 at 12:29:36AM +0100, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes: 
> 26352/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5201158714687488
> 
> Suggested-by: Tomas Härdin 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfdec.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

will apply

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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".

[FFmpeg-devel] Development of a CUDA accelerated variant of the libav vf_tonemap

2021-01-11 Thread Felix LeClair
Hi guys and gals, first post on this mailing list, apologies for any 
formatting/stylistic snafus


TLDR; we currently have tone mapping filters (typically used to map 
content from a 10bit HDR source to an 8bit SDR output) that are done on 
CPU with Zscale from Zlib, or hardware implementations using VAAPI or 
OpenCL. Having a version implemented in CUDA would round out the main 
HWaccels types.


Context:
	I'm a computer engineering student up in Canada with an interest in 
high efficiency distributed processing. As a personal project I'm 
trying to build a cluster of Nvidia Jetson Nano's to be able to handle 
a few dozen streams (mix of SD, HD, FHD, UHD, 4kHDR) at once while 
drawing south of 100W at peak. These little devices can do anywhere 
from 1 to 9 streams of content at a time depending on 
resolution/framerate in hardware in any mix of HEVC or H.264, so 3 of 
them should get me most of the way to where I want to go (this would be 
a 30W package capable of ~12 2160p30@10 bit -> 1080p30 8bit streams).


The issue is that, 4 little arm64 cores are just not going to be able 
to tonemap using Zscale in real time, even with the encoder and 
decoders sharing memory with the CPU (so no PCIe memcopy penalty). On 
the other hand, the built in GPU and the relative simplicity of most 
tone mapping algorithms (say hable) should make quick work of this. 
Unfortunately (or fortunately for me to learn with?) there isn't a CUDA 
version of the filter.


Question/guidance:
I've read through the doc on how to write filters, as well as looking 
at the other cuda filters currently in the source and have a general 
idea of where I'm going, but haven't been able to fully nail down how 
to access frames from hwupload_cuda passed to vf_tonemap_cuda.c which 
in turn passes that frame to vf_tonemap_cuda.cu for processing. I have 
a repo with everything I've been pulling together for my project, but 
the piece of interest is under */cuda_filter/ in the source tree. 



Would anyone mind helping me out with how to architect this?

Thanks!

FelixCLC
(Alias's: FCLC, camofelix )



___
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/5] avcodec/Makefile: Remove unnecessary cbrt_data dependency

2021-01-11 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index fea37ef3c9..36891bbb57 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -174,7 +174,7 @@ OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o 
> aaccoder.o aacenctab.o\
>aacenc_tns.o \
>aacenc_ltp.o \
>aacenc_pred.o \
> -  psymodel.o mpeg4audio.o kbdwin.o 
> cbrt_data.o
> +  psymodel.o mpeg4audio.o kbdwin.o
>  OBJS-$(CONFIG_AAC_MF_ENCODER)  += mfenc.o mf_utils.o
>  OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o
>  OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o ac3.o 
> kbdwin.o ac3tab.o
> 
Will apply this patchset tomorrow unless there are objections.

- Andreas
___
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/5] avcodec/tableprint: Don't include mem_internal.h

2021-01-11 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> tableprint.h does not declare anything as aligned; it just prints
> DECLARE_ALIGNED. So it can be removed; in fact, it needs to be removed,
> because mem_internal.h includes config.h which leads to warnings when
> building with hardcoded tables enabled because of redefinitions of
> CONFIG_HARDCODED_TABLES.
> 
> (Furthermore, config.h is only valid for the target, not the host,
> so HAVE_LOCAL_ALIGNED might even be wrong here.)
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/tableprint.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/tableprint.h b/libavcodec/tableprint.h
> index e57eeb6ca6..6f61c7124b 100644
> --- a/libavcodec/tableprint.h
> +++ b/libavcodec/tableprint.h
> @@ -27,7 +27,6 @@
>  #include 
>  
>  #include "libavutil/common.h"
> -#include "libavutil/mem_internal.h"
>  
>  #define WRITE_1D_FUNC_ARGV(type, linebrk, fmtstr, ...)\
>  void write_##type##_array(const type *data, int len)\
> 
Will apply this patch tomorrow unless there are objections.

- Andreas
___
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] avcodec/aacenctab: Simplify exporting array size

2021-01-11 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/aacenc.c| 4 ++--
>  libavcodec/aacenctab.c | 7 ++-
>  libavcodec/aacenctab.h | 6 ++
>  3 files changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> index 070a2e706a..75e40c9d7f 100644
> --- a/libavcodec/aacenc.c
> +++ b/libavcodec/aacenc.c
> @@ -999,8 +999,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
>  break;
>  s->samplerate_index = i;
>  ERROR_IF(s->samplerate_index == 16 ||
> - s->samplerate_index >= ff_aac_swb_size_1024_len ||
> - s->samplerate_index >= ff_aac_swb_size_128_len,
> + s->samplerate_index >= FF_ARRAY_ELEMS(ff_aac_swb_size_1024) ||
> + s->samplerate_index >= FF_ARRAY_ELEMS(ff_aac_swb_size_128),
>   "Unsupported sample rate %d\n", avctx->sample_rate);
>  
>  /* Bitrate limiting */
> diff --git a/libavcodec/aacenctab.c b/libavcodec/aacenctab.c
> index 874365a593..69458cf1fd 100644
> --- a/libavcodec/aacenctab.c
> +++ b/libavcodec/aacenctab.c
> @@ -88,7 +88,7 @@ static const uint8_t swb_size_1024_8[] = {
>  32, 36, 36, 40, 44, 48, 52, 56, 60, 64, 80
>  };
>  
> -const uint8_t *const ff_aac_swb_size_128[] = {
> +const uint8_t *const ff_aac_swb_size_128[13] = {
>  swb_size_128_96, swb_size_128_96, swb_size_128_64,
>  swb_size_128_48, swb_size_128_48, swb_size_128_48,
>  swb_size_128_24, swb_size_128_24, swb_size_128_16,
> @@ -96,13 +96,10 @@ const uint8_t *const ff_aac_swb_size_128[] = {
>  swb_size_128_8
>  };
>  
> -const uint8_t *const ff_aac_swb_size_1024[] = {
> +const uint8_t *const ff_aac_swb_size_1024[13] = {
>  swb_size_1024_96, swb_size_1024_96, swb_size_1024_64,
>  swb_size_1024_48, swb_size_1024_48, swb_size_1024_32,
>  swb_size_1024_24, swb_size_1024_24, swb_size_1024_16,
>  swb_size_1024_16, swb_size_1024_16, swb_size_1024_8,
>  swb_size_1024_8
>  };
> -
> -const int ff_aac_swb_size_128_len  = FF_ARRAY_ELEMS(ff_aac_swb_size_128);
> -const int ff_aac_swb_size_1024_len = FF_ARRAY_ELEMS(ff_aac_swb_size_1024);
> diff --git a/libavcodec/aacenctab.h b/libavcodec/aacenctab.h
> index dbbdf61dfd..39f7e52909 100644
> --- a/libavcodec/aacenctab.h
> +++ b/libavcodec/aacenctab.h
> @@ -38,10 +38,8 @@
>  
>  #define AAC_MAX_CHANNELS 16
>  
> -extern const uint8_t *const ff_aac_swb_size_1024[];
> -extern const int  ff_aac_swb_size_1024_len;
> -extern const uint8_t *const ff_aac_swb_size_128[];
> -extern const int  ff_aac_swb_size_128_len;
> +extern const uint8_t *const ff_aac_swb_size_1024[13];
> +extern const uint8_t *const ff_aac_swb_size_128[13];
>  
>  /* Supported layouts without using a PCE */
>  static const int64_t aac_normal_chan_layouts[7] = {
> 
Will apply this patch tomorrow unless there are objections.

- Andreas
___
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 06/11] avcodec: add cbs for h266/vvc

2021-01-11 Thread James Almer

On 1/11/2021 5:45 PM, Mark Thompson wrote:

+static int FUNC(vui_parameters)(CodedBitstreamContext *ctx, RWContext

*rw,

+    H266RawVUI *current)
+{
+    int err;
+
+    flag(vui_progressive_source_flag);
+    flag(vui_interlaced_source_flag);
+    flag(vui_non_packed_constraint_flag);
+    flag(vui_non_projected_constraint_flag);
+    flag(vui_aspect_ratio_info_present_flag);
+    if (current->vui_aspect_ratio_info_present_flag) {
+    flag(vui_aspect_ratio_constant_flag);
+    ub(8, vui_aspect_ratio_idc);
+    if (current->vui_aspect_ratio_idc == 255) {
+    ub(16, vui_sar_width);
+    ub(16, vui_sar_height);
+    }
+    } else {
+    infer(vui_aspect_ratio_constant_flag, 0);
+    infer(vui_aspect_ratio_idc, 0);
+    }
+    flag(vui_overscan_info_present_flag);
+    if (current->vui_overscan_info_present_flag)
+    flag(vui_overscan_appropriate_flag);
+    flag(vui_colour_description_present_flag);
+    if (current->vui_colour_description_present_flag) {
+    ub(8, vui_colour_primaries);
+    ub(8, vui_transfer_characteristics);
+    ub(8, vui_matrix_coeffs);
+    flag(vui_full_range_flag);
+    } else {
+    infer(vui_colour_primaries, 2);
+    infer(vui_transfer_characteristics, 2);
+    infer(vui_matrix_coeffs, 2);
+    infer(vui_full_range_flag, 0);
+    }
+    flag(vui_chroma_loc_info_present_flag);
+    if (current->vui_chroma_loc_info_present_flag) {
+    if (current->vui_progressive_source_flag &&
+    !current->vui_interlaced_source_flag) {
+    ue(vui_chroma_sample_loc_type_frame, 0, 6);
+    } else {
+    ue(vui_chroma_sample_loc_type_top_field, 0, 6);
+    ue(vui_chroma_sample_loc_type_bottom_field,  0, 6);
+    }
+    }


These are inferred as 6 when not present?


6 only happened when ChromaFormatIdc = 1, others are not defined.
and 6 is the unspecific value in the spec...
Do we really need to infer it :)


To match the colour description cases probably yes?


"When vui_chroma_loc_info_present_flag is equal to 0, 
vui_chroma_sample_loc_type_frame is not present and is inferred to be 
equal to 6, which indicates that the location of the chroma samples is 
unknown or unspecified or specified by other means not specified in this 
Specification. When vui_chroma_sample_loc_type_top_field and 
vui_chroma_sample_loc_type_bottom_field are not present, the values of 
vui_chroma_sample_loc_type_top_field and 
vui_chroma_sample_loc_type_bottom_field are inferred to be equal to 
vui_chroma_sample_loc_type_frame."


So the correct implementation i think would be

flag(vui_chroma_loc_info_present_flag);
if (current->vui_chroma_loc_info_present_flag) {
if (current->vui_progressive_source_flag &&
!current->vui_interlaced_source_flag) {
ue(vui_chroma_sample_loc_type_frame, 0, 6);
infer(vui_chroma_sample_loc_type_top_field,
  current->vui_chroma_sample_loc_type_frame);
infer(vui_chroma_sample_loc_type_bottom_field,
  current->vui_chroma_sample_loc_type_frame);
} else {
infer(vui_chroma_sample_loc_type_frame, 6);
ue(vui_chroma_sample_loc_type_top_field, 0, 6);
ue(vui_chroma_sample_loc_type_bottom_field,  0, 6);
}
} else {
infer(vui_chroma_sample_loc_type_frame, 6);
infer(vui_chroma_sample_loc_type_top_field,
  current->vui_chroma_sample_loc_type_frame);
infer(vui_chroma_sample_loc_type_bottom_field,
  current->vui_chroma_sample_loc_type_frame);
}

Also, you also need to infer the default value of almost everything when 
sps_vui_parameters_present_flag is 0. See section D.8 and how h265 does 
it with the vui_parameters_default() custom function.

___
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] Replace arrays of pointers to strings by arrays of strings

2021-01-11 Thread Andreas Rheinhardt
Marton Balint:
> 
> 
> On Wed, 6 Jan 2021, Andreas Rheinhardt wrote:
> 
>> When the difference of the longest size and the average size of
>> collection of strings is smaller than the size of a pointer, it makes
>> sense to store the strings directly in an array instead of using an
>> array of pointers to strings (unless doing so precludes deduplicating
>> strings); doing so also avoids relocations. This requirement is
>> fulfilled for several arrays of pointers to strings that are changed in
>> this commit.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> Now used sizeof("longest string") for the array element size.
> 
> Duplicating the "longest string" is very ugly, I don't find it better
> than a constant number, because a sizeof still does not say it tries to
> find the longest string.
> 
> TBH I am not a fan of these kind of patches for a few byte of savings,
> and when changing the list of strings it can actually become worse which
> won't be checked by anybody...
> 
When using position independent code, each of these pointers that is
different from NULL requires a relocation (on ELF, these are quite
expensive: 24 byte when using 64 byte systems), so that these arrays of
pointers can't be in .rodata, but only in .data (or .data.rel.ro). Even
worse, these static const objects aren't initialized in a lazy manner,*
so that pages containing pointers to be relocated are automatically
dirty even when they are actually never used. I think it is of the
utmost importance to counter this and this patch does so in a few instances.
Of course I am all ears for how to make it clear that someone who
modifies the strings also needs to check the array dimensions.

(Here is a snippet for those who want to test this for themselves:

+typedef struct Entry {
+const char *str;
+char array[4088];
+} Entry;
+
+#define REPEAT(...) __VA_ARGS__, __VA_ARGS__, __VA_ARGS__, __VA_ARGS__
+#define REPEAT2(...)
REPEAT(REPEAT(REPEAT(REPEAT(REPEAT(REPEAT(REPEAT(__VA_ARGS__)))
+
+const Entry unused[16384] = { REPEAT2({ "", "" }) };
+
)

- Andreas

*: It seems that Windows does better:
https://devblogs.microsoft.com/oldnewthing/20160413-00/?p=93301
___
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 13/30] avformat/rtpdec: Remove next pointer from Protocol Handlers

2021-01-11 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Forgotten in 61974537610d82bd35b6e3ac91ccd270c6bdc711 (notice that
> RTPDynamicProtocolHandler is not a public struct, so one can remove
> the linked-list pointer immediately (unlike in most other patches of
> this kind)).
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/rtpdec.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
> index 9144edbe8b..701ce072b6 100644
> --- a/libavformat/rtpdec.h
> +++ b/libavformat/rtpdec.h
> @@ -134,8 +134,6 @@ struct RTPDynamicProtocolHandler {
>  /** Parse handler for this dynamic packet */
>  DynamicPayloadPacketHandlerProc parse_packet;
>  int (*need_keyframe)(PayloadContext *context);
> -
> -struct RTPDynamicProtocolHandler *next;
>  };
>  
>  typedef struct RTPPacket {
> 
Will apply this and the next patch tomorrow unless there are objections.

- Andreas
___
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] avcodec/aacenctab: Simplify exporting array size

2021-01-11 Thread zhilizhao(赵志立)


> On Jan 12, 2021, at 8:16 AM, Andreas Rheinhardt 
>  wrote:
> 
> Andreas Rheinhardt:
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> libavcodec/aacenc.c| 4 ++--
>> libavcodec/aacenctab.c | 7 ++-
>> libavcodec/aacenctab.h | 6 ++
>> 3 files changed, 6 insertions(+), 11 deletions(-)
>> 
>> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
>> index 070a2e706a..75e40c9d7f 100644
>> --- a/libavcodec/aacenc.c
>> +++ b/libavcodec/aacenc.c
>> @@ -999,8 +999,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
>> break;
>> s->samplerate_index = i;
>> ERROR_IF(s->samplerate_index == 16 ||
>> - s->samplerate_index >= ff_aac_swb_size_1024_len ||
>> - s->samplerate_index >= ff_aac_swb_size_128_len,
>> + s->samplerate_index >= FF_ARRAY_ELEMS(ff_aac_swb_size_1024) ||
>> + s->samplerate_index >= FF_ARRAY_ELEMS(ff_aac_swb_size_128),
>>  "Unsupported sample rate %d\n", avctx->sample_rate);
>> 
>> /* Bitrate limiting */
>> diff --git a/libavcodec/aacenctab.c b/libavcodec/aacenctab.c
>> index 874365a593..69458cf1fd 100644
>> --- a/libavcodec/aacenctab.c
>> +++ b/libavcodec/aacenctab.c
>> @@ -88,7 +88,7 @@ static const uint8_t swb_size_1024_8[] = {
>> 32, 36, 36, 40, 44, 48, 52, 56, 60, 64, 80
>> };
>> 
>> -const uint8_t *const ff_aac_swb_size_128[] = {
>> +const uint8_t *const ff_aac_swb_size_128[13] = {
>> swb_size_128_96, swb_size_128_96, swb_size_128_64,
>> swb_size_128_48, swb_size_128_48, swb_size_128_48,
>> swb_size_128_24, swb_size_128_24, swb_size_128_16,
>> @@ -96,13 +96,10 @@ const uint8_t *const ff_aac_swb_size_128[] = {
>> swb_size_128_8
>> };
>> 
>> -const uint8_t *const ff_aac_swb_size_1024[] = {
>> +const uint8_t *const ff_aac_swb_size_1024[13] = {
>> swb_size_1024_96, swb_size_1024_96, swb_size_1024_64,
>> swb_size_1024_48, swb_size_1024_48, swb_size_1024_32,
>> swb_size_1024_24, swb_size_1024_24, swb_size_1024_16,
>> swb_size_1024_16, swb_size_1024_16, swb_size_1024_8,
>> swb_size_1024_8
>> };
>> -
>> -const int ff_aac_swb_size_128_len  = FF_ARRAY_ELEMS(ff_aac_swb_size_128);
>> -const int ff_aac_swb_size_1024_len = FF_ARRAY_ELEMS(ff_aac_swb_size_1024);
>> diff --git a/libavcodec/aacenctab.h b/libavcodec/aacenctab.h
>> index dbbdf61dfd..39f7e52909 100644
>> --- a/libavcodec/aacenctab.h
>> +++ b/libavcodec/aacenctab.h
>> @@ -38,10 +38,8 @@
>> 
>> #define AAC_MAX_CHANNELS 16
>> 
>> -extern const uint8_t *const ff_aac_swb_size_1024[];
>> -extern const int  ff_aac_swb_size_1024_len;
>> -extern const uint8_t *const ff_aac_swb_size_128[];
>> -extern const int  ff_aac_swb_size_128_len;
>> +extern const uint8_t *const ff_aac_swb_size_1024[13];
>> +extern const uint8_t *const ff_aac_swb_size_128[13];
>> 
>> /* Supported layouts without using a PCE */
>> static const int64_t aac_normal_chan_layouts[7] = {
>> 
> Will apply this patch tomorrow unless there are objections.

Two mismatches can happen after the patch:
1. mismatch between the array length in header file and source file
2. mismatch between the specified array length and the number of
elements

Add or remove element needs to change three parts of the code.
There is no such disadvantage before the patch.

Just my two cents.

> 
> - Andreas
> ___
> 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 1/1] bug: test pointer to be used.

2021-01-11 Thread James Almer

On 1/4/2021 3:11 PM, AlexisWilke wrote:

Two tests check the opposite pointer before using it. If only one of these
is set to a valid pointer, one of these functions will crash, the other will
ignore the pointer.
---
  libavformat/allformats.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0e0caaad39..6990af55f4 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -541,7 +541,7 @@ const AVOutputFormat *av_muxer_iterate(void **opaque)
  
  if (i < size) {

  f = muxer_list[i];
-} else if (indev_list) {
+} else if (outdev_list) {
  f = outdev_list[i - size];
  }
  
@@ -558,7 +558,7 @@ const AVInputFormat *av_demuxer_iterate(void **opaque)
  
  if (i < size) {

  f = demuxer_list[i];
-} else if (outdev_list) {
+} else if (indev_list) {
  f = indev_list[i - size];
  }


Applied. Thanks.
___
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] Development of a CUDA accelerated variant of the libav vf_tonemap

2021-01-11 Thread Lynne
Jan 11, 2021, 23:27 by felix.leclair...@hotmail.com:

> Hi guys and gals, first post on this mailing list, apologies for any 
> formatting/stylistic snafus
>
> TLDR; we currently have tone mapping filters (typically used to map content 
> from a 10bit HDR source to an 8bit SDR output) that are done on CPU with 
> Zscale from Zlib, or hardware implementations using VAAPI or OpenCL. Having a 
> version implemented in CUDA would round out the main HWaccels types.
>
> Context:
>  I'm a computer engineering student up in Canada with an interest in high 
> efficiency distributed processing. As a personal project I'm trying to build 
> a cluster of Nvidia Jetson Nano's to be able to handle a few dozen streams 
> (mix of SD, HD, FHD, UHD, 4kHDR) at once while drawing south of 100W at peak. 
> These little devices can do anywhere from 1 to 9 streams of content at a time 
> depending on resolution/framerate in hardware in any mix of HEVC or H.264, so 
> 3 of them should get me most of the way to where I want to go (this would be 
> a 30W package capable of ~12 2160p30@10 bit -> 1080p30 8bit streams).
>
> The issue is that, 4 little arm64 cores are just not going to be able to 
> tonemap using Zscale in real time, even with the encoder and decoders sharing 
> memory with the CPU (so no PCIe memcopy penalty). On the other hand, the 
> built in GPU and the relative simplicity of most tone mapping algorithms (say 
> hable) should make quick work of this. Unfortunately (or fortunately for me 
> to learn with?) there isn't a CUDA version of the filter.
>
> Question/guidance:
> I've read through the doc on how to write filters, as well as looking at the 
> other cuda filters currently in the source and have a general idea of where 
> I'm going, but haven't been able to fully nail down how to access frames from 
> hwupload_cuda passed to vf_tonemap_cuda.c which in turn passes that frame to 
> vf_tonemap_cuda.cu for processing. I have a repo with everything I've been 
> pulling together for my project, but the piece of interest is under 
> */cuda_filter/ in the source tree. 
> 
>
> Would anyone mind helping me out with how to architect this?
>

The tonemap filter is just a (very old by now) copy of libplacebo's tonemapping.
No one has bothered to keep it in sync.
I'm working on a libplacebo wrapper currently, so once that's merged there
will be up to date hardware tonemapping.
___
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] lavu: support arbitrary-point FFT and all even (i)MDCT transforms

2021-01-11 Thread Lynne
This patch adds support for arbitrary-point FFTs and all even MDCT 
transforms.
Odd MDCTs are not supported yet as they're based on the DCT-II and DCT-III
and they're very niche.

With this we can now write tests.

Patch attached.

>From 63eac77a5689e560dfa1da793d10851ea799bab7 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Tue, 12 Jan 2021 08:11:47 +0100
Subject: [PATCH] lavu: support arbitrary-point FFT and all even (i)MDCT
 transforms

This patch adds support for arbitrary-point FFTs and all even MDCT
transforms.
Odd MDCTs are not supported yet as they're based on the DCT-II and DCT-III
and they're very niche.

With this we can now write tests.
---
 libavutil/tx.h  |   5 +-
 libavutil/tx_priv.h |   3 ++
 libavutil/tx_template.c | 101 +---
 3 files changed, 101 insertions(+), 8 deletions(-)

diff --git a/libavutil/tx.h b/libavutil/tx.h
index 418e8ec1ed..f49eb8c4c7 100644
--- a/libavutil/tx.h
+++ b/libavutil/tx.h
@@ -51,6 +51,8 @@ enum AVTXType {
  * For inverse transforms, the stride specifies the spacing between each
  * sample in the input array in bytes. The output will be a flat array.
  * Stride must be a non-zero multiple of sizeof(float).
+ * NOTE: the inverse transform is half-length, meaning the output will not
+ * contain redundant data. This is what most codecs work with.
  */
 AV_TX_FLOAT_MDCT = 1,
 /**
@@ -93,8 +95,7 @@ typedef void (*av_tx_fn)(AVTXContext *s, void *out, void *in, ptrdiff_t stride);
 
 /**
  * Initialize a transform context with the given configuration
- * Currently power of two lengths from 2 to 131072 are supported, along with
- * any length decomposable to a power of two and either 3, 5 or 15.
+ * (i)MDCTs with an odd length are currently not supported.
  *
  * @param ctx the context to allocate, will be NULL on error
  * @param tx pointer to the transform function pointer to set
diff --git a/libavutil/tx_priv.h b/libavutil/tx_priv.h
index 0ace3e90dc..18a07c312c 100644
--- a/libavutil/tx_priv.h
+++ b/libavutil/tx_priv.h
@@ -58,6 +58,7 @@ typedef void FFTComplex;
 (dim) = (are) * (bim) - (aim) * (bre); \
 } while (0)
 
+#define UNSCALE(x) (x)
 #define RESCALE(x) (x)
 
 #define FOLD(a, b) ((a) + (b))
@@ -85,6 +86,7 @@ typedef void FFTComplex;
 (dim)   = (int)(((accu) + 0x4000) >> 31);  \
 } while (0)
 
+#define UNSCALE(x) ((double)x/2147483648.0)
 #define RESCALE(x) (av_clip64(lrintf((x) * 2147483648.0), INT32_MIN, INT32_MAX))
 
 #define FOLD(x, y) ((int)((x) + (unsigned)(y) + 32) >> 6)
@@ -108,6 +110,7 @@ struct AVTXContext {
 int m;  /* Ptwo part */
 int inv;/* Is inverted */
 int type;   /* Type */
+double scale;   /* Scale */
 
 FFTComplex *exptab; /* MDCT exptab */
 FFTComplex *tmp;/* Temporary buffer needed for all compound transforms */
diff --git a/libavutil/tx_template.c b/libavutil/tx_template.c
index 7f4ca2f31e..a91b8f900c 100644
--- a/libavutil/tx_template.c
+++ b/libavutil/tx_template.c
@@ -397,6 +397,31 @@ static void monolithic_fft(AVTXContext *s, void *_out, void *_in,
 fft_dispatch[mb](out);
 }
 
+static void naive_fft(AVTXContext *s, void *_out, void *_in,
+  ptrdiff_t stride)
+{
+FFTComplex *in = _in;
+FFTComplex *out = _out;
+const int n = s->n;
+double phase = s->inv ? 2.0*M_PI/n : -2.0*M_PI/n;
+
+for(int i = 0; i < n; i++) {
+FFTComplex tmp = { 0 };
+for(int j = 0; j < n; j++) {
+const double factor = phase*i*j;
+const FFTComplex mult = {
+RESCALE(cos(factor)),
+RESCALE(sin(factor)),
+};
+FFTComplex res;
+CMUL3(res, in[j], mult);
+tmp.re += res.re;
+tmp.im += res.im;
+}
+out[i] = tmp;
+}
+}
+
 #define DECL_COMP_IMDCT(N) \
 static void compound_imdct_##N##xM(AVTXContext *s, void *_dst, void *_src, \
ptrdiff_t stride)   \
@@ -553,6 +578,57 @@ static void monolithic_mdct(AVTXContext *s, void *_dst, void *_src,
 }
 }
 
+static void naive_imdct(AVTXContext *s, void *_dst, void *_src,
+ptrdiff_t stride)
+{
+int len = s->n;
+int len2 = len*2;
+FFTSample *src = _src;
+FFTSample *dst = _dst;
+double scale = s->scale;
+const double phase = M_PI/(4.0*len2);
+
+stride /= sizeof(*src);
+
+for (int i = 0; i < len; i++) {
+double sum_d = 0.0;
+double sum_u = 0.0;
+double i_d = phase * (4*len  - 2*i - 1);
+double i_u = phase * (3*len2 + 2*i + 1);
+for (int j = 0; j < len2; j++) {
+double a = (2 * j + 1);
+double a_d = cos(a * i_d);
+double a_u = cos(a * i_u);
+double val = UNSCALE(src[j*stride]);

Re: [FFmpeg-devel] [PATCH 6/6] fft_fixed: remove 16-bit FFT code

2021-01-11 Thread Lynne
Jan 9, 2021, 20:22 by d...@lynne.ee:

> No longer used by anything. 
> Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's
> simply too much work for code meant to be all removed anyway.
>
> Patch attached. Read patch 1/6 to see the size savings.
>
Forgot to remove the tests, making FATE fail.
Fixed, patch attached.

>From 7358525927895a1a1201b29711d0535616984889 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Sat, 9 Jan 2021 16:31:19 +0100
Subject: [PATCH 6/6] fft_fixed: remove 16-bit FFT code

No longer used by anything.
Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's
simply too much work for code meant to be all removed anyway.
---
 libavcodec/Makefile |   9 +-
 libavcodec/arm/Makefile |   6 +-
 libavcodec/arm/fft_fixed_init_arm.c |  40 -
 libavcodec/arm/fft_fixed_neon.S | 261 
 libavcodec/fft-internal.h   |  27 +--
 libavcodec/fft.h|   8 -
 libavcodec/fft_fixed.c  |  21 ---
 libavcodec/fft_template.c   |   2 -
 libavcodec/tests/.gitignore |   1 -
 libavcodec/tests/fft-fixed.c|  21 ---
 tests/fate/fft.mak  |   2 +-
 11 files changed, 8 insertions(+), 390 deletions(-)
 delete mode 100644 libavcodec/arm/fft_fixed_init_arm.c
 delete mode 100644 libavcodec/arm/fft_fixed_neon.S
 delete mode 100644 libavcodec/fft_fixed.c
 delete mode 100644 libavcodec/tests/fft-fixed.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index bf4256dc87..446e6e6b3b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -83,10 +83,9 @@ OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o
 OBJS-$(CONFIG_FAANDCT) += faandct.o
 OBJS-$(CONFIG_FAANIDCT)+= faanidct.o
 OBJS-$(CONFIG_FDCTDSP) += fdctdsp.o jfdctfst.o jfdctint.o
-FFT-OBJS-$(CONFIG_HARDCODED_TABLES)+= cos_tables.o cos_fixed_tables.o
-OBJS-$(CONFIG_FFT) += avfft.o fft_fixed.o fft_float.o \
-  fft_fixed_32.o fft_init_table.o \
-  $(FFT-OBJS-yes)
+FFT-OBJS-$(CONFIG_HARDCODED_TABLES)+= cos_tables.o
+OBJS-$(CONFIG_FFT) += avfft.o fft_float.o fft_fixed_32.o \
+  fft_init_table.o $(FFT-OBJS-yes)
 OBJS-$(CONFIG_FLACDSP) += flacdsp.o
 OBJS-$(CONFIG_FMTCONVERT)  += fmtconvert.o
 OBJS-$(CONFIG_GOLOMB)  += golomb.o
@@ -1217,7 +1216,7 @@ TESTPROGS = avpacket\
 
 TESTPROGS-$(CONFIG_CABAC) += cabac
 TESTPROGS-$(CONFIG_DCT)   += avfft
-TESTPROGS-$(CONFIG_FFT)   += fft fft-fixed fft-fixed32
+TESTPROGS-$(CONFIG_FFT)   += fft fft-fixed32
 TESTPROGS-$(CONFIG_GOLOMB)+= golomb
 TESTPROGS-$(CONFIG_IDCTDSP)   += dct
 TESTPROGS-$(CONFIG_IIRFILTER) += iirfilter
diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index 23e8abbf2e..c4ab93aeeb 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -5,8 +5,7 @@ OBJS-$(CONFIG_AC3DSP)  += arm/ac3dsp_init_arm.o \
   arm/ac3dsp_arm.o
 OBJS-$(CONFIG_AUDIODSP)+= arm/audiodsp_init_arm.o
 OBJS-$(CONFIG_BLOCKDSP)+= arm/blockdsp_init_arm.o
-OBJS-$(CONFIG_FFT) += arm/fft_init_arm.o\
-  arm/fft_fixed_init_arm.o
+OBJS-$(CONFIG_FFT) += arm/fft_init_arm.o
 OBJS-$(CONFIG_FLACDSP) += arm/flacdsp_init_arm.o\
   arm/flacdsp_arm.o
 OBJS-$(CONFIG_FMTCONVERT)  += arm/fmtconvert_init_arm.o
@@ -108,8 +107,7 @@ NEON-OBJS-$(CONFIG_AUDIODSP)   += arm/audiodsp_init_neon.o  \
   arm/int_neon.o
 NEON-OBJS-$(CONFIG_BLOCKDSP)   += arm/blockdsp_init_neon.o  \
   arm/blockdsp_neon.o
-NEON-OBJS-$(CONFIG_FFT)+= arm/fft_neon.o\
-  arm/fft_fixed_neon.o
+NEON-OBJS-$(CONFIG_FFT)+= arm/fft_neon.o
 NEON-OBJS-$(CONFIG_FMTCONVERT) += arm/fmtconvert_neon.o
 NEON-OBJS-$(CONFIG_G722DSP)+= arm/g722dsp_neon.o
 NEON-OBJS-$(CONFIG_H264CHROMA) += arm/h264cmc_neon.o
diff --git a/libavcodec/arm/fft_fixed_init_arm.c b/libavcodec/arm/fft_fixed_init_arm.c
deleted file mode 100644
index 30ce48d352..00
--- a/libavcodec/arm/fft_fixed_init_arm.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright (c) 2009 Mans Rullgard 
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by t

Re: [FFmpeg-devel] [PATCH 1/6] ac3enc_fixed: convert to 32-bit sample format

2021-01-11 Thread Lynne
Jan 9, 2021, 22:01 by andreas.rheinha...@gmail.com:

> Lynne:
>
>> @@ -165,7 +164,11 @@ typedef struct AC3EncodeContext {
>>  AVCodecContext *avctx;  ///< parent AVCodecContext
>>  PutBitContext pb;   ///< bitstream writer context
>>  AudioDSPContext adsp;
>> +#if AC3ENC_FLOAT
>>  AVFloatDSPContext *fdsp;
>> +#else
>> +AVFixedDSPContext *fdsp;
>> +#endif
>>  MECmpContext mecc;
>>  AC3DSPContext ac3dsp;   ///< AC-3 optimized functions
>>  FFTContext mdct;///< FFT context for MDCT 
>> calculation
>>
> [...]
>
>> @@ -118,9 +89,10 @@ static CoefType calc_cpl_coord(CoefSumType energy_ch, 
>> CoefSumType energy_cpl)
>>  static av_cold void ac3_fixed_mdct_end(AC3EncodeContext *s)
>>  {
>>  ff_mdct_end(&s->mdct);
>> +av_freep(&s->fdsp);
>> +av_freep(&s->mdct_window);
>>  }
>>
>
> ff_ac3_encode_close already unconditionally frees fdsp, so freeing it
> above is either unnecessary or ac3_float_mdct_end should also free its
> fdsp (and ff_ac3_encode_close shouldn't). Freeing mdct_window can also
> be moved to ff_ac3_encode_close (which already frees several buffers
> whose pointed-to-type depends upon the encoding mode).
> Notice that ac3enc.c uses the fixed-point mode, but the layout of
> AC3EncodeContext does not depend upon this (apart from pointed-to-types,
> of course). Actually, ff_mdct_end does the same for both fixed- and
> floating-point mode, so one could even incorporate
> ac3_fixed/float_mdct_end into ff_ac3_encode_close.
>
Done. Left ac3_fixed/float_mdct_end as-is for now.
New patch attached.

>From 9e20fe47bba46efd8fb3b47ea079a96c86d836ae Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Sat, 9 Jan 2021 01:51:52 +0100
Subject: [PATCH 1/6] ac3enc_fixed: convert to 32-bit sample format

The AC3 encoder used to be a separate library called "Aften", which
got merged into libavcodec (literally, SVN commits and all).
The merge preserved as much features from the library as possible.

The code had two versions - a fixed point version and a floating
point version. FFmpeg had floating point DSP code used by other
codecs, the AC3 decoder including, so the floating-point DSP was
simply replaced with FFmpeg's own functions.
However, FFmpeg had no fixed-point audio code at that point. So
the encoder brought along its own fixed-point DSP functions,
including a fixed-point MDCT.

The fixed-point MDCT itself is trivially just a float MDCT with a
different type and each multiply being a fixed-point multiply.
So over time, it got refactored, and the FFT used for all other codecs
was templated.

Due to design decisions at the time, the fixed-point version of the
encoder operates at 16-bits of precision. Although convenient, this,
even at the time, was inadequate and inefficient. The encoder is noisy,
does not produce output comparable to the float encoder, and even
rings at higher frequencies due to the badly approximated winow function.

Enter MIPS (owned by Imagination Technologies at the time). They wanted
quick fixed-point decoding on their FPUless cores. So they contributed
patches to template the AC3 decoder so it had both a fixed-point
and a floating-point version. They also did the same for the AAC decoder.
They however, used 32-bit samples. Not 16-bits. And we did not have
32-bit fixed-point DSP functions, including an MDCT. But instead of
templating our MDCT to output 3 versions (float, 32-bit fixed and 16-bit fixed),
they simply copy-pasted their own MDCT into ours, and completely
ifdeffed our own MDCT code out if a 32-bit fixed point MDCT was selected.

This is also the status quo nowadays - 2 separate MDCTs, one which
produces floating point and 16-bit fixed point versions, and one
sort-of integrated which produces 32-bit MDCT.

MIPS weren't all that interested in encoding, so they left the encoder
as-is, and they didn't care much about the ifdeffery, mess or quality - it's
not their problem.

So the MDCT/FFT code has always been a thorn in anyone looking to clean up
code's eye.

Backstory over. Internally AC3 operates on 25-bit fixed-point coefficients.
So for the floating point version, the encoder simply runs the float MDCT,
and converts the resulting coefficients to 25-bit fixed-point, as AC3 is inherently
a fixed-point codec. For the fixed-point version, the input is 16-bit samples,
so to maximize precision the frame samples are analyzed and the highest set
bit is detected via ac3_max_msb_abs_int16(), and the coefficients are then
scaled up via ac3_lshift_int16(), so the input for the FFT is always at least 14 bits,
computed in normalize_samples(). After FFT, the coefficients are scaled up to 25 bits.

This patch simply changes the encoder to accept 32-bit samples, reusing
the already well-optimized 32-bit MDCT code, allowing us to clean up and drop
a large part of a very messy code of ours, as well as prepare for the future lavu/tx
conversion. The coefficients are simply scaled down to 25 bits during windowing,
skipping 2 s

Re: [FFmpeg-devel] [PATCH 1/6] ac3enc_fixed: convert to 32-bit sample format

2021-01-11 Thread Andreas Rheinhardt
Lynne:
> Jan 9, 2021, 22:01 by andreas.rheinha...@gmail.com:
> 
>> Lynne:
>>
>>> @@ -165,7 +164,11 @@ typedef struct AC3EncodeContext {
>>>  AVCodecContext *avctx;  ///< parent AVCodecContext
>>>  PutBitContext pb;   ///< bitstream writer context
>>>  AudioDSPContext adsp;
>>> +#if AC3ENC_FLOAT
>>>  AVFloatDSPContext *fdsp;
>>> +#else
>>> +AVFixedDSPContext *fdsp;
>>> +#endif
>>>  MECmpContext mecc;
>>>  AC3DSPContext ac3dsp;   ///< AC-3 optimized functions
>>>  FFTContext mdct;///< FFT context for MDCT 
>>> calculation
>>>
>> [...]
>>
>>> @@ -118,9 +89,10 @@ static CoefType calc_cpl_coord(CoefSumType energy_ch, 
>>> CoefSumType energy_cpl)
>>>  static av_cold void ac3_fixed_mdct_end(AC3EncodeContext *s)
>>>  {
>>>  ff_mdct_end(&s->mdct);
>>> +av_freep(&s->fdsp);
>>> +av_freep(&s->mdct_window);
>>>  }
>>>
>>
>> ff_ac3_encode_close already unconditionally frees fdsp, so freeing it
>> above is either unnecessary or ac3_float_mdct_end should also free its
>> fdsp (and ff_ac3_encode_close shouldn't). Freeing mdct_window can also
>> be moved to ff_ac3_encode_close (which already frees several buffers
>> whose pointed-to-type depends upon the encoding mode).
>> Notice that ac3enc.c uses the fixed-point mode, but the layout of
>> AC3EncodeContext does not depend upon this (apart from pointed-to-types,
>> of course). Actually, ff_mdct_end does the same for both fixed- and
>> floating-point mode, so one could even incorporate
>> ac3_fixed/float_mdct_end into ff_ac3_encode_close.
>>
> Done. Left ac3_fixed/float_mdct_end as-is for now.
> New patch attached.
> >
> @@ -129,8 +99,31 @@ static av_cold void ac3_fixed_mdct_end(AC3EncodeContext 
> *s)
>   */
>  static av_cold int ac3_fixed_mdct_init(AC3EncodeContext *s)
>  {
> +int32_t *iwin;
> +float fwin[AC3_BLOCK_SIZE];
> +
>  int ret = ff_mdct_init(&s->mdct, 9, 0, -1.0);
> -s->mdct_window = ff_ac3_window;

You forgot to remove this table.

> +if (ret < 0)
> +return ret;
> +
> +iwin = av_malloc_array(AC3_WINDOW_SIZE, sizeof(*iwin));
> +if (!iwin)
> +return AVERROR(ENOMEM);
> +
> +ff_kbd_window_init(fwin, 5.0, AC3_WINDOW_SIZE/2);
> +
> +for (int i = 0; i < AC3_WINDOW_SIZE/2; i++)
> +iwin[i] = lrintf(fwin[i] * (1 << 22));
> +

Does this lead to a different result than using ff_kbd_window_init_fixed
directly?

> +for (int i = 0; i < AC3_WINDOW_SIZE/2; i++)
> +iwin[AC3_WINDOW_SIZE-1-i] = iwin[i];
> +
> +s->mdct_window = iwin;
> +
> +s->fdsp = avpriv_alloc_fixed_dsp(s->avctx->flags & 
> AV_CODEC_FLAG_BITEXACT);
> +if (!s->fdsp)
> +return AVERROR(ENOMEM);
> +
>  return 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 6/6] fft_fixed: remove 16-bit FFT code

2021-01-11 Thread Andreas Rheinhardt
Lynne:
> Jan 9, 2021, 20:22 by d...@lynne.ee:
> 
>> No longer used by anything. 
>> Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's
>> simply too much work for code meant to be all removed anyway.
>>
>> Patch attached. Read patch 1/6 to see the size savings.
>>
> Forgot to remove the tests, making FATE fail.
> Fixed, patch attached.
> 
According to patchwork, even the very first of your patches doesn't pass
FATE. And given that your second version (of the first patch) didn't
change anything wrt FATE, it won't be different with v2.

- Andreas
___
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] avformat/fifo: utilize a clone packet for muxing

2021-01-11 Thread Jan Ekström
On Mon, Jan 11, 2021 at 10:53 PM Andreas Rheinhardt
 wrote:
>
> Jan Ekström:
> > On Tue, Dec 8, 2020 at 2:54 PM Jan Ekström  wrote:
> >>
> >> From: Jan Ekström 
> >>
> >> This way the timestamp adjustments do not have to be manually
> >> undone in case of failure and need to recover/retry.
> >>
> >> Fixes an issue where the timestamp adjustment would be re-done over
> >> and over again when recovery by muxing the same AVPacket again is
> >> attempted. Would become visible if the fifo muxer's time base and
> >> the output muxer's time base do not match (by the value either
> >> becoming smaller and smaller, or larger and larger).
> >>
> >> Signed-off-by: Jan Ekström 
> >
> > Ping.
> >
> > Unless someone finds some disgruntling points in this patch, I will
> > soon move towards applying this.
> >
> > My initial plan was to make a simplified v2 where the output AVPacket
> > was on stack limited to the fifo_thread_write_packet context, but
> > apparently gradual removal of stack usage of AVPackets is being
> > planned, so I decided to not to.
> >
> > Best regards,
> > Jan
>
> Can't you just record (in FifoMessage) whether the timestamps have
> already been converted to the desired timebase?

Back when I found this issue in this function that aligns the time
bases and writes the packet on the underlying avformat context, I did
not think of that, but I did think of reversing the time base scaling
in case of failure. That I then opted not to do due to possibly being
inaccurate unless I saved all of those values from the AVPacket that
av_packet_rescale_ts touches. Thus, I settled on just utilizing a
reference/copy for the actual muxing, so that it could be easily
discarded and the original AVPacket's values were not lost.

> (Or why not just copy
> the timebase chosen by the internal muxer to the user-visible stream so
> that we don't even have to convert it? This is how muxers always operate.)

This one sounds more like the correct way in the end, if possible. My
attempt for now was to just fix an issue within the current logic
(time base handling in case of failure was forgotten). I am trying to
remind myself at which point the AVStreams should no longer be
poked/modified as far as time base is concerned... init or header?
init seems to call init_pts in libavformat/mux.c, so my initial
guesstimate is that where fifo.c is currently doing its things
(fifo_mux_init), you could just add the time base sync. Most API
clients tend to call only avformat_write_header so in that sense with
various API clients you probably wouldn't even notice the difference
:) .

Jan
___
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".