Re: [FFmpeg-devel] [PATCH] avformat/libsrt: Decode URL parameter strings

[zhilizhao(赵志立)]

> On Aug 11, 2023, at 00:13, Armin Hasitzka  wrote:
> 
> Hi again,
> 
> we found this the other day when using a stream ID containing "%2F",
> expecting this to be resolved to "/". While "%2F" could obviously be sent
> decoded, "&" (decoded) would currently end the value and not be used, "+"
> (decoded) would be overwritten with " ", and "=" (decoded) could cause
> entirely unexpected outcomes (albeit all these characters being allowed by
> SRT for various string inputs).
> 
> As for changing `av_strndup` to `ff_urldecode` (which removes a length
> check); I don't think that this particular length check added any
> protection (`av_find_info_tag` adds a trailing `\0` if found). This
> thinking is also evident at the two other places where `ff_urldecode`
> replaced `av_strdup`.
> 
> It would be amazing if we could get this merged upstream :)
> 

Thanks for the contribution, but the issue is kind of complex.

1. The format of streamid isn’t take URL into consideration

"#!::u=admin,r=foo”

2. Obviously some implementation and usecases depend on these fields to
be passed directly without URL encoding/decoding.

The same issue has been filed to srt again and again, ref.

https://github.com/Haivision/srt/issues/2749

and #1871, #1173, #2015.

I think we shouldn’t put these fields into URL at the first place.
Now doing any change, even if it’s technically correct, will make
regression issues.

I have no idea to improve the code. But it’s easy to solve from the
user’s point of view: don’t set these fields via URL, just use options.
These is no implementation dependent behavior with options.

> ---
>  libavformat/libsrt.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> index cd8f5b1e7d..8986616334 100644
> --- a/libavformat/libsrt.c
> +++ b/libavformat/libsrt.c
> @@ -32,6 +32,7 @@
>  #include "network.h"
>  #include "os_support.h"
>  #include "url.h"
> +#include "urldecode.h"
>  
>  /* This is for MPEG-TS and it's a default SRTO_PAYLOADSIZE for SRTT_LIVE (8 
> TS packets) */
>  #ifndef SRT_LIVE_DEFAULT_PAYLOAD_SIZE
> @@ -547,7 +548,7 @@ static int libsrt_open(URLContext *h, const char *uri, 
> int flags)
>  }
>  if (av_find_info_tag(buf, sizeof(buf), "passphrase", p)) {
>  av_freep(>passphrase);
> -s->passphrase = av_strndup(buf, strlen(buf));
> +s->passphrase = ff_urldecode(buf, 0);
>  }
>  #if SRT_VERSION_VALUE >= 0x010302
>  if (av_find_info_tag(buf, sizeof(buf), "enforced_encryption", p)) {
> @@ -632,7 +633,7 @@ static int libsrt_open(URLContext *h, const char *uri, 
> int flags)
>  }
>  if (av_find_info_tag(buf, sizeof(buf), "streamid", p)) {
>  av_freep(>streamid);
> -s->streamid = av_strdup(buf);
> +s->streamid = ff_urldecode(buf, 0);
>  if (!s->streamid) {
>  ret = AVERROR(ENOMEM);
>  goto err;
> @@ -640,7 +641,7 @@ static int libsrt_open(URLContext *h, const char *uri, 
> int flags)
>  }
>  if (av_find_info_tag(buf, sizeof(buf), "smoother", p)) {
>  av_freep(>smoother);
> -s->smoother = av_strdup(buf);
> +s->smoother = ff_urldecode(buf, 0);
>  if(!s->smoother) {
>  ret = AVERROR(ENOMEM);
>  goto err;
> -- 
> 2.41.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 3/3] avcodec/jpeg2000htdec: Check m

[Pierre-Anthony Lemieux]

On Sun, Aug 6, 2023 at 9:28 AM Pierre-Anthony Lemieux  wrote:
>
> On Sat, Aug 5, 2023 at 9:30 AM Michael Niedermayer
>  wrote:
> >
> > On Fri, Aug 04, 2023 at 06:19:46PM -0700, Pierre-Anthony Lemieux wrote:
> > > On Tue, Aug 1, 2023 at 5:02 PM Michael Niedermayer
> > >  wrote:
> > > >
> > > > This also fixes assertion failures
> > > >
> > > > Fixes: shift exponent 95 is too large for 64-bit type 'unsigned long 
> > > > long'
> > > > Fixes: 
> > > > 58299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5828618092937216
> > > >
> > > > Found-by: continuous fuzzing process 
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/jpeg2000htdec.c | 22 --
> > > >  1 file changed, 20 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> > > > index 3985783f3a..ae2ee6d6ee 100644
> > > > --- a/libavcodec/jpeg2000htdec.c
> > > > +++ b/libavcodec/jpeg2000htdec.c
> > > > @@ -689,6 +689,10 @@ static int 
> > > > jpeg2000_decode_ht_cleanup_segment(const Jpeg2000DecoderContext *s,
> > > >  for (int i = 0; i < 4; i++) {
> > > >  m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] - 
> > > > ((emb_pat_k[J2K_Q1] >> i) & 1);
> > > >  m[J2K_Q2][i] = sigma_n[4 * q2 + i] * U[J2K_Q2] - 
> > > > ((emb_pat_k[J2K_Q2] >> i) & 1);
> > > > +if (m[J2K_Q1][i] > 63 || m[J2K_Q2][i] > 63) {
> > >
> > > AFAIK, m[i], which is m_n in the standard, can never be larger than
> > > the sample bit depth (including the sign bit, if any). Is it worth
> > > comparing it to a value more precise than 63?
> >
> > probably, yes
> > I think you know the spec better than i do, so you can probably pick
> > the tightest bound quicker ...
> > can you submit a patch doing that ?
>
> I plan to do so before week's end.

https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230810234856.2636-1-...@sandflow.com/

>
> >
> > thx
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > The greatest way to live with honor in this world is to be what we pretend
> > to be. -- Socrates
> > ___
> > 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".

[FFmpeg-devel] [PATCH v1] avcodec/jpeg2000htdec: check if block decoding will exceed internal precision

[pal]

From: Pierre-Anthony Lemieux 

Intended to replace 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230802000135.26482-3-mich...@niedermayer.cc/
with a more accurate block decoding magnitude bound.

---
 libavcodec/jpeg2000htdec.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
index 2c4cea5dd9..713dba17e3 100644
--- a/libavcodec/jpeg2000htdec.c
+++ b/libavcodec/jpeg2000htdec.c
@@ -572,6 +572,14 @@ static int jpeg2000_decode_ht_cleanup_segment(const 
Jpeg2000DecoderContext *s,
 
 const uint8_t *vlc_buf = Dcup + Pcup;
 
+/*
+ * Bound on the recision needed to process the codeblock. The number of
+ * decoded bit planes is equal to at most cblk->zbp + 2 since S_blk = P if
+ * there are no placeholder passes or HT Sets and P = cblk->zbp. See Rec.
+ * ITU-T T.814, 7.6.
+ */
+int maxbp = cblk->zbp + 2;
+
 /* convert to raster-scan */
 const uint16_t is_border_x = width % 2;
 const uint16_t is_border_y = height % 2;
@@ -590,6 +598,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const 
Jpeg2000DecoderContext *s,
 goto free;
 }
 
+/* do we have enough precision, assuming a 32-bit decoding path */
+if (maxbp >= 32)
+return AVERROR_INVALIDDATA;
+
 sigma = sigma_n;
 mu = mu_n;
 
@@ -676,6 +688,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const 
Jpeg2000DecoderContext *s,
 }
 U[J2K_Q1] = kappa[J2K_Q1] + u[J2K_Q1];
 U[J2K_Q2] = kappa[J2K_Q2] + u[J2K_Q2];
+if (U[J2K_Q1] > maxbp || U[J2K_Q2] > maxbp) {
+ret = AVERROR_INVALIDDATA;
+goto free;
+}
 
 for (int i = 0; i < 4; i++) {
 m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] - 
((emb_pat_k[J2K_Q1] >> i) & 1);
@@ -713,6 +729,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const 
Jpeg2000DecoderContext *s,
 }
 
 U[J2K_Q1] = kappa[J2K_Q1] + u[J2K_Q1];
+if (U[J2K_Q1] > maxbp) {
+ret = AVERROR_INVALIDDATA;
+goto free;
+}
 
 for (int i = 0; i < 4; i++)
 m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] - 
((emb_pat_k[J2K_Q1] >> i) & 1);
@@ -842,6 +862,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const 
Jpeg2000DecoderContext *s,
 
 U[J2K_Q1] = kappa[J2K_Q1] + u[J2K_Q1];
 U[J2K_Q2] = kappa[J2K_Q2] + u[J2K_Q2];
+if (U[J2K_Q1] > maxbp || U[J2K_Q2] > maxbp) {
+ret = AVERROR_INVALIDDATA;
+goto free;
+}
 
 for (int i = 0; i < 4; i++) {
 m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] - 
((emb_pat_k[J2K_Q1] >> i) & 1);
@@ -910,6 +934,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const 
Jpeg2000DecoderContext *s,
 kappa[J2K_Q1] = FFMAX(1, gamma[J2K_Q1] * (max_e[J2K_Q1] - 1));
 
 U[J2K_Q1] = kappa[J2K_Q1] + u[J2K_Q1];
+if (U[J2K_Q1] > maxbp) {
+ret = AVERROR_INVALIDDATA;
+goto free;
+}
 
 for (int i = 0; i < 4; i++)
 m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] - 
((emb_pat_k[J2K_Q1] >> i) & 1);
@@ -1238,8 +1266,10 @@ ff_jpeg2000_decode_htj2k(const Jpeg2000DecoderContext 
*s, Jpeg2000CodingStyle *c
 }
 if ((ret = jpeg2000_decode_ht_cleanup_segment(s, cblk, t1, _state, 
, ,
   _sgn, Dcup, Lcup, Pcup, pLSB, 
width,
-  height, sample_buf, block_states)) < 
0)
+  height, sample_buf, block_states)) < 
0) {
+av_log(s->avctx, AV_LOG_ERROR, "Bad HT cleanup segment\n");
 goto free;
+}
 
 if (cblk->npasses > 1)
 jpeg2000_decode_sigprop_segment(cblk, width, height, Dref, Lref,
-- 
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".

Re: [FFmpeg-devel] [PATCH 01/12] avradio/avformat/sdrdemux: Move agc_gain into local variable

[Paul B Mahol]

On Thu, Aug 10, 2023 at 11:03 PM Michael Niedermayer 
wrote:

> Hi Paul
>
> also CC-ing jb as he seemed interrested in teh subject
>
> On Mon, Jul 31, 2023 at 12:26:50AM +0200, Paul B Mahol wrote:
> > NAK to whole set.
>
> I suggest you lift that NAK.
>

NAK is here to stay forever, until:

All SDR related work/patches/files/posts are moved out FFmpeg's
FATE/mailing lists/Twitter.



> If you do i would apply this set of bugfixes and after that
> look into, if its possible to factorize the SDR code out.
> I first would do so within the same lib but once its more
> seperated, maybe we can seperate the SDR code and move it
> into a seperate libavradio leaving the input device/demuxer
> as a user of that lib.
> That would be a seperate lib and API used by a module
> in libavdevice/libavformat as it was suggestes by jb
>
> I dont know how well that refactorization would work out. I may
> have looked at this from the wrong side
> but as long as you block this patchset the code is stuck in
> libavformat and libavdevice
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Into a blind darkness they enter who follow after the Ignorance,
> they as if into a greater darkness enter who devote themselves
> to the Knowledge alone. -- Isha Upanishad
> ___
> 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 01/12] avradio/avformat/sdrdemux: Move agc_gain into local variable

[Michael Niedermayer]

Hi Paul

also CC-ing jb as he seemed interrested in teh subject

On Mon, Jul 31, 2023 at 12:26:50AM +0200, Paul B Mahol wrote:
> NAK to whole set.

I suggest you lift that NAK.
If you do i would apply this set of bugfixes and after that
look into, if its possible to factorize the SDR code out.
I first would do so within the same lib but once its more
seperated, maybe we can seperate the SDR code and move it
into a seperate libavradio leaving the input device/demuxer
as a user of that lib.
That would be a seperate lib and API used by a module
in libavdevice/libavformat as it was suggestes by jb

I dont know how well that refactorization would work out. I may
have looked at this from the wrong side
but as long as you block this patchset the code is stuck in
libavformat and libavdevice

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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] What is FFmpeg and what should it be

[Tomas Härdin]

tor 2023-08-10 klockan 14:39 +0200 skrev Nicolas George:
> If a sponsor tried to leverage their sponsoring to dictate the
> direction
> of the project, threatening to withhold it unless they get their way,
> then we should realize that sponsor is a dangerous asshole and sever
> all
> ties with them immediately.

This sure sounds familiar. And I'm not talking about Remlab Tmi.

/Tomas
___
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] examples/transcode: flush decoder on EOF

[Zhao Zhili]

From: Zhao Zhili 

Signed-off-by: Zhao Zhili 
---
 doc/examples/transcode.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/doc/examples/transcode.c b/doc/examples/transcode.c
index 305181663c..ed6ac9fa03 100644
--- a/doc/examples/transcode.c
+++ b/doc/examples/transcode.c
@@ -585,11 +585,38 @@ int main(int argc, char **argv)
 av_packet_unref(packet);
 }
 
-/* flush filters and encoders */
+/* flush decoders, filters and encoders */
 for (i = 0; i < ifmt_ctx->nb_streams; i++) {
-/* flush filter */
+StreamContext *stream;
+
 if (!filter_ctx[i].filter_graph)
 continue;
+
+stream = _ctx[i];
+
+av_log(NULL, AV_LOG_INFO, "Flushing stream %u decoder\n", i);
+
+/* flush decoder */
+ret = avcodec_send_packet(stream->dec_ctx, NULL);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Flushing decoding failed\n");
+goto end;
+}
+
+while (ret >= 0) {
+ret = avcodec_receive_frame(stream->dec_ctx, stream->dec_frame);
+if (ret == AVERROR_EOF)
+break;
+else if (ret < 0)
+goto end;
+
+stream->dec_frame->pts = stream->dec_frame->best_effort_timestamp;
+ret = filter_encode_write_frame(stream->dec_frame, i);
+if (ret < 0)
+goto end;
+}
+
+/* flush filter */
 ret = filter_encode_write_frame(NULL, i);
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Flushing filter failed\n");
-- 
2.34.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] new audio filter and misc improvements

[Paul B Mahol]

On Thu, Aug 10, 2023 at 5:13 PM Michael Niedermayer 
wrote:

> On Thu, Aug 10, 2023 at 12:10:49PM +0200, Paul B Mahol wrote:
> > On Thu, Aug 10, 2023 at 11:48 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Wed, Aug 09, 2023 at 11:36:16PM +0200, Paul B Mahol wrote:
> > > > Patches attached.
> > >
> > > >  af_adeclick.c |7 ---
> > > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > > b19bd0c3f05d5ebce92f7500dab61bd85d9b3661
> > > 0003-avfilter-af_adeclick-do-not-output-pointless-message.patch
> > > > From 2d8c330f543397642fa1afe0a01a67155008d4e1 Mon Sep 17 00:00:00
> 2001
> > > > From: Paul B Mahol 
> > > > Date: Wed, 9 Aug 2023 21:53:04 +0200
> > > > Subject: [PATCH 3/3] avfilter/af_adeclick: do not output pointless
> > > message
> > > >
> > > > Signed-off-by: Paul B Mahol 
> > > > ---
> > > >  libavfilter/af_adeclick.c | 7 ---
> > > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > [...]
> > >
> > > >  af_adeclick.c |  136
> > > --
> > > >  1 file changed, 67 insertions(+), 69 deletions(-)
> > > > cfc7bc440f2f408f8570501f3afb2de235860221
> > > 0002-avfilter-af_adeclick-refactor-and-cleanup.patch
> > > > From 0a6de9b1482ece4402b1c7274501b43e43f5f56a Mon Sep 17 00:00:00
> 2001
> > > > From: Paul B Mahol 
> > > > Date: Wed, 9 Aug 2023 21:49:19 +0200
> > > > Subject: [PATCH 2/3] avfilter/af_adeclick: refactor and cleanup
> > > >
> > > > Signed-off-by: Paul B Mahol 
> > > > ---
> > > >  libavfilter/af_adeclick.c | 136
> +++---
> > > >  1 file changed, 67 insertions(+), 69 deletions(-)
> > >
> > > [...]
> > >
> > > >  doc/filters.texi  |   51 +
> > > >  libavfilter/Makefile  |1
> > > >  libavfilter/af_adeclick.c |   91
> > > +++---
> > > >  libavfilter/allfilters.c  |1
> > > >  4 files changed, 140 insertions(+), 4 deletions(-)
> > > > 61d03514ba9fa85d1ec308ce37037a0c07ad9a7f
> > > 0001-avfilter-add-adesurge-filter.patch
> > > > From af565f57f733af327edc1e1724e31a3c5f1fe44f Mon Sep 17 00:00:00
> 2001
> > > > From: Paul B Mahol 
> > > > Date: Wed, 9 Aug 2023 18:21:25 +0200
> > > > Subject: [PATCH 1/3] avfilter: add adesurge filter
> > > >
> > > > Signed-off-by: Paul B Mahol 
> > > > ---
> > > >  doc/filters.texi  | 51 ++
> > > >  libavfilter/Makefile  |  1 +
> > > >  libavfilter/af_adeclick.c | 91
> +--
> > > >  libavfilter/allfilters.c  |  1 +
> > > >  4 files changed, 140 insertions(+), 4 deletions(-)
> > >
> > > It seems you forgot adding fate tests, please make sure fate tests are
> > > added
> > > when this or a future variant is applied
> > >
> >
> > Sorry, Sir!,
> >
> > The filter modules are not mention for fate testing,
>
> doc/developer.texi:
>  807 @item
>  808 Consider adding a regression test for your code. All new modules
>  809 should be covered by tests. That includes demuxers, muxers, decoders,
> encoders
>  810 filters, bitstream filters, parsers. If its not possible to do that,
> add
>  811 an explanation why to your patchset, its ok to not test if theres a
> reason.
>
> so yes, filters should be tested too
>
>
> > and for obvious
> > reasons like usage of non-integer math.
>
> A wide range of non integer modules are tested.
>

Not possible for non-trivial stuff.

Please keep ignoring my patches as you did all these years.

And your little SDR adventure inside FFmpeg will not make situation any
better.



>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you fake or manipulate statistics in a paper in physics you will never
> get a job again.
> If you fake or manipulate statistics in a paper in medicin you will get
> a job for life at the pharma industry.
> ___
> 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".

[FFmpeg-devel] [PATCH] avformat/libsrt: Decode URL parameter strings

[Armin Hasitzka]

Hi again,

we found this the other day when using a stream ID containing "%2F",
expecting this to be resolved to "/". While "%2F" could obviously be sent
decoded, "&" (decoded) would currently end the value and not be used, "+"
(decoded) would be overwritten with " ", and "=" (decoded) could cause
entirely unexpected outcomes (albeit all these characters being allowed by
SRT for various string inputs).

As for changing `av_strndup` to `ff_urldecode` (which removes a length
check); I don't think that this particular length check added any
protection (`av_find_info_tag` adds a trailing `\0` if found). This
thinking is also evident at the two other places where `ff_urldecode`
replaced `av_strdup`.

It would be amazing if we could get this merged upstream :)

Best
Armin


0001-avformat-libsrt-Decode-URL-parameter-strings.patch
Description: Binary data
___
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 v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Kieran Kunhya]

Sent from my mobile device

On Thu, 10 Aug 2023, 11:12 Devin Heitmueller, <
devin.heitmuel...@ltnglobal.com> wrote:

> Hi Kieran,
>
> On Thu, Aug 10, 2023 at 9:09 AM Kieran Kunhya  wrote:
> > You're exposing this incorrect information as public API, two wrongs
> don't make a right.
>
> The information is already exposed via the public API, in the form of
> pkt->pts.  The fact that I've exposed that same value as side data as
> well doesn't really change that situation.
>

The whole exposing of SI as if it were PES is a giant hack in general, SI
doesn't have a PTS.

Kieran
___
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] avcodec/mv30: Check the input length before allocation

[Paul B Mahol]

On Thu, Aug 10, 2023 at 5:46 PM Michael Niedermayer 
wrote:

> On Thu, Aug 10, 2023 at 12:12:51PM +0200, Paul B Mahol wrote:
> > On Thu, Aug 10, 2023 at 11:34 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Wed, Aug 09, 2023 at 11:20:43PM +0200, Paul B Mahol wrote:
> > > > On Wed, Aug 9, 2023 at 9:30 PM Michael Niedermayer <
> > > mich...@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > Hi Paul
> > > > >
> > > > > On Wed, Aug 09, 2023 at 08:53:03PM +0200, Paul B Mahol wrote:
> > > > > > This is not correct, and please stop writing such patches.
> Thanks.
> > > > >
> > > > > If there is a problem in the bugfix, please explain what the
> problem
> > > is.
> > > > > If you do not like the specific fix, you can fix it differently
> too or
> > > > > tell me what you prefer.
> > > > > Simply saying "no" with no explanation repeatedly is rude
> > > > >
> > > >
> > > > Patch breaks valid files.
> > >
> > > Does the patch break files you create intentionally or files
> > > pre-existing ?
> > > The check can fail if 2 data segments overlap, one can craft
> > > a file with that. The previous patches are implemented differently
> > > and dont have that behavior, you rejected them too and at the time
> > > you did call them "hacky" and did not mention that they break anything
> > > and also ignored all further questions
> > >
> > > I just implemented this one differently as the other way was rejected
> > > by you with no comment
> > >
> > > Also please provide the files this breaks so the issue can be
> > > fixed
> > >
> > >
> > Why not same thing for AV1 codec?
> > Just reduce max resolutions for mv30 to 32x32 and be done.
>
> Limiting the resolution to max 32x32 would break real samples
> for example V-codecs/mv30.avi
>
> if you suggest to limit it only for the fuzzer, well, that would not
> fix the timeout outside the fuzzer.
> For some decoders limiting the resolution in the fuzzer is the only
> practical
> option. But for mv30 this timeout really occurs because the input is not
> checked/validated.
>

But mv30 bitstream is not so trivial and can not be checked that easily
with your patches.

Also whole fuzzing idea of your work is flawed.


>
> thx
>
> [...]
> --
> 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 v2] avcodec/mv30: Check the input length before allocation

[Michael Niedermayer]

On Thu, Aug 10, 2023 at 12:12:51PM +0200, Paul B Mahol wrote:
> On Thu, Aug 10, 2023 at 11:34 AM Michael Niedermayer 
> wrote:
> 
> > On Wed, Aug 09, 2023 at 11:20:43PM +0200, Paul B Mahol wrote:
> > > On Wed, Aug 9, 2023 at 9:30 PM Michael Niedermayer <
> > mich...@niedermayer.cc>
> > > wrote:
> > >
> > > > Hi Paul
> > > >
> > > > On Wed, Aug 09, 2023 at 08:53:03PM +0200, Paul B Mahol wrote:
> > > > > This is not correct, and please stop writing such patches. Thanks.
> > > >
> > > > If there is a problem in the bugfix, please explain what the problem
> > is.
> > > > If you do not like the specific fix, you can fix it differently too or
> > > > tell me what you prefer.
> > > > Simply saying "no" with no explanation repeatedly is rude
> > > >
> > >
> > > Patch breaks valid files.
> >
> > Does the patch break files you create intentionally or files
> > pre-existing ?
> > The check can fail if 2 data segments overlap, one can craft
> > a file with that. The previous patches are implemented differently
> > and dont have that behavior, you rejected them too and at the time
> > you did call them "hacky" and did not mention that they break anything
> > and also ignored all further questions
> >
> > I just implemented this one differently as the other way was rejected
> > by you with no comment
> >
> > Also please provide the files this breaks so the issue can be
> > fixed
> >
> >
> Why not same thing for AV1 codec?
> Just reduce max resolutions for mv30 to 32x32 and be done.

Limiting the resolution to max 32x32 would break real samples
for example V-codecs/mv30.avi

if you suggest to limit it only for the fuzzer, well, that would not
fix the timeout outside the fuzzer.
For some decoders limiting the resolution in the fuzzer is the only practical
option. But for mv30 this timeout really occurs because the input is not
checked/validated.

thx

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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] What is FFmpeg and what should it be

[Jean-Baptiste Kempf]

On Thu, 10 Aug 2023, at 14:39, Nicolas George wrote:
>> livelihood, and millions for their computer use" in response to NG's 
>> argument 
>> that FFmpeg should be turned into a fun experimental research project, and 
>> that people who wanted to keep FFmpeg what he calls a "serious open-source 
>> trademark" should just fork.
>
> Not “turned into”, but restored. FFmpeg *was* a fun experimental
> research project, and it was the reason it became so great: developers
> then could try things that were not tried elsewhere, they were free to
> take risks, to make mistakes and fix them.
>
> And the, during the second half of 2000s decade, people like you took
> more and more place, people who demanded absolute stability and rejected
> all risks whatsoever.

You mean, like every project that starts small and gets bigger and reaches 
maturity stage?

> But what you refuse to realize is that it is only an opinion, shared by
> you and a few “people”, backed by zero actual arguments.

The issue here, is that you are in minority about your vision of FFmpeg, as a 
fun and experimental project.
You screaming louder does not change this reality.

If you disagree, just get a vote from all people who have commit access, and 
you will see.

-- 
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] exclude currently unused 0.17% of fate samples from rsync

[Michael Niedermayer]

Several developers where upset, that from the over 1gb of fate samples 2mb are 
only used
by the ffmpeg branch with SDR support in https://git.ffmpeg.org/libavradio

This avoids these samples from being downloaded or synchronized.
It should have no real world effect on anything of course if 0.17% more or
less is downloaded but maybe it makes some people happier.

Signed-off-by: Michael Niedermayer 
---
 configure  | 2 ++
 tests/Makefile | 1 +
 2 files changed, 3 insertions(+)

diff --git a/configure b/configure
index 932998b8d6..f859701ebd 100755
--- a/configure
+++ b/configure
@@ -2384,6 +2384,7 @@ TOOLCHAIN_FEATURES="
 inline_asm_nonlocal_labels
 pragma_deprecated
 rsync_contimeout
+rsync_exclude
 symver_asm_label
 symver_gnu_asm
 vfp_args
@@ -6968,6 +6969,7 @@ disabled makeinfo_html && texi2html --help 2> /dev/null | 
grep -q 'init-file' &&
 perl -v> /dev/null 2>&1 && enable perl  || disable perl
 pod2man --help > /dev/null 2>&1 && enable pod2man   || disable pod2man
 rsync --help 2> /dev/null | grep -q 'contimeout' && enable rsync_contimeout || 
disable rsync_contimeout
+rsync --help 2> /dev/null | grep -q -- '--exclude' && enable rsync_exclude || 
disable rsync_exclude
 xmllint --version  > /dev/null 2>&1 && enable xmllint   || disable xmllint
 
 # check V4L2 codecs available in the API
diff --git a/tests/Makefile b/tests/Makefile
index e09f30a0fc..45db76695e 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -265,6 +265,7 @@ FATE_EXTERN   += $(FATE_EXTERN-yes) 
$(FATE_SAMPLES_FASTSTART)
 FATE += $(FATE-yes)
 
 RSYNC_OPTIONS-$(HAVE_RSYNC_CONTIMEOUT) += --contimeout=60
+RSYNC_OPTIONS-$(HAVE_RSYNC_EXCLUDE)+= --exclude=/sdr/
 RSYNC_OPTIONS = -vrltLW --timeout=60 $(RSYNC_OPTIONS-yes)
 
 $(FATE_FFMPEG) $(FATE_FFMPEG_FFPROBE) $(FATE_SAMPLES_AVCONV) 
$(FATE_SAMPLES_FFMPEG) $(FATE_SAMPLES_FFMPEG_FFPROBE): 
ffmpeg$(PROGSSUF)$(EXESUF)
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] new audio filter and misc improvements

[Michael Niedermayer]

On Thu, Aug 10, 2023 at 12:10:49PM +0200, Paul B Mahol wrote:
> On Thu, Aug 10, 2023 at 11:48 AM Michael Niedermayer 
> wrote:
> 
> > On Wed, Aug 09, 2023 at 11:36:16PM +0200, Paul B Mahol wrote:
> > > Patches attached.
> >
> > >  af_adeclick.c |7 ---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > b19bd0c3f05d5ebce92f7500dab61bd85d9b3661
> > 0003-avfilter-af_adeclick-do-not-output-pointless-message.patch
> > > From 2d8c330f543397642fa1afe0a01a67155008d4e1 Mon Sep 17 00:00:00 2001
> > > From: Paul B Mahol 
> > > Date: Wed, 9 Aug 2023 21:53:04 +0200
> > > Subject: [PATCH 3/3] avfilter/af_adeclick: do not output pointless
> > message
> > >
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  libavfilter/af_adeclick.c | 7 ---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > [...]
> >
> > >  af_adeclick.c |  136
> > --
> > >  1 file changed, 67 insertions(+), 69 deletions(-)
> > > cfc7bc440f2f408f8570501f3afb2de235860221
> > 0002-avfilter-af_adeclick-refactor-and-cleanup.patch
> > > From 0a6de9b1482ece4402b1c7274501b43e43f5f56a Mon Sep 17 00:00:00 2001
> > > From: Paul B Mahol 
> > > Date: Wed, 9 Aug 2023 21:49:19 +0200
> > > Subject: [PATCH 2/3] avfilter/af_adeclick: refactor and cleanup
> > >
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  libavfilter/af_adeclick.c | 136 +++---
> > >  1 file changed, 67 insertions(+), 69 deletions(-)
> >
> > [...]
> >
> > >  doc/filters.texi  |   51 +
> > >  libavfilter/Makefile  |1
> > >  libavfilter/af_adeclick.c |   91
> > +++---
> > >  libavfilter/allfilters.c  |1
> > >  4 files changed, 140 insertions(+), 4 deletions(-)
> > > 61d03514ba9fa85d1ec308ce37037a0c07ad9a7f
> > 0001-avfilter-add-adesurge-filter.patch
> > > From af565f57f733af327edc1e1724e31a3c5f1fe44f Mon Sep 17 00:00:00 2001
> > > From: Paul B Mahol 
> > > Date: Wed, 9 Aug 2023 18:21:25 +0200
> > > Subject: [PATCH 1/3] avfilter: add adesurge filter
> > >
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  doc/filters.texi  | 51 ++
> > >  libavfilter/Makefile  |  1 +
> > >  libavfilter/af_adeclick.c | 91 +--
> > >  libavfilter/allfilters.c  |  1 +
> > >  4 files changed, 140 insertions(+), 4 deletions(-)
> >
> > It seems you forgot adding fate tests, please make sure fate tests are
> > added
> > when this or a future variant is applied
> >
> 
> Sorry, Sir!,
> 
> The filter modules are not mention for fate testing,

doc/developer.texi:
 807 @item
 808 Consider adding a regression test for your code. All new modules
 809 should be covered by tests. That includes demuxers, muxers, decoders, 
encoders
 810 filters, bitstream filters, parsers. If its not possible to do that, add
 811 an explanation why to your patchset, its ok to not test if theres a reason.

so yes, filters should be tested too


> and for obvious
> reasons like usage of non-integer math.

A wide range of non integer modules are tested.

thx

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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 v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Devin Heitmueller]

Hi Kieran,

On Thu, Aug 10, 2023 at 9:09 AM Kieran Kunhya  wrote:
> You're exposing this incorrect information as public API, two wrongs don't 
> make a right.

The information is already exposed via the public API, in the form of
pkt->pts.  The fact that I've exposed that same value as side data as
well doesn't really change that situation.

> I also told the author of the previous code that it was wrong but the patch 
> was forced through on the guise that "professionals won't respect ffmpeg if 
> scte-35 isn't demuxed".

So you're annoyed that seven years ago somebody else submitted some
patch and it got merged over your objection?  And that in that time
nobody (including you) has cared enough to take it upon themselves to
improve the accuracy of the timestamp?

> The fact something isn't used often, doesn't mean it should be implemented 
> badly. You could say that interlaced isn't used much as a total of all the 
> video in the world so we should just not decode it correctly.

I've made no attempt to argue that the accuracy of the timestamp
couldn't be improved.  I would argue that improving it shouldn't be
any sort of prerequisite to merging this patch series though.
Presumably it hasn't happened already because 1) properly implementing
PCR interpolation within the ffmpeg mpegts demux implementation is
difficult, 2) nobody has cared enough to do it, and/or 3) the typical
PCR interval is 40ms so people are happy with it being "close enough"
in the splice immediate case.

> By all means keep your hacks in your forks.

Where is the hack?  My patches are an incremental improvement over
what is already there.  The notion that it makes no attempt to  solve
some orthogonal problem that I'm not really worried about isn't
grounds for rejecting it.

I would be happy to see other developers weigh in, or if Kieran's is
the final word then I would like to see this reviewed by the TC.  I'm
making a genuine effort to improve the support in ffmpeg and it seems
like an artificial barrier is being raised against those efforts.

Devin


Devin

--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] What is FFmpeg and what should it be

[James Almer]

On 8/10/2023 9:39 AM, Nicolas George wrote:

Rémi Denis-Courmont (12023-08-08):

No. You are taking for granted that SDR belongs in FFmpeg in the first place,
and that's exactly what people disagree with.


And you are taking for granted that it does not belongs in FFmpeg.

But what you refuse to realize is that it is only an opinion, shared by
you and a few “people”, backed by zero actual arguments.

As such, your opinion is worthy of very little consideration, a lot much
less than the opposition opinion that is actually backed by the
enthusiasm of users.


This is absolutely unacceptable, Nicolas.
___
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] What is FFmpeg and what should it be

[Vittorio Giovara]

On Thu, Aug 10, 2023 at 2:39 PM Nicolas George  wrote:

> > No. You are taking for granted that SDR belongs in FFmpeg in the first
> place,
> > and that's exactly what people disagree with.
>
> And you are taking for granted that it does not belongs in FFmpeg.
>
> But what you refuse to realize is that it is only an opinion, shared by
> you and a few “people”, backed by zero actual arguments.
>
> As such, your opinion is worthy of very little consideration, a lot much
> less than the opposition opinion that is actually backed by the
> enthusiasm of users.
>

this is not the way to talk to a fellow developer with plenty of open
source contributions in this and many other repositories
you need to consider that not everybody has the energy or will to write
lengthy paragraphs that just reiterate the same points and do not move the
needle one way or another - in other words, your argument is not the
correct one just because it's the longest
and please try writing with more respect, the "people" (leaving air quotes
verbatim) you refer to is basically the entire community, versus you and
Michael
-- 
Vittorio
___
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 v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Kieran Kunhya]

On Thu, 10 Aug 2023, 08:59 Devin Heitmueller, <
devin.heitmuel...@ltnglobal.com> wrote:

> On Thu, Aug 10, 2023 at 8:48 AM Kieran Kunhya  wrote:
> >
> >
> >
> > On Thu, 10 Aug 2023 at 08:41, Kieran Kunhya  wrote:
> >>
> >> On Thu, 10 Aug 2023 at 08:20, Devin Heitmueller <
> devin.heitmuel...@ltnglobal.com> wrote:
> >>>
> >>> On Thu, Aug 10, 2023 at 8:13 AM Kieran Kunhya  wrote:
> >>> > The (closest?) video PTS is even worse than the last PCR because the
> VBV means the closest PTS can be quite far from the interpolated PCR.
> >>>
> >>> It's arguments like that which prompted me to explicitly exclude such
> >>> a patch from the series.  It's a discussion to be had, but not
> >>> relevant for this patch series (which makes no effort to change the
> >>> logic for how the timestamp is determined).
> >>>
> >>> Wait until such a patch is submitted, and then we can debate at length
> >>> the ambiguity in the specification and what the best approach is.
> >>
> >>
> >> There is zero ambiguity in the specification.
> >
> >
> > Like any other form of SI in MPEG-TS the timestamp (although there is
> actually no such thing) is "now", which by definition is the interpolated
> PCR.
> > Taking a video frame PTS is incorrect.
> >
> > What's the point of submitting patches like this exposing things in the
> public API that you know to be wrong?
>
> Again, this patch series makes no attempt to address the problem you
> are complaining about.  It brings the situation from "completely
> doesn't work" to "works fine the majority of the time except for the
> splice immediate case where the timestamp may not be as accurate as it
> could be".  And let's be fair, splice immediate is both an uncommon
> use case in the industry and nobody doing a splice immediate expects
> it to be frame accurate (as it's typically initiated by a human during
> live programming).
>
> I'm happy to have this discussion, but it doesn't have any bearing on
> whether this patch series should be accepted.  Let's not throw out the
> baby with the bathwater.
>

You're exposing this incorrect information as public API, two wrongs don't
make a right.

I also told the author of the previous code that it was wrong but the patch
was forced through on the guise that "professionals won't respect ffmpeg if
scte-35 isn't demuxed".

The fact something isn't used often, doesn't mean it should be implemented
badly. You could say that interlaced isn't used much as a total of all the
video in the world so we should just not decode it correctly.

By all means keep your hacks in your forks.

Kieran

>
___
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 v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Devin Heitmueller]

On Thu, Aug 10, 2023 at 8:48 AM Kieran Kunhya  wrote:
>
>
>
> On Thu, 10 Aug 2023 at 08:41, Kieran Kunhya  wrote:
>>
>> On Thu, 10 Aug 2023 at 08:20, Devin Heitmueller 
>>  wrote:
>>>
>>> On Thu, Aug 10, 2023 at 8:13 AM Kieran Kunhya  wrote:
>>> > The (closest?) video PTS is even worse than the last PCR because the VBV 
>>> > means the closest PTS can be quite far from the interpolated PCR.
>>>
>>> It's arguments like that which prompted me to explicitly exclude such
>>> a patch from the series.  It's a discussion to be had, but not
>>> relevant for this patch series (which makes no effort to change the
>>> logic for how the timestamp is determined).
>>>
>>> Wait until such a patch is submitted, and then we can debate at length
>>> the ambiguity in the specification and what the best approach is.
>>
>>
>> There is zero ambiguity in the specification.
>
>
> Like any other form of SI in MPEG-TS the timestamp (although there is 
> actually no such thing) is "now", which by definition is the interpolated PCR.
> Taking a video frame PTS is incorrect.
>
> What's the point of submitting patches like this exposing things in the 
> public API that you know to be wrong?

Again, this patch series makes no attempt to address the problem you
are complaining about.  It brings the situation from "completely
doesn't work" to "works fine the majority of the time except for the
splice immediate case where the timestamp may not be as accurate as it
could be".  And let's be fair, splice immediate is both an uncommon
use case in the industry and nobody doing a splice immediate expects
it to be frame accurate (as it's typically initiated by a human during
live programming).

I'm happy to have this discussion, but it doesn't have any bearing on
whether this patch series should be accepted.  Let's not throw out the
baby with the bathwater.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Kieran Kunhya]

On Thu, 10 Aug 2023 at 08:41, Kieran Kunhya  wrote:

> On Thu, 10 Aug 2023 at 08:20, Devin Heitmueller <
> devin.heitmuel...@ltnglobal.com> wrote:
>
>> On Thu, Aug 10, 2023 at 8:13 AM Kieran Kunhya  wrote:
>> > The (closest?) video PTS is even worse than the last PCR because the
>> VBV means the closest PTS can be quite far from the interpolated PCR.
>>
>> It's arguments like that which prompted me to explicitly exclude such
>> a patch from the series.  It's a discussion to be had, but not
>> relevant for this patch series (which makes no effort to change the
>> logic for how the timestamp is determined).
>>
>> Wait until such a patch is submitted, and then we can debate at length
>> the ambiguity in the specification and what the best approach is.
>>
>
> There is zero ambiguity in the specification.
>

Like any other form of SI in MPEG-TS the timestamp (although there is
actually no such thing) is "now", which by definition is the interpolated
PCR.
Taking a video frame PTS is incorrect.

What's the point of submitting patches like this exposing things in the
public API that you know to be wrong?

Kieran
___
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 v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Kieran Kunhya]

On Thu, 10 Aug 2023 at 08:20, Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:

> On Thu, Aug 10, 2023 at 8:13 AM Kieran Kunhya  wrote:
> > The (closest?) video PTS is even worse than the last PCR because the VBV
> means the closest PTS can be quite far from the interpolated PCR.
>
> It's arguments like that which prompted me to explicitly exclude such
> a patch from the series.  It's a discussion to be had, but not
> relevant for this patch series (which makes no effort to change the
> logic for how the timestamp is determined).
>
> Wait until such a patch is submitted, and then we can debate at length
> the ambiguity in the specification and what the best approach is.
>

There is zero ambiguity in the specification.

Kieran
___
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] What is FFmpeg and what should it be

[Nicolas George]

Rémi Denis-Courmont (12023-08-08):
> I have made some preposterous statements in my dark past, but I am pretty 
> sure 
> that I didn't make any statement to that effect, no.
> 
> I did assert that there "are dozens of people, ostensibly including [you], 
> that depend on FFmpeg being ""Serious OpenSource TM"" in some way, for their
> livelihood, and millions for their computer use" in response to NG's argument 
> that FFmpeg should be turned into a fun experimental research project, and 
> that people who wanted to keep FFmpeg what he calls a "serious open-source 
> trademark" should just fork.

Not “turned into”, but restored. FFmpeg *was* a fun experimental
research project, and it was the reason it became so great: developers
then could try things that were not tried elsewhere, they were free to
take risks, to make mistakes and fix them.

And the, during the second half of 2000s decade, people like you took
more and more place, people who demanded absolute stability and rejected
all risks whatsoever. They started giving shit to Michael, then project
leader, trying to force him and everybody else to behave, according to
their own standards. They wasted the time of one of the most skilled
hackers in the field of multimedia having him perform tasks a few
baseline technicians could do.

And when it did not go as fast as they wanted, they staged a coup, with
all the terrible consequences we know.

Let me state it plain and clear:

The fact that people and companies choose to depend on FFmpeg for their
livelihood is their own problem, and their own only, it does not create
ANY OBLIGATION WHATSOEVER for FFmpeg.

It is even true for sponsors. They can gift FFmpeg hardware or money or
hosting, they can hope that FFmpeg will progress to be even more useful
to them, but FFmpeg has NO OBLIGATION WHATSOEVER to honor that hope.
(Except for tit-for-tat programs with contractual rules, like GSoC.)

If a sponsor tried to leverage their sponsoring to dictate the direction
of the project, threatening to withhold it unless they get their way,
then we should realize that sponsor is a dangerous asshole and sever all
ties with them immediately.

> No. You are taking for granted that SDR belongs in FFmpeg in the first place, 
> and that's exactly what people disagree with.

And you are taking for granted that it does not belongs in FFmpeg.

But what you refuse to realize is that it is only an opinion, shared by
you and a few “people”, backed by zero actual arguments.

As such, your opinion is worthy of very little consideration, a lot much
less than the opposition opinion that is actually backed by the
enthusiasm of users.

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Devin Heitmueller]

On Thu, Aug 10, 2023 at 8:13 AM Kieran Kunhya  wrote:
> The (closest?) video PTS is even worse than the last PCR because the VBV 
> means the closest PTS can be quite far from the interpolated PCR.

It's arguments like that which prompted me to explicitly exclude such
a patch from the series.  It's a discussion to be had, but not
relevant for this patch series (which makes no effort to change the
logic for how the timestamp is determined).

Wait until such a patch is submitted, and then we can debate at length
the ambiguity in the specification and what the best approach is.

Thanks,

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/4] mpegts: Stash original PTS for SCTE-35 sections for processing later

[Kieran Kunhya]

On Wed, 9 Aug 2023, 12:37 Devin Heitmueller, <
devin.heitmuel...@ltnglobal.com> wrote:

> eI have a separate patch which better tracks the
> video PTS and uses that as the basis for specifying the SCTE-35
> timestamp value (and that's what I use in production).  I will be
> looking to submit that as a separate patch, but didn't want to muddy
> the waters by introducing it in this patch series (where I'm not
> trying to tackle that problem).
>

The (closest?) video PTS is even worse than the last PCR because the VBV
means the closest PTS can be quite far from the interpolated PCR.

Kieran

>
___
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] avcodec/mv30: Check the input length before allocation

[Paul B Mahol]

On Thu, Aug 10, 2023 at 11:34 AM Michael Niedermayer 
wrote:

> On Wed, Aug 09, 2023 at 11:20:43PM +0200, Paul B Mahol wrote:
> > On Wed, Aug 9, 2023 at 9:30 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > Hi Paul
> > >
> > > On Wed, Aug 09, 2023 at 08:53:03PM +0200, Paul B Mahol wrote:
> > > > This is not correct, and please stop writing such patches. Thanks.
> > >
> > > If there is a problem in the bugfix, please explain what the problem
> is.
> > > If you do not like the specific fix, you can fix it differently too or
> > > tell me what you prefer.
> > > Simply saying "no" with no explanation repeatedly is rude
> > >
> >
> > Patch breaks valid files.
>
> Does the patch break files you create intentionally or files
> pre-existing ?
> The check can fail if 2 data segments overlap, one can craft
> a file with that. The previous patches are implemented differently
> and dont have that behavior, you rejected them too and at the time
> you did call them "hacky" and did not mention that they break anything
> and also ignored all further questions
>
> I just implemented this one differently as the other way was rejected
> by you with no comment
>
> Also please provide the files this breaks so the issue can be
> fixed
>
>
Why not same thing for AV1 codec?
Just reduce max resolutions for mv30 to 32x32 and be done.



> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
> ___
> 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] new audio filter and misc improvements

[Paul B Mahol]

On Thu, Aug 10, 2023 at 11:48 AM Michael Niedermayer 
wrote:

> On Wed, Aug 09, 2023 at 11:36:16PM +0200, Paul B Mahol wrote:
> > Patches attached.
>
> >  af_adeclick.c |7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > b19bd0c3f05d5ebce92f7500dab61bd85d9b3661
> 0003-avfilter-af_adeclick-do-not-output-pointless-message.patch
> > From 2d8c330f543397642fa1afe0a01a67155008d4e1 Mon Sep 17 00:00:00 2001
> > From: Paul B Mahol 
> > Date: Wed, 9 Aug 2023 21:53:04 +0200
> > Subject: [PATCH 3/3] avfilter/af_adeclick: do not output pointless
> message
> >
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavfilter/af_adeclick.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> [...]
>
> >  af_adeclick.c |  136
> --
> >  1 file changed, 67 insertions(+), 69 deletions(-)
> > cfc7bc440f2f408f8570501f3afb2de235860221
> 0002-avfilter-af_adeclick-refactor-and-cleanup.patch
> > From 0a6de9b1482ece4402b1c7274501b43e43f5f56a Mon Sep 17 00:00:00 2001
> > From: Paul B Mahol 
> > Date: Wed, 9 Aug 2023 21:49:19 +0200
> > Subject: [PATCH 2/3] avfilter/af_adeclick: refactor and cleanup
> >
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavfilter/af_adeclick.c | 136 +++---
> >  1 file changed, 67 insertions(+), 69 deletions(-)
>
> [...]
>
> >  doc/filters.texi  |   51 +
> >  libavfilter/Makefile  |1
> >  libavfilter/af_adeclick.c |   91
> +++---
> >  libavfilter/allfilters.c  |1
> >  4 files changed, 140 insertions(+), 4 deletions(-)
> > 61d03514ba9fa85d1ec308ce37037a0c07ad9a7f
> 0001-avfilter-add-adesurge-filter.patch
> > From af565f57f733af327edc1e1724e31a3c5f1fe44f Mon Sep 17 00:00:00 2001
> > From: Paul B Mahol 
> > Date: Wed, 9 Aug 2023 18:21:25 +0200
> > Subject: [PATCH 1/3] avfilter: add adesurge filter
> >
> > Signed-off-by: Paul B Mahol 
> > ---
> >  doc/filters.texi  | 51 ++
> >  libavfilter/Makefile  |  1 +
> >  libavfilter/af_adeclick.c | 91 +--
> >  libavfilter/allfilters.c  |  1 +
> >  4 files changed, 140 insertions(+), 4 deletions(-)
>
> It seems you forgot adding fate tests, please make sure fate tests are
> added
> when this or a future variant is applied
>

Sorry, Sir!,

The filter modules are not mention for fate testing, and for obvious
reasons like usage of non-integer math.


>
> thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> than the original author, trying to rewrite it will not make it better.
> ___
> 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] new audio filter and misc improvements

[Michael Niedermayer]

On Wed, Aug 09, 2023 at 11:36:16PM +0200, Paul B Mahol wrote:
> Patches attached.

>  af_adeclick.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> b19bd0c3f05d5ebce92f7500dab61bd85d9b3661  
> 0003-avfilter-af_adeclick-do-not-output-pointless-message.patch
> From 2d8c330f543397642fa1afe0a01a67155008d4e1 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Wed, 9 Aug 2023 21:53:04 +0200
> Subject: [PATCH 3/3] avfilter/af_adeclick: do not output pointless message
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/af_adeclick.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
[...]

>  af_adeclick.c |  136 
> --
>  1 file changed, 67 insertions(+), 69 deletions(-)
> cfc7bc440f2f408f8570501f3afb2de235860221  
> 0002-avfilter-af_adeclick-refactor-and-cleanup.patch
> From 0a6de9b1482ece4402b1c7274501b43e43f5f56a Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Wed, 9 Aug 2023 21:49:19 +0200
> Subject: [PATCH 2/3] avfilter/af_adeclick: refactor and cleanup
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/af_adeclick.c | 136 +++---
>  1 file changed, 67 insertions(+), 69 deletions(-)

[...]

>  doc/filters.texi  |   51 +
>  libavfilter/Makefile  |1 
>  libavfilter/af_adeclick.c |   91 
> +++---
>  libavfilter/allfilters.c  |1 
>  4 files changed, 140 insertions(+), 4 deletions(-)
> 61d03514ba9fa85d1ec308ce37037a0c07ad9a7f  
> 0001-avfilter-add-adesurge-filter.patch
> From af565f57f733af327edc1e1724e31a3c5f1fe44f Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Wed, 9 Aug 2023 18:21:25 +0200
> Subject: [PATCH 1/3] avfilter: add adesurge filter
> 
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  | 51 ++
>  libavfilter/Makefile  |  1 +
>  libavfilter/af_adeclick.c | 91 +--
>  libavfilter/allfilters.c  |  1 +
>  4 files changed, 140 insertions(+), 4 deletions(-)

It seems you forgot adding fate tests, please make sure fate tests are added
when this or a future variant is applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec/mv30: Check the input length before allocation

[Michael Niedermayer]

On Wed, Aug 09, 2023 at 11:20:43PM +0200, Paul B Mahol wrote:
> On Wed, Aug 9, 2023 at 9:30 PM Michael Niedermayer 
> wrote:
> 
> > Hi Paul
> >
> > On Wed, Aug 09, 2023 at 08:53:03PM +0200, Paul B Mahol wrote:
> > > This is not correct, and please stop writing such patches. Thanks.
> >
> > If there is a problem in the bugfix, please explain what the problem is.
> > If you do not like the specific fix, you can fix it differently too or
> > tell me what you prefer.
> > Simply saying "no" with no explanation repeatedly is rude
> >
> 
> Patch breaks valid files.

Does the patch break files you create intentionally or files
pre-existing ?
The check can fail if 2 data segments overlap, one can craft
a file with that. The previous patches are implemented differently
and dont have that behavior, you rejected them too and at the time
you did call them "hacky" and did not mention that they break anything
and also ignored all further questions

I just implemented this one differently as the other way was rejected
by you with no comment

Also please provide the files this breaks so the issue can be
fixed

thx

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

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


signature.asc
Description: 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 v1 1/1] lavc/qsvenc: disable SEI frame before each P-frame

[Xiang, Haihao]

Hi,
How can I disable SEI frame? Is there any other option?

You may use option -scenario  to indicate the scenario for the encoding 
session, but I'm not sure whether your runtime has the optimization for SEI.

Thanks
Haihao



获取 Outlook for iOS

发件人: Xiang, Haihao 
发送时间: Monday, August 7, 2023 10:06:41 AM
收件人: ffmpeg-devel@ffmpeg.org 
抄送: siriu...@hotmail.com 
主题: Re: [FFmpeg-devel] [PATCH v1 1/1] lavc/qsvenc: disable SEI frame before 
each P-frame

On So, 2023-08-06 at 19:54 +0800, Ting Hu wrote:
> From: tinghu3 
>
> In order to save bandwith for video conference application,
> set pic_timing_sei of av_option to disable SEI frames.
> It doesn't take effect.
>
> Signed-off-by: tinghu3 
> ---
>  libavcodec/qsvenc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index df63c182b0..7a5ea5391e 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -937,7 +937,7 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  q->extco.Header.BufferSz  = sizeof(q->extco);
>
>  q->extco.PicTimingSEI = q->pic_timing_sei ?
> -MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_UNKNOWN;
> +MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;

PicTimingSEI and RefPicMarkRep are tristate flags. When a tristate flag is set
to MFX_CODINGOPTION_UNKNOWN(0), the SDK encoder can choose a best configuration
based on the current state and settings. We want to the SDK encoder set
reasonable values for these flags

Thanks
Haihao

>  q->old_pic_timing_sei = q->pic_timing_sei;
>
>  if (q->rdo >= 0)
> @@ -968,6 +968,7 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  q->extco.AUDelimiter  = q->aud ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
>  }
>
> +q->extco.RefPicMarkRep = q->pic_timing_sei ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
>  q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer *)
> >extco;
>
>  if (avctx->codec_id == AV_CODEC_ID_H264) {


___
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 06/15] avformat/matroskaenc: Hoist check out of loop

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/matroskaenc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index be70e7a6f1..d9bc31daee 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1877,9 +1877,13 @@ static int mkv_write_track(AVFormatContext *s, 
> MatroskaMuxContext *mkv,
>  
>  // look for a codec ID string specific to mkv to use,
>  // if none are found, use AVI codes
> -if (par->codec_id != AV_CODEC_ID_RAWVIDEO || par->codec_tag) {
> +if (par->codec_id == AV_CODEC_ID_FFV1) {
> +/* FFV1 is actually supported natively in Matroska,
> + * yet we use the VfW way to mux it for compatibility
> + * with old demuxers. (FIXME: Are they really important?) */
> +} else if (par->codec_id != AV_CODEC_ID_RAWVIDEO || par->codec_tag) {
>  for (j = 0; ff_mkv_codec_tags[j].id != AV_CODEC_ID_NONE; j++) {
> -if (ff_mkv_codec_tags[j].id == par->codec_id && 
> par->codec_id != AV_CODEC_ID_FFV1) {
> +if (ff_mkv_codec_tags[j].id == par->codec_id) {
>  put_ebml_string(pb, MATROSKA_ID_CODECID, 
> ff_mkv_codec_tags[j].str);
>  native_id = 1;
>  break;

Will apply the rest of 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".

[FFmpeg-devel] [PATCH] lavc/qsvenc: return error with zero output

[Xiang, Haihao]

From: Haihao Xiang 

Signed-off-by: Haihao Xiang 
---
 libavcodec/qsvenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 7ff9d333a2..b3b7475b0f 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -2584,7 +2584,7 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext *q,
 pict_type = AV_PICTURE_TYPE_P;
 else if (qpkt.bs->FrameType & MFX_FRAMETYPE_B || qpkt.bs->FrameType & 
MFX_FRAMETYPE_xB)
 pict_type = AV_PICTURE_TYPE_B;
-else if (qpkt.bs->FrameType == MFX_FRAMETYPE_UNKNOWN) {
+else if (qpkt.bs->FrameType == MFX_FRAMETYPE_UNKNOWN && 
qpkt.bs->DataLength) {
 pict_type = AV_PICTURE_TYPE_NONE;
 av_log(avctx, AV_LOG_WARNING, "Unknown FrameType, set pict_type to 
AV_PICTURE_TYPE_NONE.\n");
 } else {
-- 
2.34.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] lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10

[David Rosca]

Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
---
v2: fix #ifdef -> #if
v3: annotate

 libavutil/hwcontext_vaapi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a227ddd..558fed94c6 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1048,6 +1048,9 @@ static const struct {
 #if defined(VA_FOURCC_Y412) && defined(DRM_FORMAT_XVYU12_16161616)
 DRM_MAP(Y412, 1, DRM_FORMAT_XVYU12_16161616),
 #endif
+#if defined(VA_FOURCC_X2R10G10B10) && defined(DRM_FORMAT_XRGB2101010)
+DRM_MAP(X2R10G10B10, 1, DRM_FORMAT_XRGB2101010),
+#endif
 };
 #undef DRM_MAP
 
-- 
2.41.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".