Re: [FFmpeg-devel] [PATCH v3 1/3] hwcontext_d3d11va: add mutiple supported DXGI formats
On So, 2023-02-19 at 01:57 +, Xiang, Haihao wrote:
> On Do, 2023-02-16 at 01:30 +, Xiang, Haihao wrote:
> > On Di, 2023-02-14 at 10:45 +0800, Tong Wu wrote:
> > > Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
> > >
> > > The added formats work with qsv acceleration and will not have
> > > impact on d3d11va acceleration(-hwaccel d3d11va) since so far
> > > these formats are still not supported by using d3d11va acceleration.
> > >
> > > Hwupload and hwdownload can work with the added formats.
> > >
> > > Signed-off-by: Tong Wu
> > > ---
> > > libavutil/hwcontext_d3d11va.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> > > index 363ec6a47d..aa50538d64 100644
> > > --- a/libavutil/hwcontext_d3d11va.c
> > > +++ b/libavutil/hwcontext_d3d11va.c
> > > @@ -89,6 +89,13 @@ static const struct {
> > > { DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
> > > { DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
> > > { DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },
> > > +{ DXGI_FORMAT_AYUV, AV_PIX_FMT_VUYX },
> > > +{ DXGI_FORMAT_YUY2, AV_PIX_FMT_YUYV422 },
> > > +{ DXGI_FORMAT_Y210, AV_PIX_FMT_Y210 },
> > > +{ DXGI_FORMAT_Y410, AV_PIX_FMT_XV30 },
> > > +{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
> > > +{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
> > > +{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
> > > // Special opaque formats. The pix_fmt is merely a place holder, as
> > > the
> > > // opaque format cannot be accessed directly.
> > > { DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
> >
> > LGTM, thx
> >
>
> Is there any comment about this patchset? I will push it in the next few days
> if
> there are no objections for v3,
Pushed, thx
- Haihao
___
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] libavcodec/libfdk-aacenc: Scale VBR mode with FF_QP2LAMBDA
libavcodec/libfdk-aacenc: VBR mode currently does not account for scaling when
using -aq options with libfdk, resulting in clamping to vbr mode 5 whenever a
value >0 is provided. Adjusting for the scaling factor for proper VBR support.
---
libavcodec/libfdk-aacenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 54549de473..da211baf51 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -230,7 +230,7 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
}
if (avctx->flags & AV_CODEC_FLAG_QSCALE || s->vbr) {
-int mode = s->vbr ? s->vbr : avctx->global_quality;
+int mode = s->vbr ? s->vbr : avctx->global_quality / FF_QP2LAMBDA;
if (mode < 1 || mode > 5) {
av_log(avctx, AV_LOG_WARNING,
"VBR quality %d out of range, should be 1-5\n", mode);
--
2.39.2.637.g21b0678d19-goog
___
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] FFmpeg 6.0
On 2/21/2023 4:31 AM, Kieran Kunhya wrote: On Tue, 21 Feb 2023, 11:38 Michael Niedermayer, wrote: On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote: Hi all i plan to branch off release/6.0 from master in the next days If theres something blocking and i should wait, please reply here 6.0 release will be maybe 1 week after the branch point once it has branched all important fixes should be backported of course What name shall 6.0 bear ? ill pick what has the highest number of votes Here are some previously suggested names: Darwin, De broglie, Desitter, Galois, Gauss, Heaviside, Jacobi, Maxwell, Mellin, Perelman, Poincaré, Ramanujan, Sagan, Viterbi, Voltaire, Von Neumann thx. I would like to propose "Jemison" after Mae Jemison, the first female African-American in space or Katherine Johnson, mathematician on the Apollo programme. 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". suggestion: Heavens ___ 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] avcodec/pngdec: read colorspace info when decoding with AVDISCARD_ALL
Hi, On Tue, Feb 21, 2023 at 5:36 PM Leo Izen wrote: > These chunks are lightweight and it's useful information to have when > running ffmpeg -i or ffprobe, for example. > I disagree conceptually with this. If we want to skip "all" decoding, we should also skip metadata for said frames. I think what we're looking for here is a partial decoding stage, e.g. "header-only" or similar, instead of "including framedata", for some or all frames. That's orthogonal to AVDISCARD_*. Ronald ___ 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] Scale libFDK encoder VBR mode with FF_QP2LAMBDA
VBR mode currently does not account for scaling when using -aq options with
libfdk, resulting in clamping to vbr mode 5 whenever a value >0 is provided.
Adjusting for the scaling factor for proper VBR support.
---
libavcodec/libfdk-aacenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 54549de473..da211baf51 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -230,7 +230,7 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
}
if (avctx->flags & AV_CODEC_FLAG_QSCALE || s->vbr) {
-int mode = s->vbr ? s->vbr : avctx->global_quality;
+int mode = s->vbr ? s->vbr : avctx->global_quality / FF_QP2LAMBDA;
if (mode < 1 || mode > 5) {
av_log(avctx, AV_LOG_WARNING,
"VBR quality %d out of range, should be 1-5\n", mode);
--
2.39.2.637.g21b0678d19-goog
___
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] Use CONFIG_FFRTMPCRYPT_PROTOCOL for conditional compilation...
Use CONFIG_FFRTMPCRYPT_PROTOCOL for conditional compilation and NOT run-time
evaluation. If optimizations are disabled and CONFIG_FFRTMPCRYPT_PROTOCOL==0,
the compiler may fail to get rid of the conditional blocks. Alas, the blocks
themselves contain calls to RTMPE functionality (ff_rtmpe_gen_pub_key,
ff_rtmpe_compute_secret_key, etc.) that we have explicitly disabled by setting
CONFIG_FFRTMPCRYPT_PROTOCOL to zero in the first place.
Signed-off-by: Ziemowit Łąski <15880281+zla...@users.noreply.github.com>
---
libavformat/rtmpproto.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index f0ef223f05..5ff0e0f443 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -1222,7 +1222,8 @@ static int rtmp_handshake(URLContext *s, RTMPContext *rt)
for (i = 9; i <= RTMP_HANDSHAKE_PACKET_SIZE; i++)
tosend[i] = av_lfg_get(&rnd) >> 24;
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* When the client wants to use RTMPE, we have to change the command
* byte to 0x06 which means to use encrypted data and we have to set
* the flash version to at least 9.0.115.0. */
@@ -1237,6 +1238,7 @@ static int rtmp_handshake(URLContext *s, RTMPContext *rt)
if ((ret = ff_rtmpe_gen_pub_key(rt->stream, tosend + 1)) < 0)
return ret;
}
+#endif
client_pos = rtmp_handshake_imprint_with_digest(tosend + 1, rt->encrypted);
if (client_pos < 0)
@@ -1300,7 +1302,8 @@ static int rtmp_handshake(URLContext *s, RTMPContext *rt)
if (ret < 0)
return ret;
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* Compute the shared secret key sent by the server and initialize
* the RC4 encryption. */
if ((ret = ff_rtmpe_compute_secret_key(rt->stream, serverdata + 1,
@@ -1310,6 +1313,7 @@ static int rtmp_handshake(URLContext *s, RTMPContext *rt)
/* Encrypt the signature received by the server. */
ff_rtmpe_encrypt_sig(rt->stream, signature, digest, serverdata[0]);
}
+#endif
if (memcmp(signature, clientdata + RTMP_HANDSHAKE_PACKET_SIZE - 32,
32)) {
av_log(s, AV_LOG_ERROR, "Signature mismatch\n");
@@ -1330,25 +1334,30 @@ static int rtmp_handshake(URLContext *s, RTMPContext
*rt)
if (ret < 0)
return ret;
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* Encrypt the signature to be send to the server. */
ff_rtmpe_encrypt_sig(rt->stream, tosend +
RTMP_HANDSHAKE_PACKET_SIZE - 32, digest,
serverdata[0]);
}
+#endif
// write reply back to the server
if ((ret = ffurl_write(rt->stream, tosend,
RTMP_HANDSHAKE_PACKET_SIZE)) < 0)
return ret;
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* Set RC4 keys for encryption and update the keystreams. */
if ((ret = ff_rtmpe_update_keystream(rt->stream)) < 0)
return ret;
}
+#endif
} else {
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* Compute the shared secret key sent by the server and initialize
* the RC4 encryption. */
if ((ret = ff_rtmpe_compute_secret_key(rt->stream, serverdata + 1,
@@ -1361,16 +1370,19 @@ static int rtmp_handshake(URLContext *s, RTMPContext
*rt)
serverdata[0]);
}
}
+#endif
if ((ret = ffurl_write(rt->stream, serverdata + 1,
RTMP_HANDSHAKE_PACKET_SIZE)) < 0)
return ret;
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* Set RC4 keys for encryption and update the keystreams. */
if ((ret = ff_rtmpe_update_keystream(rt->stream)) < 0)
return ret;
}
+#endif
}
return 0;
@@ -2643,6 +2655,8 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags, AVDictionary **o
if (port < 0)
port = RTMPS_DEFAULT_PORT;
ff_url_join(buf, sizeof(buf), "tls", NULL, hostname, port, NULL);
+
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
} else if (!strcmp(proto, "rtmpe") || (!strcmp(proto, "rtmpte"))) {
if (!strcmp(proto, "rtmpte"))
av_dict_set(opts, "ffrtmpcrypt_tunneling", "1", 1);
@@ -2650,6 +2664,8 @@ static int rtmp_open(URLContext *s, const
Re: [FFmpeg-devel] How to implement pcap ffmpeg format?
New pcap ffmpeg format can have all options rtpdec requires. Anyway, I don't suggest you implement this feature. I just want to find a good entry point to start coding personally. I need to create a development tool for rtp tracing, and pcap files seem a good idea because I can grab rtp using tcpdump, or create pcap files directly in my application, or whatever. It's better then wrap vp8/vp9 to ivf or h264 to byte stream and pass it to ffmpeg via pipe because it doesn't require coding of new solutions for every video and audio formats transferring over rtp. On Tue, Feb 21, 2023 at 10:38 PM Kieran Kunhya wrote: > On Tue, 21 Feb 2023, 22:33 sonntex, wrote: > > > I want to implement something which helps me to play rtp stored in pcap > > files. > > > > tcpdump -i lo udp port 5 -s0 -w - | ffplay -i - > > > > The specification of pcap files is really simple and I could create a new > > ffmpeg format, but don't know how to process rtp packets extracted from > > pcap, because it seems that all functions for rtp parsing are private. > > > > Need a good example of inner ffmpeg formats processing. > > > > How is ffmpeg meant to know the meaning of the contents of a pcap and the > format inside? > > This is a very bad idea. > > What's next, ffmpeg implementing userspace TCP? Are we going to add support > for parsing filesystems as well? > > Regards, > Kieran Kunhya > > > > ___ > 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] How to implement pcap ffmpeg format?
On Tue, 21 Feb 2023, 22:33 sonntex, wrote: > I want to implement something which helps me to play rtp stored in pcap > files. > > tcpdump -i lo udp port 5 -s0 -w - | ffplay -i - > > The specification of pcap files is really simple and I could create a new > ffmpeg format, but don't know how to process rtp packets extracted from > pcap, because it seems that all functions for rtp parsing are private. > > Need a good example of inner ffmpeg formats processing. > How is ffmpeg meant to know the meaning of the contents of a pcap and the format inside? This is a very bad idea. What's next, ffmpeg implementing userspace TCP? Are we going to add support for parsing filesystems as well? Regards, Kieran Kunhya > ___ 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 v4] avcodec/pngdec: read colorspace info when decoding with AVDISCARD_ALL
These chunks are lightweight and it's useful information to have when
running ffmpeg -i or ffprobe, for example.
---
libavcodec/pngdec.c | 136 ++-
tests/ref/fate/png-icc | 8 +--
tests/ref/fate/png-side-data | 2 +-
3 files changed, 91 insertions(+), 55 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 0d969decf2..d1aa29978a 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -75,6 +75,7 @@ typedef struct PNGDecContext {
int have_chrm;
uint32_t white_point[2];
uint32_t display_primaries[3][2];
+int gamma;
int have_srgb;
int have_cicp;
enum AVColorPrimaries cicp_primaries;
@@ -641,6 +642,83 @@ static int decode_phys_chunk(AVCodecContext *avctx,
PNGDecContext *s,
return 0;
}
+/*
+ * This populates AVCodecContext fields so it must be called before
+ * ff_thread_finish_setup() to avoid a race condition with respect to the
+ * generic copying of avctx fields.
+ */
+static int populate_avctx_color_fields(AVCodecContext *avctx, AVFrame *frame)
+{
+PNGDecContext *s = avctx->priv_data;
+
+if (s->have_cicp) {
+if (s->cicp_primaries >= AVCOL_PRI_NB)
+av_log(avctx, AV_LOG_WARNING, "unrecognized cICP primaries\n");
+else
+avctx->color_primaries = frame->color_primaries =
s->cicp_primaries;
+if (s->cicp_trc >= AVCOL_TRC_NB)
+av_log(avctx, AV_LOG_WARNING, "unrecognized cICP transfer\n");
+else
+avctx->color_trc = frame->color_trc = s->cicp_trc;
+if (s->cicp_range == 0)
+av_log(avctx, AV_LOG_WARNING, "unsupported tv-range cICP chunk\n");
+} else if (s->iccp_data) {
+AVFrameSideData *sd = av_frame_new_side_data(frame,
AV_FRAME_DATA_ICC_PROFILE, s->iccp_data_len);
+if (!sd)
+return AVERROR(ENOMEM);
+memcpy(sd->data, s->iccp_data, s->iccp_data_len);
+av_dict_set(&sd->metadata, "name", s->iccp_name, 0);
+} else if (s->have_srgb) {
+avctx->color_primaries = frame->color_primaries = AVCOL_PRI_BT709;
+avctx->color_trc = frame->color_trc = AVCOL_TRC_IEC61966_2_1;
+} else if (s->have_chrm) {
+AVColorPrimariesDesc desc;
+enum AVColorPrimaries prim;
+desc.wp.x = av_make_q(s->white_point[0], 10);
+desc.wp.y = av_make_q(s->white_point[1], 10);
+desc.prim.r.x = av_make_q(s->display_primaries[0][0], 10);
+desc.prim.r.y = av_make_q(s->display_primaries[0][1], 10);
+desc.prim.g.x = av_make_q(s->display_primaries[1][0], 10);
+desc.prim.g.y = av_make_q(s->display_primaries[1][1], 10);
+desc.prim.b.x = av_make_q(s->display_primaries[2][0], 10);
+desc.prim.b.y = av_make_q(s->display_primaries[2][1], 10);
+prim = av_csp_primaries_id_from_desc(&desc);
+if (prim != AVCOL_PRI_UNSPECIFIED)
+avctx->color_primaries = frame->color_primaries = prim;
+else
+av_log(avctx, AV_LOG_WARNING, "unknown cHRM primaries\n");
+}
+
+/* these chunks override gAMA */
+if (s->iccp_data || s->have_srgb || s->have_cicp) {
+av_dict_set(&s->frame_metadata, "gamma", NULL, 0);
+} else if (s->gamma) {
+/*
+ * These values are 10/2.2, 10/2.8, 10/2.6, and
+ * 10/1.0 respectively. 45455, 35714, and 38462, and 10.
+ * There's a 0.001 gamma tolerance here in case of floating
+ * point issues when the PNG was written.
+ *
+ * None of the other enums have a pure gamma curve so it makes
+ * sense to leave those to sRGB and cICP.
+ */
+if (s->gamma > 45355 && s->gamma < 4)
+avctx->color_trc = frame->color_trc = AVCOL_TRC_GAMMA22;
+else if (s->gamma > 35614 && s->gamma < 35814)
+avctx->color_trc = frame->color_trc = AVCOL_TRC_GAMMA28;
+else if (s->gamma > 38362 && s->gamma < 38562)
+avctx->color_trc = frame->color_trc = AVCOL_TRC_SMPTE428;
+else if (s->gamma > 99900 && s->gamma < 100100)
+avctx->color_trc = frame->color_trc = AVCOL_TRC_LINEAR;
+}
+
+/* we only support pc-range RGB */
+avctx->colorspace = frame->colorspace = AVCOL_SPC_RGB;
+avctx->color_range = frame->color_range = AVCOL_RANGE_JPEG;
+
+return 0;
+}
+
static int decode_idat_chunk(AVCodecContext *avctx, PNGDecContext *s,
GetByteContext *gb, AVFrame *p)
{
@@ -756,6 +834,8 @@ static int decode_idat_chunk(AVCodecContext *avctx,
PNGDecContext *s,
p->key_frame= 1;
p->interlaced_frame = !!s->interlace_type;
+if ((ret = populate_avctx_color_fields(avctx, p)) < 0)
+return ret;
ff_thread_finish_setup(avctx);
/* compute the compressed row size */
@@ -1256,6 +1336,10 @@ static int decode_frame_common(AVCodecContext *avctx,
PNGDecContext *s,
[FFmpeg-devel] How to implement pcap ffmpeg format?
I want to implement something which helps me to play rtp stored in pcap files. tcpdump -i lo udp port 5 -s0 -w - | ffplay -i - The specification of pcap files is really simple and I could create a new ffmpeg format, but don't know how to process rtp packets extracted from pcap, because it seems that all functions for rtp parsing are private. Need a good example of inner ffmpeg formats processing. ___ 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] FFmpeg 6.0
On Tue, Feb 21, 2023 at 02:20:26PM +0100, Jean-Baptiste Kempf wrote: > > > On Tue, 21 Feb 2023, at 12:38, Michael Niedermayer wrote: > > On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote: > >> Hi all > >> > >> i plan to branch off release/6.0 from master in the next days > >> If theres something blocking and i should wait, please reply here > >> > >> 6.0 release will be maybe 1 week after the branch point > >> once it has branched all important fixes should be backported of course > > > > What name shall 6.0 bear ? > > Why don’t you select 3 or 4 names from the list > And we do a proper vote how do you select 3 or 4 names while maintaining it as a proper vote where people can add name suggestions ? > on vote.ffmpeg.org? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes 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] FFmpeg 6.0
On Tue, 21 Feb 2023, at 12:38, Michael Niedermayer wrote: > On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote: >> Hi all >> >> i plan to branch off release/6.0 from master in the next days >> If theres something blocking and i should wait, please reply here >> >> 6.0 release will be maybe 1 week after the branch point >> once it has branched all important fixes should be backported of course > > What name shall 6.0 bear ? Why don’t you select 3 or 4 names from the list And we do a proper vote on vote.ffmpeg.org? -- 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".
Re: [FFmpeg-devel] FFmpeg 6.0
On Tue, 21 Feb 2023, 11:38 Michael Niedermayer, wrote: > On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote: > > Hi all > > > > i plan to branch off release/6.0 from master in the next days > > If theres something blocking and i should wait, please reply here > > > > 6.0 release will be maybe 1 week after the branch point > > once it has branched all important fixes should be backported of course > > What name shall 6.0 bear ? > > ill pick what has the highest number of votes > > Here are some previously suggested names: > Darwin, De broglie, Desitter, Galois, Gauss, Heaviside, Jacobi, Maxwell, > Mellin, Perelman, Poincaré, Ramanujan, Sagan, Viterbi, Voltaire, Von Neumann > > thx. > I would like to propose "Jemison" after Mae Jemison, the first female African-American in space or Katherine Johnson, mathematician on the Apollo programme. 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] FFmpeg 6.0
Gijs Peskens wrote: >> Here are some previously suggested names: >> Darwin, De broglie, Desitter, Galois, Gauss, Heaviside, >> Jacobi, Maxwell, Mellin, Perelman, Poincaré, Ramanujan, >> Sagan, Viterbi, Voltaire, Von Neumann > >Assuming with Desitter the Dutch mathematician >(https://en.wikipedia.org/wiki/Willem_de_Sitter) is intended >the correct name would be "de Sitter" There is another Dutch gentleman I would like to suggest: Dijkstra. He was very influential for today's IT, but is little known. Best regards from Reto ___ 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 4/6] avformat/wavdec: s337m support
>This is why it is better to demand that these things be explicitly signalled. >At the same time a lot of users expect ffmpeg to Just Work, but that is not >always possible. Perhaps we should should put this in the manual and tell >>spdif/s377m/dolby-e users to RTFM? > >> And another point here in this latest edition on my patch serie is >> that the use of an existing AVOption makes it possible for users to >> upgrade their command lines just now by adding the option : >> ignored in previous version, it will take effect the day they upgrade >> their ffmpeg version, so the transition can be smooth... > >Assuming users read the documentation of course.. Yes, definitely, at the end, I don't see an option other than RTFM. Documentation : I could insert a "dolby_e" section between ac3 and flac in decoders.texi. But there is nothing specific to dolby_e for real. Maybe an overall "stream probing" chapter would be better in decoders.texi between "Decoders" and "Video Decoders" chapters; with a specific paragraph about the non_pcm_mode option for wav/s337 (and later for s302) ? 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] FFmpeg 6.0
On 21-02-2023 12:38, Michael Niedermayer wrote: On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote: Hi all i plan to branch off release/6.0 from master in the next days If theres something blocking and i should wait, please reply here 6.0 release will be maybe 1 week after the branch point once it has branched all important fixes should be backported of course What name shall 6.0 bear ? ill pick what has the highest number of votes Here are some previously suggested names: Darwin, De broglie, Desitter, Galois, Gauss, Heaviside, Jacobi, Maxwell, Mellin, Perelman, Poincaré, Ramanujan, Sagan, Viterbi, Voltaire, Von Neumann thx [...] Assuming with Desitter the Dutch mathematician (https://en.wikipedia.org/wiki/Willem_de_Sitter) is intended the correct name would be "de Sitter" ___ 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] FFmpeg 6.0
On Tue, Feb 21, 2023 at 12:38 PM Michael Niedermayer wrote: > On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote: > > Hi all > > > > i plan to branch off release/6.0 from master in the next days > > If theres something blocking and i should wait, please reply here > > > > 6.0 release will be maybe 1 week after the branch point > > once it has branched all important fixes should be backported of course > > What name shall 6.0 bear ? > > ill pick what has the highest number of votes > > Here are some previously suggested names: > Darwin, De broglie, Desitter, Galois, Gauss, Heaviside, Jacobi, Maxwell, > Mellin, Perelman, Poincaré, Ramanujan, Sagan, Viterbi, Voltaire, Von Neumann > > Carl, you keep censoring and removing that name all the time for some reason. > thx > > [...] > > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is what and why we do it that matters, not just one of them. > ___ > 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] FFmpeg 6.0
On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote: > Hi all > > i plan to branch off release/6.0 from master in the next days > If theres something blocking and i should wait, please reply here > > 6.0 release will be maybe 1 week after the branch point > once it has branched all important fixes should be backported of course What name shall 6.0 bear ? ill pick what has the highest number of votes Here are some previously suggested names: Darwin, De broglie, Desitter, Galois, Gauss, Heaviside, Jacobi, Maxwell, Mellin, Perelman, Poincaré, Ramanujan, Sagan, Viterbi, Voltaire, Von Neumann thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. 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 1/2] avcodec/jpeg2000dec: Move decoder structs to header files.
Ping on this On Fri, 6 Jan 2023, 18:46 Tomas Härdin, wrote: > ons 2022-12-28 klockan 23:20 +0300 skrev etemesica...@gmail.com: > > From: caleb > > > > --- > > libavcodec/jpeg2000dec.c | 88 +--- > > libavcodec/jpeg2000dec.h | 121 > > +++ > > 2 files changed, 122 insertions(+), 87 deletions(-) > > create mode 100644 libavcodec/jpeg2000dec.h > > Just responding here to mark that I've noticed these two patches but > I'm not back on j2k work until probably February > > /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 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/6] avformat/s337m: New ff_s337m_probe()
>> ff_s337m_probe is very similar to s337m_probe: what mainly differs is >> the input parameters. >> The one little thing I added is the S337M_PROBE_GUARDBAND_MIN_BYTES. >> Currently it is set to 0, so has no effect (and of course I can remove >> it if someone object). >> There is two things to know about it: >> - one is that some DolbyE decoder implementations does not support the >> s337m sync word to be the first word, A minimal guard band (full of >> zero) is required in such a case : 1 word is enough in the cases I >> experimented. >> One developer might find it useful to set >> S337M_PROBE_GUARDBAND_MIN_BYTES to 1 in order to ffprobe-qc/reject >> such files. >> - one other thing is that, currently, the detection is based on 3 >> consecutive samples, But there are other implementations in the wild. >> A common single- sample implementation is to simply require a >> sufficient S337M_PROBE_GUARDBAND_MIN_BYTES in order to avoid a fake >> detection. >> (for 16 bits, this is really dangerous!; for 24 bits, I think it is >> fair but would still require some little additions to be 100% sure). > >What a mess.. And there's no other way to reliably probe this? > >/Tomas No! But the statistics are such that at some time, a fake probe is not "possible". Anyway, we already have stream probings in current code, not only considering wav. I think my patch is similar to the spdif probe and safe. 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] [PATCH 2/6] avformat/s337m: Consider container bit resolution
>I haven't worked enough with S377m to really know, but I do know it's a mess. >Is there a way to differentiate "regular" packed 20-bit audio from S377m in >wav? > >/Tomas There is a relevant overview of S337m in this dolby paper: https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-tech-doc_1.2.pdf Page 25, one can read: SMPTE 337M is the primary method by which Dolby E is able to work in existing facilities and with existing devices. The standard is written such that the same AES3 interface can be shared with the normal PCM audio usage either by treating the AES3 channels independently or by alternating between data and linear PCM usage. Devices that are specifically designed for SMPTE 337M/Dolby E compatibility should be able to transition easily between both usages. The whole design is to not signal, not differentiate "normal PCM audio usage" from s337m. And indeed, manufacturers have implemented probing in all their hardware/software (be it linear/SDI input, or mxf/wav files input etc.). Note: ARD/ZDF mxf file format being "the" world exception here, as dolby_e/non-pcm must be signaled, made explicit: https://www.ard.de/ard/die-ard/ARD-ZDF-HDF02a-AVC-I-100-1080i-25-8-Audio-Tracks-100.pdf In ffmpeg, we already have spdif probing in wav, so there is nothing really new technically speaking. Quoting the previous dolby paper, about spdif (IEC61937): The IEC61937 format is similar to the SMPTE 337M format and can be considered a subset of SMPTE 337M for some data types (see SMPTE 337M Section 7), however there are significant differences in the two standards. In particular IEC61937 does not support the Dolby E data type. 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".
[FFmpeg-devel] [PATCH] avcodec/ac3: Remove unused fields
Signed-off-by: Nicolas Gaullier
---
libavcodec/ac3dec.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
index 138b462abb..adf82b4a98 100644
--- a/libavcodec/ac3dec.h
+++ b/libavcodec/ac3dec.h
@@ -90,7 +90,6 @@ typedef struct AC3DecodeContext {
int lfe_on; ///< lfe channel in use
int dialog_normalization[2];///< dialog level in dBFS
(dialnorm)
int compression_exists[2]; ///< compression field is valid
for frame (compre)
-int compression_gain[2];///< gain to apply for heavy
compression(compr)
int channel_map;///< custom channel map
(chanmap)
int preferred_downmix; ///< Preferred 2-channel downmix
mode (dmixmod)
int center_mix_level; ///< Center mix level index
@@ -100,7 +99,6 @@ typedef struct AC3DecodeContext {
int lfe_mix_level_exists; ///< indicates if lfemixlevcod is
specified (lfemixlevcode)
int lfe_mix_level; ///< LFE mix level index
(lfemixlevcod)
int eac3; ///< indicates if current frame is
E-AC-3
-int eac3_frame_dependent_found; ///< bitstream has E-AC-3
dependent frame(s)
int eac3_subsbtreamid_found;///< bitstream has E-AC-3
additional substream(s)
int dolby_surround_mode;///< dolby surround mode
(dsurmod)
int dolby_surround_ex_mode; ///< dolby surround ex mode
(dsurexmod)
--
2.30.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 4/6] avformat/wavdec: s337m support
fre 2023-02-17 klockan 10:30 + skrev Nicolas Gaullier:
> > > +#if CONFIG_S337M_DEMUXER
> > > + {"non_pcm_mode", "Chooses what to do with s337m",
> > > OFFSET(non_pcm_mode), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, DEC,
> > > "non_pcm_mode"},
> > > + {"copy" , "Pass s337m through unchanged", 0,
> > > AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 1, DEC, "non_pcm_mode"},
> > > + {"demux" , "Demux s337m" , 0,
> > > AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 1, DEC, "non_pcm_mode"},
> > > +#endif
> > > { NULL },
> > > };
> >
> > So default is to demux? Sounds OK and probably avoids eardrum
> > destruction
>
> Well, to be honest, I am not very comfortable with that.
> The fact is, I fear that many users have scripts to mux wav/dolby_e
> into mxf outputs and they will be affected...
This is why it is better to demand that these things be explicitly
signalled. At the same time a lot of users expect ffmpeg to Just Work,
but that is not always possible. Perhaps we should should put this in
the manual and tell spdif/s377m/dolby-e users to RTFM?
> And another point here in this latest edition on my patch serie is
> that the use of an existing AVOption makes it possible for users
> to upgrade their command lines just now by adding the option :
> ignored in previous version, it will take effect the day they upgrade
> their ffmpeg version,
> so the transition can be smooth...
Assuming users read the documentation of course..
>
> > > + } else {
> > > + av_log(s, AV_LOG_INFO, "Passing
> > > through S337M data: codec will not be reported\n");
> > > + }
> >
> > Perhaps the user should also be informed when S337m is demuxed
> > rather than passed through?
>
> I could add a debug message if you think that could be helpful ?
> I think I cannot add an INFO log as spdif and other probe-mecanisms
> are not verbose in current code.
Nah, it was more a rhetorical question
/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".
Re: [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution
fre 2023-02-17 klockan 09:44 + skrev Nicolas Gaullier: > > > @@ -56,6 +56,12 @@ static int s337m_get_offset_and_codec(void > > > *avc, > > > avpriv_report_missing_feature(avc, "Data type %#x in > > > SMPTE 337M", data_type & 0x1F); > > > return AVERROR_PATCHWELCOME; > > > } > > > + if (container_word_bits && > > > + !(container_word_bits == 16 && word_bits == 16) && > > > + !(container_word_bits == 24 && word_bits == 20) && > > > > I presume 20/24 is intentional. Does WAV not support signalling 20- > > bit? > > > > The rest looks OK enough > > > > /Tomas > > You are true, I meant "container_word_bits" as "block_size" rather > than "valid bits per sample" and > I think this should be clarified is the latter integration code in > "wavdec: s337m support" patch where > I use par->bits_per_coded_sample... > But I should have rather coded "AV_CODEC_ID_PCM_S16LE ? 16 : 24" > This is in case a wav file would be detected as 20 bits in a 24 bits > container (I don't think it is supported yet, but it could as > bitspersample and validbitpersample are two different fields in > WAVE_FORMAT_EXTENSIBLE). > Are you ok with this ? I haven't worked enough with S377m to really know, but I do know it's a mess. Is there a way to differentiate "regular" packed 20-bit audio from S377m in wav? /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".
Re: [FFmpeg-devel] [PATCH 3/6] avformat/s337m: New ff_s337m_probe()
fre 2023-02-17 klockan 10:12 + skrev Nicolas Gaullier: > > The logic here is a bit hairy and I don't have time atm to digest > > it, but is it entirely contained in S337m or would one need to read > > other specs too? > > > > /Tomas > > ff_s337m_probe is very similar to s337m_probe: what mainly differs is > the input parameters. > The one little thing I added is the S337M_PROBE_GUARDBAND_MIN_BYTES. > Currently it is set to 0, so has no effect (and of course I can > remove it if someone object). > There is two things to know about it: > - one is that some DolbyE decoder implementations does not support > the s337m sync word to be the first word, > A minimal guard band (full of zero) is required in such a case : 1 > word is enough in the cases I experimented. > One developer might find it useful to set > S337M_PROBE_GUARDBAND_MIN_BYTES to 1 in order to ffprobe-qc/reject > such files. > - one other thing is that, currently, the detection is based on 3 > consecutive samples, > But there are other implementations in the wild. A common single- > sample implementation is to simply require > a sufficient S337M_PROBE_GUARDBAND_MIN_BYTES in order to avoid a fake > detection. > (for 16 bits, this is really dangerous!; for 24 bits, I think it is > fair but would still require some little additions to be 100% sure). What a mess.. And there's no other way to reliably probe this? /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".
Re: [FFmpeg-devel] Trac votes and priority
On Sat, Feb 18, 2023 at 12:18:57AM +0100, Michael Niedermayer wrote: > On Fri, Feb 17, 2023 at 11:29:04PM +0100, Michael Niedermayer wrote: > > Hi > > > > On Fri, Feb 17, 2023 at 12:25:07PM -0600, Brad Isbell wrote: > > > I think that if Trac ticket priority is to be used, it should first be > > > working. Currently, if you try to vote on a ticket, a `500 Internal > > > Server Error` occurs in the background. > > > > it seemed to work when i tryied but it seems trac needs some adjustments and > > tuning and maintaince. It seems not configured optimally > > i could replicate this, you can work around it by simply opening the vote > link in a new window (as on right click on it and open in new tab works) > i have no time to investigate this ATM, but if someone knows what the > cause is i can apply a fix if its clean votes seem to work now with the new css & js thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban 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] trac updating bits
On Tue, Feb 21, 2023 at 11:29:22AM +0530, Gyan Doshi wrote: > > > On 2023-02-18 04:58 am, Michael Niedermayer wrote: > > Hi > > > > It appears that a bunch of static files for our trac where missed during > > previous > > updates. I re-deployed them so we should have the latest files now > > (this is css / js stuff mostly) > > I didnt notice any change in looks, but if something broke today then this > > is where to > > look first > > trac is rendered without any CSS for me. > Accessing stylesheet URI gives permission error. Fixed I must have had the CSS and other stuff cached in my browser when i tested thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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 2/3] lavc/assenc: set AV_CODEC_CAP_SINGLE_SUB_RECT
> On Feb 21, 2023, at 01:48, Nicolas George wrote: > > rcombs (12023-02-20): >> This already gave garbled output when multiple rects were present, >> so this is simply documenting an existing requirement. >> --- >> libavcodec/assenc.c | 2 ++ >> 1 file changed, 2 insertions(+) > > NAK: the code has provisions for multiple rectangles, if you enforce a > single rectangle you need to remove the code that is now useless. Fair enough, if we're fine with breaking the existing case further. Should I simply drop rectangles after a first, or return an error? > > But I do not think pushing the issue onto the applications is a good way > to fix the problem. Or even pushing the issue onto the framework, since > the framework does not know the specifics. Better fix the code in ASS > that handles multiple rectangles than inventing yet another annoying > flag. A single frame can be encoded into multiple packets, so that > should not be hard. This is only true for audio/video encoders; subtitle encoders still use a different API, which does not have M:N support. There's some long-ongoing work to change that, but for now, this seems like the only way to deal with this case before that API overhaul. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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] ffmpeg: respect AV_CODEC_CAP_SINGLE_SUB_RECT
> On Feb 21, 2023, at 01:45, Nicolas George wrote:
>
> rcombs (12023-02-20):
>> Fixes ASS output when multiple rects are present.
>> ---
>> fftools/ffmpeg.c | 28 ++--
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> Does this not belong to the framework?
I don't see a way it could be? avcodec_encode_subtitle takes an AVSubtitle and
writes to a single caller-provided buffer; there's no way for it to generate
multiple outputs for a single input.
>
>>
>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>> index 9884e0c6c6..23eac52438 100644
>> --- a/fftools/ffmpeg.c
>> +++ b/fftools/ffmpeg.c
>> @@ -1021,6 +1021,7 @@ static void do_subtitle_out(OutputFile *of,
>> AVCodecContext *enc;
>> AVPacket *pkt = ost->pkt;
>> int64_t pts;
>> +int single_rect;
>>
>> if (sub->pts == AV_NOPTS_VALUE) {
>> av_log(ost, AV_LOG_ERROR, "Subtitle packets must have a pts\n");
>> @@ -1031,11 +1032,15 @@ static void do_subtitle_out(OutputFile *of,
>>
>> enc = ost->enc_ctx;
>>
>> +single_rect = !!(enc->codec->capabilities &
>> AV_CODEC_CAP_SINGLE_SUB_RECT);
>> +
>> /* Note: DVB subtitle need one packet to draw them and one other
>>packet to clear them */
>> /* XXX: signal it in the codec context ? */
>> if (enc->codec_id == AV_CODEC_ID_DVB_SUBTITLE)
>> nb = 2;
>> +else if (single_rect)
>> +nb = FFMAX(sub->num_rects, 1);
>> else
>> nb = 1;
>>
>> @@ -1044,7 +1049,7 @@ static void do_subtitle_out(OutputFile *of,
>> if (output_files[ost->file_index]->start_time != AV_NOPTS_VALUE)
>> pts -= output_files[ost->file_index]->start_time;
>> for (i = 0; i < nb; i++) {
>> -unsigned save_num_rects = sub->num_rects;
>> +AVSubtitle local_sub = *sub;
>>
>> if (!check_recording_time(ost, pts, AV_TIME_BASE_Q))
>> return;
>> @@ -1053,19 +1058,22 @@ static void do_subtitle_out(OutputFile *of,
>> if (ret < 0)
>> report_and_exit(AVERROR(ENOMEM));
>>
>> -sub->pts = pts;
>> +local_sub.pts = pts;
>> // start_display_time is required to be 0
>> -sub->pts += av_rescale_q(sub->start_display_time,
>> (AVRational){ 1, 1000 }, AV_TIME_BASE_Q);
>> -sub->end_display_time -= sub->start_display_time;
>> -sub->start_display_time = 0;
>> -if (i == 1)
>> -sub->num_rects = 0;
>> +local_sub.pts +=
>> av_rescale_q(sub->start_display_time, (AVRational){ 1, 1000 },
>> AV_TIME_BASE_Q);
>> +local_sub.end_display_time -= sub->start_display_time;
>> +local_sub.start_display_time = 0;
>> +
>> +if (enc->codec_id == AV_CODEC_ID_DVB_SUBTITLE && i == 1)
>> +local_sub.num_rects = 0;
>> +else if (single_rect && sub->num_rects > 0) {
>> +local_sub.num_rects = 1;
>> +local_sub.rects += i;
>> +}
>>
>> ost->frames_encoded++;
>>
>> -subtitle_out_size = avcodec_encode_subtitle(enc, pkt->data,
>> pkt->size, sub);
>> -if (i == 1)
>> -sub->num_rects = save_num_rects;
>> +subtitle_out_size = avcodec_encode_subtitle(enc, pkt->data,
>> pkt->size, &local_sub);
>> if (subtitle_out_size < 0) {
>> av_log(ost, AV_LOG_FATAL, "Subtitle encoding failed\n");
>> exit_program(1);
>
> Regards,
>
> --
> Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with
> subject "unsubscribe".
___
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/3] lavc/codec.h: add AV_CODEC_CAP_SINGLE_SUB_RECT
> On Feb 21, 2023, at 01:42, Nicolas George wrote: > > rcombs (12023-02-20): >> --- >> doc/APIchanges | 3 +++ >> libavcodec/codec.h | 5 + >> libavcodec/version.h | 2 +- >> 3 files changed, 9 insertions(+), 1 deletion(-) > > And... No change to the framework to make use of this flag? Like, return > AVERROR(EINVAL) if the flag is present but several rectangles are given? I didn't want to break existing applications further, though I don't feel strongly about it either way (since the existing behavior is already very poor). > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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".
