[FFmpeg-devel] [PATCH] libavformat/rtspdec.c:flush pes buffer while rtsp seek
Fixes ticket #9949.
Signed-off-by: tanwei123
---
libavformat/mpegts.c| 20
libavformat/mpegts.h| 1 +
libavformat/rtpdec.c| 7 +++
libavformat/rtpdec.h| 2 ++
libavformat/rtpdec_mpegts.c | 11 +++
libavformat/rtspdec.c | 11 +++
6 files changed, 52 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index d97702fcd7..c5472bb464 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -3419,6 +3419,26 @@ int avpriv_mpegts_parse_packet(MpegTSContext *ts,
AVPacket *pkt,
return len1 - len;
}
+void avpriv_mpegts_seek_flush(MpegTSContext *ts)
+{
+int i;
+/* flush pes buffer */
+for (i = 0; i < NB_PID_MAX; i++) {
+if (ts->pids[i]) {
+if (ts->pids[i]->type == MPEGTS_PES) {
+PESContext *pes = ts->pids[i]->u.pes_filter.opaque;
+av_buffer_unref(&pes->buffer);
+pes->data_index = 0;
+pes->state = MPEGTS_SKIP; /* skip until pes header */
+} else if (ts->pids[i]->type == MPEGTS_SECTION) {
+ts->pids[i]->u.section_filter.last_ver = -1;
+}
+ts->pids[i]->last_cc = -1;
+ts->pids[i]->last_pcr = -1;
+}
+}
+}
+
void avpriv_mpegts_parse_close(MpegTSContext *ts)
{
mpegts_free(ts);
diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index a48f14e768..b6f19e96bb 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -170,6 +170,7 @@ MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext *s);
int avpriv_mpegts_parse_packet(MpegTSContext *ts, AVPacket *pkt,
const uint8_t *buf, int len);
void avpriv_mpegts_parse_close(MpegTSContext *ts);
+void avpriv_mpegts_seek_flush(MpegTSContext *ts);
typedef struct SLConfigDescr {
int use_au_start;
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index fa7544cc07..d688afd1c1 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -954,6 +954,13 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket *pkt,
return rv ? rv : has_next_packet(s);
}
+void ff_rtp_seek_flush(RTPDemuxContext *s)
+{
+ff_rtp_reset_packet_queue(s);
+if (s->handler && s->handler->seek_flush)
+s->handler->seek_flush(s->dynamic_protocol_context);
+}
+
void ff_rtp_parse_close(RTPDemuxContext *s)
{
ff_rtp_reset_packet_queue(s);
diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
index 5a02e72dc2..8d6d857e28 100644
--- a/libavformat/rtpdec.h
+++ b/libavformat/rtpdec.h
@@ -52,6 +52,7 @@ int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket *pkt,
void ff_rtp_parse_close(RTPDemuxContext *s);
int64_t ff_rtp_queued_packet_time(RTPDemuxContext *s);
void ff_rtp_reset_packet_queue(RTPDemuxContext *s);
+void ff_rtp_seek_flush(RTPDemuxContext *s);
/**
* Send a dummy packet on both port pairs to set up the connection
@@ -135,6 +136,7 @@ struct RTPDynamicProtocolHandler {
/** Parse handler for this dynamic packet */
DynamicPayloadPacketHandlerProc parse_packet;
int (*need_keyframe)(PayloadContext *context);
+void (*seek_flush)(PayloadContext *protocol_data);
};
typedef struct RTPPacket {
diff --git a/libavformat/rtpdec_mpegts.c b/libavformat/rtpdec_mpegts.c
index 405271f744..6e9abcae08 100644
--- a/libavformat/rtpdec_mpegts.c
+++ b/libavformat/rtpdec_mpegts.c
@@ -47,6 +47,16 @@ static av_cold int mpegts_init(AVFormatContext *ctx, int
st_index,
return 0;
}
+static void mpegts_seek_flush(PayloadContext *data)
+{
+if (!data)
+return;
+memset(data->buf, 0, data->read_buf_size);
+data->read_buf_size = 0;
+if (data->ts)
+avpriv_mpegts_seek_flush(data->ts);
+}
+
static int mpegts_handle_packet(AVFormatContext *ctx, PayloadContext *data,
AVStream *st, AVPacket *pkt, uint32_t
*timestamp,
const uint8_t *buf, int len, uint16_t seq,
@@ -94,6 +104,7 @@ const RTPDynamicProtocolHandler ff_mpegts_dynamic_handler = {
.priv_data_size= sizeof(PayloadContext),
.parse_packet = mpegts_handle_packet,
.init = mpegts_init,
+.seek_flush= mpegts_seek_flush,
.close = mpegts_close_context,
.static_payload_id = 33,
};
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index bbabec7db8..f743fac2ee 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -36,6 +36,7 @@
#include "rdt.h"
#include "tls.h"
#include "url.h"
+#include "mpegts.h"
#include "version.h"
static const struct RTSPStatusMessage {
@@ -982,6 +983,16 @@ static int rtsp_read_seek(AVFormatContext *s, int
stream_index,
rt->state = RTSP_STATE_IDLE;
break;
}
+
+if (rt->cur_transport_priv && rt->transport == RTSP_TRANSPORT_RTP) {
+ff_rtp_seek_flush(rt->cur_transport_priv);
+} else if (CONFIG_RTPDEC && rt->ts) {
+av_freep(&rt->recvbuf);
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
-Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Monday, November 14, 2022 10:43 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI On 11/4/2022 5:29 AM, bin.wang-at-intel@ffmpeg.org wrote: > +%macro FILTER_SOBEL 0 > +%if UNIX64 > +cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, > +c3, c4, c5, c6, c7, c8, r, x %else cglobal filter_sobel, 4, 15, 7, > +dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, > +c8, r, x %endif %if WIN64 > +SWAP xmm0, xmm2 > +SWAP xmm1, xmm3 > +mov r2q, matrixmp > +mov r3q, ptrmp > +DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, > +c7, c8, r, x %endif > +movsxdifnidn widthq, widthd > +VBROADCASTSS m0, xmm0 > +VBROADCASTSS m1, xmm1 > + This and every other xmm# case should instead be xm#, to ensure the > swapping is taken into account. Sorry, I can't get your point, could you please help to explain why I have to use xm# to ensure the swapping operation(swap xmm# can't work in WIN64 asm)? And How to do it ? ___ 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] Changelog: Add missing lines for QSV
From: Haihao Xiang Signed-off-by: Haihao Xiang --- Changelog | 5 + 1 file changed, 5 insertions(+) diff --git a/Changelog b/Changelog index 166aa8b5e7..f0b3d870d8 100644 --- a/Changelog +++ b/Changelog @@ -20,6 +20,11 @@ version : - ViewQuest VQC decoder - backgroundkey filter - nvenc AV1 encoding support +- DX11 support for QSV +- Multi Gfx adapter support for QSV +- oneVPL support for QSV +- QSV AV1 encoder +- QSV decoding and encoding for 10/12bit 422, 8/10/12bit 444 HEVC and VP9 version 5.1: -- 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 v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
On 11/4/2022 5:29 AM, bin.wang-at-intel@ffmpeg.org wrote: +%macro FILTER_SOBEL 0 +%if UNIX64 +cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x +%else +cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x +%endif +%if WIN64 +SWAP xmm0, xmm2 +SWAP xmm1, xmm3 +mov r2q, matrixmp +mov r3q, ptrmp +DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, r, x +%endif +movsxdifnidn widthq, widthd +VBROADCASTSS m0, xmm0 +VBROADCASTSS m1, xmm1 This and every other xmm# case should instead be xm#, to ensure the swapping is taken into account. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
On Fri, 2022-11-11 at 03:00 +, Xiang, Haihao wrote:
> On Mon, 2022-11-07 at 05:24 +, Xiang, Haihao wrote:
> > On Fri, 2022-11-04 at 16:29 +0800, bin.wang-at-intel@ffmpeg.org wrote:
> > > From: bwang30
> > >
> > > This commit enabled assembly code with intel AVX512 VNNI and added unit
> > > test
> > > for sobel filter
> > >
> > > sobel_c: 4537
> > > sobel_avx512icl 2136
> > >
> > > Signed-off-by: bwang30
> > > ---
> > > libavfilter/convolution.h | 74 +
> > > libavfilter/vf_convolution.c | 91 +++-
> > > libavfilter/x86/vf_convolution.asm| 147 ++
> > > libavfilter/x86/vf_convolution_init.c | 18
> > > tests/checkasm/Makefile | 1 +
> > > tests/checkasm/checkasm.c | 3 +
> > > tests/checkasm/checkasm.h | 1 +
> > > tests/checkasm/vf_convolution.c | 104 ++
> > > tests/fate/checkasm.mak | 1 +
> > > 9 files changed, 362 insertions(+), 78 deletions(-)
> > > create mode 100644 tests/checkasm/vf_convolution.c
> > >
> > > diff --git a/libavfilter/convolution.h b/libavfilter/convolution.h
> > > index 88aabe9a20..e44bfb5da8 100644
> > > --- a/libavfilter/convolution.h
> > > +++ b/libavfilter/convolution.h
> > > @@ -21,6 +21,7 @@
> > > #ifndef AVFILTER_CONVOLUTION_H
> > > #define AVFILTER_CONVOLUTION_H
> > > #include "avfilter.h"
> > > +#include "libavutil/intreadwrite.h"
> > >
> > > enum MatrixMode {
> > > MATRIX_SQUARE,
> > > @@ -61,4 +62,77 @@ typedef struct ConvolutionContext {
> > > } ConvolutionContext;
> > >
> > > void ff_convolution_init_x86(ConvolutionContext *s);
> > > +void ff_sobel_init_x86(ConvolutionContext *s, int depth, int nb_planes);
> > > +
> > > +static void setup_3x3(int radius, const uint8_t *c[], const uint8_t *src,
> > > int
> > > stride,
> > > + int x, int w, int y, int h, int bpc)
> > > +{
> > > +int i;
> > > +
> > > +for (i = 0; i < 9; i++) {
> > > +int xoff = FFABS(x + ((i % 3) - 1));
> > > +int yoff = FFABS(y + (i / 3) - 1);
> > > +
> > > +xoff = xoff >= w ? 2 * w - 1 - xoff : xoff;
> > > +yoff = yoff >= h ? 2 * h - 1 - yoff : yoff;
> > > +
> > > +c[i] = src + xoff * bpc + yoff * stride;
> > > +}
> > > +}
> > > +
> > > +static void filter_sobel(uint8_t *dst, int width,
> > > + float scale, float delta, const int *const
> > > matrix,
> > > + const uint8_t *c[], int peak, int radius,
> > > + int dstride, int stride, int size)
> > > +{
> > > +const uint8_t *c0 = c[0], *c1 = c[1], *c2 = c[2];
> > > +const uint8_t *c3 = c[3], *c5 = c[5];
> > > +const uint8_t *c6 = c[6], *c7 = c[7], *c8 = c[8];
> > > +int x;
> > > +
> > > +for (x = 0; x < width; x++) {
> > > +float suma = c0[x] * -1 + c1[x] * -2 + c2[x] * -1 +
> > > + c6[x] * 1 + c7[x] * 2 + c8[x] * 1;
> > > +float sumb = c0[x] * -1 + c2[x] * 1 + c3[x] * -2 +
> > > + c5[x] * 2 + c6[x] * -1 + c8[x] * 1;
> > > +
> > > +dst[x] = av_clip_uint8(sqrtf(suma*suma + sumb*sumb) * scale +
> > > delta);
> > > +}
> > > +}
> > > +
> > > +static void filter16_sobel(uint8_t *dstp, int width,
> > > + float scale, float delta, const int *const
> > > matrix,
> > > + const uint8_t *c[], int peak, int radius,
> > > + int dstride, int stride, int size)
> > > +{
> > > +uint16_t *dst = (uint16_t *)dstp;
> > > +int x;
> > > +
> > > +for (x = 0; x < width; x++) {
> > > +float suma = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[1][2 * x])
> > > *
> > > -2 + AV_RN16A(&c[2][2 * x]) * -1 +
> > > + AV_RN16A(&c[6][2 * x]) * 1 + AV_RN16A(&c[7][2 * x])
> > > * 2 + AV_RN16A(&c[8][2 * x]) * 1;
> > > +float sumb = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[2][2 * x])
> > > * 1 + AV_RN16A(&c[3][2 * x]) * -2 +
> > > + AV_RN16A(&c[5][2 * x]) * 2 + AV_RN16A(&c[6][2 * x])
> > > *
> > > -1 + AV_RN16A(&c[8][2 * x]) * 1;
> > > +
> > > +dst[x] = av_clip(sqrtf(suma*suma + sumb*sumb) * scale + delta, 0,
> > > peak);
> > > +}
> > > +}
> > > +
> > > +static av_unused void ff_sobel_init(ConvolutionContext *s, int depth, int
> > > nb_planes)
> > > +{
> > > +for (int i = 0; i < 4; i++) {
> > > +s->filter[i] = filter_sobel;
> > > +s->copy[i] = !((1 << i) & s->planes);
> > > +s->size[i] = 3;
> > > +s->setup[i] = setup_3x3;
> > > +s->rdiv[i] = s->scale;
> > > +s->bias[i] = s->delta;
> > > +}
> > > +if (s->depth > 8)
> > > +for (int i = 0; i < 4; i++)
> > > +s->filter[i] = filter16_sobel;
> > > +#if ARCH_X86_64
> > > +ff_sobel_init_x86(s, depth, nb_planes);
> > > +#endif
> > > +}
> > > #endif
> > > diff --git a/libavfilter/vf_con
Re: [FFmpeg-devel] [PATCH v3 1/4] swscale/input: add rgbaf32 input support
On Sun, Nov 13, 2022 at 1:25 PM Michael Niedermayer
wrote:
> On Wed, Nov 02, 2022 at 09:00:07PM -0700, mindm...@gmail.com wrote:
> > From: Mark Reid
> >
> > ---
> > libswscale/input.c | 172 +
> > libswscale/utils.c | 4 ++
> > 2 files changed, 176 insertions(+)
> >
> > diff --git a/libswscale/input.c b/libswscale/input.c
> > index 7ff7bfaa01..4683284b0b 100644
> > --- a/libswscale/input.c
> > +++ b/libswscale/input.c
> > @@ -1284,6 +1284,136 @@ static void rgbaf16##endian_name##ToA_c(uint8_t
> *_dst, const uint8_t *_src, cons
> > rgbaf16_funcs_endian(le, 0)
> > rgbaf16_funcs_endian(be, 1)
> >
> > +#define rdpx(src) (is_be ? av_int2float(AV_RB32(&src)):
> av_int2float(AV_RL32(&src)))
> > +
> > +static av_always_inline void rgbaf32ToUV_half_endian(uint16_t *dstU,
> uint16_t *dstV, int is_be,
> > + const float *src,
> int width,
> > + int32_t *rgb2yuv,
> int comp)
> > +{
> > +int32_t ru = rgb2yuv[RU_IDX], gu = rgb2yuv[GU_IDX], bu =
> rgb2yuv[BU_IDX];
> > +int32_t rv = rgb2yuv[RV_IDX], gv = rgb2yuv[GV_IDX], bv =
> rgb2yuv[BV_IDX];
> > +int i;
> > +for (i = 0; i < width; i++) {
>
> > +int r = (lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+0]),
> 0.0f, 65535.0f)) +
> > + lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+4]),
> 0.0f, 65535.0f))) >> 1;
> > +int g = (lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+1]),
> 0.0f, 65535.0f)) +
> > + lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+5]),
> 0.0f, 65535.0f))) >> 1;
> > +int b = (lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+2]),
> 0.0f, 65535.0f)) +
> > + lrintf(av_clipf(65535.0f * rdpx(src[i*(comp*2)+6]),
> 0.0f, 65535.0f))) >> 1;
> > +
> > +dstU[i] = (ru*r + gu*g + bu*b + (0x10001<<(RGB2YUV_SHIFT-1)))
> >> RGB2YUV_SHIFT;
> > +dstV[i] = (rv*r + gv*g + bv*b + (0x10001<<(RGB2YUV_SHIFT-1)))
> >> RGB2YUV_SHIFT;
>
> I would expect this sort of code to use 2 lrintf() and 2 av_clipf() not 6
>
>
ya it is a bit excessive, I'll just remove the _half conversions for now,
they aren't strictly necessary as far as I can tell.
>
> > +}
> > +}
> > +
> > +static av_always_inline void rgbaf32ToUV_endian(uint16_t *dstU,
> uint16_t *dstV, int is_be,
> > +const float *src, int
> width,
> > +int32_t *rgb2yuv, int
> comp)
> > +{
> > +int32_t ru = rgb2yuv[RU_IDX], gu = rgb2yuv[GU_IDX], bu =
> rgb2yuv[BU_IDX];
> > +int32_t rv = rgb2yuv[RV_IDX], gv = rgb2yuv[GV_IDX], bv =
> rgb2yuv[BV_IDX];
> > +int i;
> > +for (i = 0; i < width; i++) {
> > +int r = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+0]), 0.0f,
> 65535.0f));
> > +int g = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+1]), 0.0f,
> 65535.0f));
> > +int b = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+2]), 0.0f,
> 65535.0f));
> > +
> > +dstU[i] = (ru*r + gu*g + bu*b + (0x10001<<(RGB2YUV_SHIFT-1)))
> >> RGB2YUV_SHIFT;
> > +dstV[i] = (rv*r + gv*g + bv*b + (0x10001<<(RGB2YUV_SHIFT-1)))
> >> RGB2YUV_SHIFT;
> > +}
> > +}
> > +
>
> > +static av_always_inline void rgbaf32ToY_endian(uint16_t *dst, const
> float *src, int is_be,
> > + int width, int32_t
> *rgb2yuv, int comp)
> > +{
> > +int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by =
> rgb2yuv[BY_IDX];
> > +int i;
> > +for (i = 0; i < width; i++) {
> > +int r = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+0]), 0.0f,
> 65535.0f));
> > +int g = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+1]), 0.0f,
> 65535.0f));
> > +int b = lrintf(av_clipf(65535.0f * rdpx(src[i*comp+2]), 0.0f,
> 65535.0f));
> > +
>
> > +dst[i] = (ry*r + gy*g + by*b + (0x2001<<(RGB2YUV_SHIFT-1))) >>
> RGB2YUV_SHIFT;
>
> there is one output so there should be only need for one clip and one
> float->int
>
This is matching the f32 planar version. I think I was paranoid about
things being bitexact for tests and that's why it's currently being done
this way.
I'll see what happens if I introduce more float operations, could I perhaps
do this in a later patch? some asm might have to change too.
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Any man who breaks a law that conscience tells him is unjust and willingly
> accepts the penalty by staying in jail in order to arouse the conscience
> of
> the community on the injustice of the law is at that moment expressing the
> very highest respect for law. - Martin Luther King Jr
> ___
> 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 "unsub
Re: [FFmpeg-devel] [PATCH v4 2/2] lavc/vaapi_decode: add support for HWACCEL_CAP_RESET_WITHOUT_UNINIT
On Fri, 2022-11-11 at 03:45 +, Xiang, Haihao wrote:
> On Tue, 2022-11-08 at 19:45 +0800, Fei Wang wrote:
> > This can fix vp9 decode image corruption when the frame size is
> > change,
> > but the pervious frames still be referenced.
> >
> > Surfaces don't need to be bound to vaContext only after VAAPI
> > 1.0.0:
> > https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_decode.c | 41 ++-
> >
> > libavcodec/vaapi_vp9.c| 4
> > 2 files changed, 27 insertions(+), 18 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 134f10eca5..618f3c3e0a 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -658,8 +658,10 @@ int ff_vaapi_decode_init(AVCodecContext
> > *avctx)
> > VAStatus vas;
> > int err;
> >
> > -ctx->va_config = VA_INVALID_ID;
> > -ctx->va_context = VA_INVALID_ID;
> > +if (!ctx->va_config && !ctx->va_context) {
> > +ctx->va_config = VA_INVALID_ID;
> > +ctx->va_context = VA_INVALID_ID;
> > +}
>
> 0 is valid for VA config and context, it is possible the underlying
> driver
> creates VA config and context with id 0.
Fixed in V5. Thanks.
Fei
>
> Thanks
> Haihao
>
> >
> > err = ff_decode_get_hw_frames_ctx(avctx,
> > AV_HWDEVICE_TYPE_VAAPI);
> > if (err < 0)
> > @@ -670,24 +672,27 @@ int ff_vaapi_decode_init(AVCodecContext
> > *avctx)
> > ctx->device = ctx->frames->device_ctx;
> > ctx->hwctx = ctx->device->hwctx;
> >
> > -err = vaapi_decode_make_config(avctx, ctx->frames->device_ref,
> > - &ctx->va_config, NULL);
> > -if (err)
> > -goto fail;
> > -
> > -vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
> > - avctx->coded_width, avctx->coded_height,
> > - VA_PROGRESSIVE,
> > - ctx->hwfc->surface_ids,
> > - ctx->hwfc->nb_surfaces,
> > - &ctx->va_context);
> > -if (vas != VA_STATUS_SUCCESS) {
> > -av_log(avctx, AV_LOG_ERROR, "Failed to create decode "
> > - "context: %d (%s).\n", vas, vaErrorStr(vas));
> > -err = AVERROR(EIO);
> > -goto fail;
> > +if (ctx->va_config == VA_INVALID_ID) {
> > +err = vaapi_decode_make_config(avctx, ctx->frames-
> > >device_ref,
> > + &ctx->va_config, NULL);
> > +if (err)
> > +goto fail;
> > }
> >
> > +if (ctx->va_context == VA_INVALID_ID) {
> > +vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
> > + avctx->coded_width, avctx-
> > >coded_height,
> > + VA_PROGRESSIVE,
> > + ctx->hwfc->surface_ids,
> > + ctx->hwfc->nb_surfaces,
> > + &ctx->va_context);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to create decode "
> > + "context: %d (%s).\n", vas, vaErrorStr(vas));
> > +err = AVERROR(EIO);
> > +goto fail;
> > +}
> > +}
> > av_log(avctx, AV_LOG_DEBUG, "Decode context initialised: "
> > "%#x/%#x.\n", ctx->va_config, ctx->va_context);
> >
> > diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
> > index 776382f683..245b7a1b3a 100644
> > --- a/libavcodec/vaapi_vp9.c
> > +++ b/libavcodec/vaapi_vp9.c
> > @@ -181,5 +181,9 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
> > .uninit = ff_vaapi_decode_uninit,
> > .frame_params = ff_vaapi_common_frame_params,
> > .priv_data_size = sizeof(VAAPIDecodeContext),
> > +#if VA_CHECK_VERSION(1, 0, 0)
> > +.caps_internal= HWACCEL_CAP_ASYNC_SAFE |
> > HWACCEL_CAP_RESET_WITHOUT_UNINIT,
> > +#else
> > .caps_internal= HWACCEL_CAP_ASYNC_SAFE,
> > +#endif
> > };
___
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 v5 2/2] lavc/vaapi_decode: add support for HWACCEL_CAP_RESET_WITHOUT_UNINIT
This can fix vp9 decode image corruption when the frame size is change,
but the pervious frames still be referenced.
Surfaces don't need to be bound to vaContext only after VAAPI 1.0.0:
https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8
Signed-off-by: Fei Wang
---
libavcodec/vaapi_decode.c | 11 ---
libavcodec/vaapi_decode.h | 1 +
libavcodec/vaapi_vp9.c| 4
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 134f10eca5..d950471b6d 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -658,9 +658,6 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
VAStatus vas;
int err;
-ctx->va_config = VA_INVALID_ID;
-ctx->va_context = VA_INVALID_ID;
-
err = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_VAAPI);
if (err < 0)
goto fail;
@@ -670,6 +667,12 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
ctx->device = ctx->frames->device_ctx;
ctx->hwctx = ctx->device->hwctx;
+if (ctx->inited)
+return 0;
+
+ctx->va_config = VA_INVALID_ID;
+ctx->va_context = VA_INVALID_ID;
+
err = vaapi_decode_make_config(avctx, ctx->frames->device_ref,
&ctx->va_config, NULL);
if (err)
@@ -691,6 +694,8 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
av_log(avctx, AV_LOG_DEBUG, "Decode context initialised: "
"%#x/%#x.\n", ctx->va_config, ctx->va_context);
+ctx->inited = 1;
+
return 0;
fail:
diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
index 6beda14e52..62a4f37ed9 100644
--- a/libavcodec/vaapi_decode.h
+++ b/libavcodec/vaapi_decode.h
@@ -61,6 +61,7 @@ typedef struct VAAPIDecodeContext {
int surface_count;
VASurfaceAttrib pixel_format_attribute;
+int inited;
} VAAPIDecodeContext;
diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index 776382f683..245b7a1b3a 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -181,5 +181,9 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
.uninit = ff_vaapi_decode_uninit,
.frame_params = ff_vaapi_common_frame_params,
.priv_data_size = sizeof(VAAPIDecodeContext),
+#if VA_CHECK_VERSION(1, 0, 0)
+.caps_internal= HWACCEL_CAP_ASYNC_SAFE |
HWACCEL_CAP_RESET_WITHOUT_UNINIT,
+#else
.caps_internal= HWACCEL_CAP_ASYNC_SAFE,
+#endif
};
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v5 1/2] lavc: add HWACCEL_CAP_RESET_WITHOUT_UNINIT capacity for hwaccel
The capacity can avoid hwaccel being uninited when do the reset. It
provides the method for hwaccel if it still want to use the previous
initialized configuration after reset. And the configuration can be
updated in AVHWAccel.init() if needed.
For example, when use vaapi vp9 decode dynamic resolution clips, need
to avoid changing vaContext in avctx->internal->hwaccel_priv_data if
current frame resolution change and it reference a pervious frame with
different resolution. Otherwise reference frame's information bound
in vaContext will be lost, then corrupt current frame.
Signed-off-by: Fei Wang
---
update:
1. consider the case of va_config/va_context equal to 0.
libavcodec/decode.c | 10 ++
libavcodec/hwconfig.h | 7 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6be2d3d6ed..cfada048e8 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1109,7 +1109,7 @@ static int hwaccel_init(AVCodecContext *avctx,
return AVERROR_PATCHWELCOME;
}
-if (hwaccel->priv_data_size) {
+if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data) {
avctx->internal->hwaccel_priv_data =
av_mallocz(hwaccel->priv_data_size);
if (!avctx->internal->hwaccel_priv_data)
@@ -1134,10 +1134,12 @@ static int hwaccel_init(AVCodecContext *avctx,
static void hwaccel_uninit(AVCodecContext *avctx)
{
-if (avctx->hwaccel && avctx->hwaccel->uninit)
-avctx->hwaccel->uninit(avctx);
+if (avctx->hwaccel && !(avctx->hwaccel->caps_internal &
HWACCEL_CAP_RESET_WITHOUT_UNINIT)) {
+if (avctx->hwaccel->uninit)
+avctx->hwaccel->uninit(avctx);
-av_freep(&avctx->internal->hwaccel_priv_data);
+av_freep(&avctx->internal->hwaccel_priv_data);
+}
avctx->hwaccel = NULL;
diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
index 721424912c..5fb4e06d5f 100644
--- a/libavcodec/hwconfig.h
+++ b/libavcodec/hwconfig.h
@@ -25,6 +25,13 @@
#define HWACCEL_CAP_ASYNC_SAFE (1 << 0)
+/**
+ * The hwaccel supports reset without calling back AVHWAccel.uninit()
+ * and realloc avctx->internal->hwaccel_priv_data.
+ *
+ * New configuration can set up through AVHWAccel.init().
+ */
+#define HWACCEL_CAP_RESET_WITHOUT_UNINIT (1 << 1)
typedef struct AVCodecHWConfigInternal {
/**
--
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] mpegts: identify and demux DSMCC-B/MHEG streams
Ping for review.
On 9/17/22 13:08, Scott Theisen wrote:
These changes are from MythTV.
---
The `AV_CODEC_ID`s are probably in the wrong place since these are
data codecs, but that is where they are In MythTV.
There was also a related change to libavformat/demux.c's
avformat_find_stream_info() trying to optimize it for MHEG streams,
but it is unnecessary and was causing FATE to fail.
libavcodec/codec_desc.c | 12 +++
libavcodec/codec_id.h | 6 ++
libavformat/avformat.h | 5 +
libavformat/mpegts.c| 199 +++-
libavformat/mpegts.h| 17
5 files changed, 237 insertions(+), 2 deletions(-)
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 648c518b3c..0e54087863 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3488,6 +3488,18 @@ static const AVCodecDescriptor codec_descriptors[] = {
.props = AV_CODEC_PROP_TEXT_SUB,
.profiles = NULL_IF_CONFIG_SMALL(ff_arib_caption_profiles),
},
+{
+.id= AV_CODEC_ID_DVB_VBI,
+.type = AVMEDIA_TYPE_DATA,
+.name = "dvb_vbi",
+.long_name = NULL_IF_CONFIG_SMALL("dvb teletext"),
+},
+{
+.id= AV_CODEC_ID_DSMCC_B,
+.type = AVMEDIA_TYPE_DATA,
+.name = "dsmcc_b",
+.long_name = NULL_IF_CONFIG_SMALL("DSMCC B"),
+},
/* other kind of codecs and pseudo-codecs */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index bc8226ff07..7e2198a800 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -559,6 +559,12 @@ enum AVCodecID {
AV_CODEC_ID_TTML,
AV_CODEC_ID_ARIB_CAPTION,
+/* teletext codecs */
+AV_CODEC_ID_DVB_VBI,
+
+/* DSMCC codec */
+AV_CODEC_ID_DSMCC_B,
+
/* other specific kind of codecs (generally used for attachments) */
AV_CODEC_ID_FIRST_UNKNOWN = 0x18000, ///< A dummy ID pointing
at the start of various fake codecs.
AV_CODEC_ID_TTF = 0x18000,
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9d46875cce..664a1afa61 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1117,6 +1117,11 @@ typedef struct AVStream {
*
*/
int pts_wrap_bits;
+
+/* MHEG support */
+int component_tag; ///< Component tag given in PMT
+int carousel_id;
+int data_id;
} AVStream;
struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 8a3436f2be..be8edd9e62 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -46,6 +46,15 @@
#include
#endif
+typedef struct SectionContext {
+int pid;
+int stream_type;
+int new_packet;
+MpegTSContext *ts;
+AVFormatContext *stream;
+AVStream *st;
+} SectionContext;
+
/* maximum size in which we look for synchronization if
* synchronization is lost */
#define MAX_RESYNC_SIZE 65536
@@ -412,6 +421,8 @@ static int discard_pid(MpegTSContext *ts, unsigned int pid)
return !used && discarded;
}
+static void mpegts_push_section(MpegTSFilter *filter, const uint8_t *section, int section_len);
+
/**
* Assemble PES packets out of TS packets, and then call the "section_cb"
* function when they are complete.
@@ -438,6 +449,11 @@ static void write_section_data(MpegTSContext *ts,
MpegTSFilter *tss1,
tss->section_index += len;
}
+if (tss->section_cb == mpegts_push_section) {
+SectionContext *sect = tss->opaque;
+sect->new_packet = 1;
+}
+
offset = 0;
cur_section_buf = tss->section_buf;
while (cur_section_buf - tss->section_buf < MAX_SECTION_SIZE &&
cur_section_buf[0] != 0xff) {
@@ -798,6 +814,7 @@ static const StreamType ISO_types[] = {
{ 0x02, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO },
{ 0x03, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3},
{ 0x04, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3},
+{ 0x0b, AVMEDIA_TYPE_DATA, AV_CODEC_ID_DSMCC_B}, /* DVB_CAROUSEL_ID */
{ 0x0f, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC},
{ 0x10, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG4 },
/* Makito encoder sets stream type 0x11 for AAC,
@@ -882,11 +899,20 @@ static const StreamType DESC_types[] = {
{ 0x6a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_AC3 }, /* AC-3
descriptor */
{ 0x7a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_EAC3 }, /* E-AC-3
descriptor */
{ 0x7b, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_DTS },
+{ 0x13, AVMEDIA_TYPE_DATA, AV_CODEC_ID_DSMCC_B }, /*
DVB_CAROUSEL_ID */
+{ 0x45, AVMEDIA_TYPE_DATA, AV_CODEC_ID_DVB_VBI }, /*
DVB_VBI_DATA_ID */
+{ 0x46, AVMEDIA_TYPE_DATA, AV_CODEC_ID_DVB_VBI }, /*
DVB_VBI_TELETEXT_ID */ //FixMe type subtilte
{ 0x56, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_TELETEXT },
{ 0x59, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_SUBTITLE
Re: [FFmpeg-devel] [PATCH] x86/intreadwrite: use intrinsics instead of inline asm for AV_ZERO128
On 10/24/2022 5:03 PM, James Almer wrote:
When called inside a loop, the inline asm version results in one pxor
unnecessarely emitted per iteration, as the contents of the __asm__() block are
opaque to the compiler's instruction scheduler.
This is not the case with intrinsics, where pxor will be emitted once with any
half decent compiler.
The code can be adapted to also work with MSVC, but for now, it will work with
the same compilers previously supported (GCC, Clang, etc).
Signed-off-by: James Almer
---
configure| 3 +++
libavutil/x86/intreadwrite.h | 15 +++
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index c5a466657f..5bb83f5b5a 100755
--- a/configure
+++ b/configure
@@ -,6 +,7 @@ HEADERS_LIST="
INTRINSICS_LIST="
intrinsics_neon
+intrinsics_sse2
"
COMPLEX_FUNCS="
@@ -2636,6 +2637,7 @@ armv6t2_deps="arm"
armv8_deps="aarch64"
neon_deps_any="aarch64 arm"
intrinsics_neon_deps="neon"
+intrinsics_sse2_deps="sse2"
vfp_deps_any="aarch64 arm"
vfpv3_deps="vfp"
setend_deps="arm"
@@ -6207,6 +6209,7 @@ elif enabled loongarch; then
fi
check_cc intrinsics_neon arm_neon.h "int16x8_t test = vdupq_n_s16(0)"
+check_cc intrinsics_sse2 emmintrin.h "__m128i test = _mm_setzero_si128()"
check_ldflags -Wl,--as-needed
check_ldflags -Wl,-z,noexecstack
diff --git a/libavutil/x86/intreadwrite.h b/libavutil/x86/intreadwrite.h
index 40f375b013..4a03e60fc6 100644
--- a/libavutil/x86/intreadwrite.h
+++ b/libavutil/x86/intreadwrite.h
@@ -21,6 +21,9 @@
#ifndef AVUTIL_X86_INTREADWRITE_H
#define AVUTIL_X86_INTREADWRITE_H
+#if HAVE_INTRINSICS_SSE2
+#include
+#endif
#include
#include "config.h"
#include "libavutil/attributes.h"
@@ -79,20 +82,16 @@ static av_always_inline void AV_COPY128(void *d, const void
*s)
#endif /* __SSE__ */
-#ifdef __SSE2__
+#if HAVE_INTRINSICS_SSE2 && defined(__SSE2__)
#define AV_ZERO128 AV_ZERO128
static av_always_inline void AV_ZERO128(void *d)
{
-struct v {uint64_t v[2];};
-
-__asm__("pxor %%xmm0, %%xmm0 \n\t"
-"movdqa %%xmm0, %0 \n\t"
-: "=m"(*(struct v*)d)
-:: "xmm0");
+__m128i zero = _mm_setzero_si128();
+_mm_store_si128(d, zero);
}
-#endif /* __SSE2__ */
+#endif /* HAVE_INTRINSICS_SSE2 && defined(__SSE2__) */
#endif /* HAVE_MMX */
Will apply.
___
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 3/3] avcodec/ass: specify a permissive encoding
On Sun, Nov 13, 2022 at 21:15:04 +0100, Oneric wrote: > To apply the third patch you may use v1 or the attached patch file. The list also stripped the CRLF line endings from the (quoted-printable encoded) attachments :( Also no patchwork download has unmangled line endings anymore. All v1 patches can be applied from the mail client, patch one and two of v2 too. In case someone can't directly apply mails, I attached all three v2 patches again bundled in an archive in another message of this thread to stop list shenanigans. The list archive also has a download link for the *.tar.xz archive: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-November/303904.html Expected SHA256: 8e3968f0a342c30928f8ab889efdf3bf1eb65e3cd157b42c82fb3d205815658b When applying, make sure to use git am --keep-cr. Regards Oneric signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
On Sun, Nov 13, 2022 at 21:01:34 +, Soft Works wrote: > I am unable to apply any of those patches. Neither v1 nor v2 neither > when downloading the series mbox or [2/3] from patchwork nor when > saving [2/3] from the e-mail. Re patchwork, yes I rechecked and it appears all downloads are now broken (see prev message). Regarding applying the mails, all I can say is it works for me. After a fresh clone to /tmp/ffmpeg, I can successfully apply v1 1/3, v1 2/3 and v1 3/3 from my mail client via pipe-menu and `git -C /tmp/ffmpeg am -`. For v2 the first two patches also work. > Did you notice that FATE has failed, even with the v1 patches? While checking the current mbox download, I noticed yeah. The error for loongarch doesn't make sense to me "could not build fake ancestor" and the x86 runner manages to apply it, so this seems like a false positive. For x86_make_fate the short errors snippet that’s available only shows tests failing which work for me. To make sure, I copied my old fate-suite dir to the fresh clone, configured with --enable-libass --enable-libx264 --enable-libopus --enable-gpl --disable-shared --enable-static --samples=fate-suite/ and then ran `make fate-rsync`, `make` and `make fate` with an appropriate job count for: - v2 1+2 - v2 1+2 followed by v1 3 - v1 1+2+3 all applied from the received mails and all succeeded. I’d guess the fate runner uses --no-keep-cr, but then applying should already fail. Perhaps there’s a similar option only "normalising" added lines? Checking the format-patch for v2 3/3 I attached earlier (which also only ended up as quoted-printable not base64), shows the list again stripped CRLF just like for the initial patch :( It appears this list’s configuration is particular bad for CRLF-requiring patches. (But v1 or forcing base64 should still work) To make applying easier for you, I now attached all patches bundled as an archive to keep the list from interfering. Make sure to use --keep-cr. All tests were done on top of 2d25f33a7ed36003de9a62c9cb165db183663d1c. Regards Oneric patches_ffmpeg_ass-fixes_20221112.tar.xz Description: application/xz signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
> -Original Message- > From: ffmpeg-devel On Behalf Of > Oneric > Sent: Sunday, November 13, 2022 10:00 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion > fixes > > On Sun, Nov 13, 2022 at 21:27:11 +0100, Oneric wrote: > > [...] You can easily verify emails are capable of it by > > applying patch 2 yourself or using patchwork’s mbox file. > > A correction: it seems since last time we discussed this, some > patchwork > update has expanded the line-mangling to also affect "mbox" and > "series" > downloads. (Or I’m misremembering and no patchwork download ever > worked) > So to apply v2 patch 2/3, using the received mail itself is the only > option. (Applying v1 patch 2/3 also does the job) Did you notice that FATE has failed, even with the v1 patches? softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
> -Original Message- > From: ffmpeg-devel On Behalf Of > Oneric > Sent: Sunday, November 13, 2022 9:27 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion > fixes > > On Sun, Nov 13, 2022 at 20:15:23 +, Soft Works wrote: > > > > [...] it's not a Patchwork bug and it cannot be "fixed" > > at all in any other way than using binary diffs. The problem lies > in > > the fact that it's being sent by e-mail where the different line > > endings get lost (as the spec mandates CRLF and doesn't allow LF > only). > > As last time: No, emails are perfectly capable of preserving CRLF > line > endings via e.g. "quoted-printable" or "base64" transfer-encoding and > that’s what git send-email automatically uses. > > As a case in point of it not being "just" patchwork, there’s the > troubles with patch 3 of this series already as sent out by the list. > This is most likely to blame on the list itself and its message- > editing to > add a footer though, and not on git send-email or email in general. > > > Caveats when testing: Your local generated .patch files still work > > and depending on your e-mail client, even the patch in your sent > items > > folder might not work. But as soon as it's been sent via SMTP the > > different line ending get lost. > > And again like last, time I do ofc check the sent&received emails and > not > local patch files. You can easily verify emails are capable of it by > applying patch 2 yourself or using patchwork’s mbox file. > > Please actually focus on the patch this time. I have no need for > repeating > the same long tangent about email and transfer encodings as last > time, so > I’ll ignore all further messages from you not about the code changes. I am unable to apply any of those patches. Neither v1 nor v2 neither when downloading the series mbox or [2/3] from patchwork nor when saving [2/3] from the e-mail. softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
On Sun, Nov 13, 2022 at 21:27:11 +0100, Oneric wrote: > [...] You can easily verify emails are capable of it by > applying patch 2 yourself or using patchwork’s mbox file. A correction: it seems since last time we discussed this, some patchwork update has expanded the line-mangling to also affect "mbox" and "series" downloads. (Or I’m misremembering and no patchwork download ever worked) So to apply v2 patch 2/3, using the received mail itself is the only option. (Applying v1 patch 2/3 also does the job) Oneric signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
On Sun, Nov 13, 2022 at 20:15:23 +, Soft Works wrote: > > [...] it's not a Patchwork bug and it cannot be "fixed" > at all in any other way than using binary diffs. The problem lies in > the fact that it's being sent by e-mail where the different line > endings get lost (as the spec mandates CRLF and doesn't allow LF only). As last time: No, emails are perfectly capable of preserving CRLF line endings via e.g. "quoted-printable" or "base64" transfer-encoding and that’s what git send-email automatically uses. As a case in point of it not being "just" patchwork, there’s the troubles with patch 3 of this series already as sent out by the list. This is most likely to blame on the list itself and its message-editing to add a footer though, and not on git send-email or email in general. > Caveats when testing: Your local generated .patch files still work > and depending on your e-mail client, even the patch in your sent items > folder might not work. But as soon as it's been sent via SMTP the > different line ending get lost. And again like last, time I do ofc check the sent&received emails and not local patch files. You can easily verify emails are capable of it by applying patch 2 yourself or using patchwork’s mbox file. Please actually focus on the patch this time. I have no need for repeating the same long tangent about email and transfer encodings as last time, so I’ll ignore all further messages from you not about the code changes. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
> -Original Message- > From: ffmpeg-devel On Behalf Of > Oneric > Sent: Sunday, November 13, 2022 8:57 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion > fixes > > This fixes colours and font selection for files converted to ASS > > v2 > == > > On Nicolas George’s request resent with plain text diff for the > updated > refernce files. There is no other change and applying the diff of v1 > yields equal results to v2. > > Those files do intentionally contain CRLF line endings, > but apart from tests/ref/fate/sub-scc they are not marked as > "diff eol=crlf" in .gitattributes, so the diff (intentionally) > contains > some CRLF lines as well. Patchwork has or at least used to have bugs > dealing with CRLF diffs. In particular it may wrongly fail to apply > the > patch (I believe this is fixed by now though) and the buttons > for downloading the diff or pasting it into the clipboard corrupt > line > endings making the diff useless. > Instead directly apply the email in your inbox or use patchwork’s > mbox > download. If your git is configured strictly, you may also need to > use > git am --keep-cr ... . (Or just apply v1) Multiple issues were seen in this area. For the one part that is about mixed line endings, it's not a Patchwork bug and it cannot be "fixed" at all in any other way than using binary diffs. The problem lies in the fact that it's being sent by e-mail where the different line endings get lost (as the spec mandates CRLF and doesn't allow LF only). Caveats when testing: Your local generated .patch files still work and depending on your e-mail client, even the patch in your sent items folder might not work. But as soon as it's been sent via SMTP the different line ending get lost. softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec/ass: specify a permissive encoding
For some reason this message for the third patch was sent out as plain 7-bit us-ASCII, stripping the CRLF line endings. Using the very same git send-email command line except for an added --to= for sending it directly to myself, yields the expected "printed-quotable" encoded message preserving the CRLF line endings. Perhaps the list mangled it when adding its footer? Either way, the second patch got through correctly with base64 encoding and there areno problems with the first patch. To apply the third patch you may use v1 or the attached patch file. If you want to instead resend a v3 for all patches, let me know. For the future I configured git send-email to always use base64 no matter the content hopefully stopping the list from mangling my patches. Oneric From 73cacae6cb88aad4eb90c3b2b101ac1c5a6e2f69 Mon Sep 17 00:00:00 2001 From: Oneric Date: Sat, 12 Nov 2022 18:59:04 +0100 Subject: [PATCH] avcodec/ass: specify a permissive encoding The Encoding field (and the \fe tag) allows to limit font selection to only those fonts declaring support for the specified codepage in their OS/2's table "Code Page Character Range" field. Particularly, Encoding=0 means only font's declaring support for "ANSI", or rather "Latin (Western European)", are allowed to be selected. Specifying Encoding=1 allows all fonts to be considered. We do not want to limit font selection, so specify Encoding=1. NB: at the time of writing libass only partially supports this field, thus hiding the issue in any libass-based renderer. A VSFilter-based DirectShow filter or XySubFilter will reveal the issue when a font not declaring support for latin characters is specified in a style. --- libavcodec/ass.c | 2 +- tests/ref/fate/sub-aqtitle | 2 +- tests/ref/fate/sub-cc| 2 +- tests/ref/fate/sub-cc-realtime | 2 +- tests/ref/fate/sub-cc-scte20 | 2 +- tests/ref/fate/sub-charenc | 2 +- tests/ref/fate/sub-jacosub | 2 +- tests/ref/fate/sub-microdvd | 2 +- tests/ref/fate/sub-movtext | 2 +- tests/ref/fate/sub-mpl2 | 2 +- tests/ref/fate/sub-mpsub | 2 +- tests/ref/fate/sub-mpsub-frames | 2 +- tests/ref/fate/sub-pjs | 2 +- tests/ref/fate/sub-realtext | 2 +- tests/ref/fate/sub-sami | 2 +- tests/ref/fate/sub-sami2 | 2 +- tests/ref/fate/sub-scc | 2 +- tests/ref/fate/sub-srt | 2 +- tests/ref/fate/sub-srt-badsyntax | 2 +- tests/ref/fate/sub-stl | 2 +- tests/ref/fate/sub-subviewer | 2 +- tests/ref/fate/sub-subviewer1| 2 +- tests/ref/fate/sub-vplayer | 2 +- tests/ref/fate/sub-webvtt| 2 +- tests/ref/fate/sub-webvtt2 | 2 +- 25 files changed, 25 insertions(+), 25 deletions(-) diff --git a/libavcodec/ass.c b/libavcodec/ass.c index d2ea4c62c3..5058dc8337 100644 --- a/libavcodec/ass.c +++ b/libavcodec/ass.c @@ -65,7 +65,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx, "0,0," /* Spacing, Angle */ "%d,1,0," /* BorderStyle, Outline, Shadow */ "%d,10,10,10," /* Alignment, Margin[LRV] */ - "0\r\n"/* Encoding */ + "1\r\n"/* Encoding */ "\r\n" "[Events]\r\n" diff --git a/tests/ref/fate/sub-aqtitle b/tests/ref/fate/sub-aqtitle index ae5edcd9ab..2980d39427 100644 --- a/tests/ref/fate/sub-aqtitle +++ b/tests/ref/fate/sub-aqtitle @@ -8,7 +8,7 @@ YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding -Style: Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0 +Style: Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,1 [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text diff --git a/tests/ref/fate/sub-cc b/tests/ref/fate/sub-cc index 516d26af9a..5e4f5ff7fc 100644 --- a/tests/ref/fate/sub-cc +++ b/tests/ref/fate/sub-cc @@ -8,7 +8,7 @@ YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding -Style: Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,0 +Style: Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,1 [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text diff --git a/tests/ref/fate/sub-cc-realtime b/tests/ref/fate/sub-cc-realtime index 98dfef5501..22f09d5cdd 100644 --- a/tests/ref/fate/sub-cc-realtime +++ b/tests/ref/fate/sub-cc-realtime @@ -8,7 +8,7 @@ YCbCr Matrix: None
[FFmpeg-devel] [PATCH v2 3/3] avcodec/ass: specify a permissive encoding
The Encoding field (and the \fe tag) allows to limit font selection to only those fonts declaring support for the specified codepage in their OS/2's table "Code Page Character Range" field. Particularly, Encoding=0 means only font's declaring support for "ANSI", or rather "Latin (Western European)", are allowed to be selected. Specifying Encoding=1 allows all fonts to be considered. We do not want to limit font selection, so specify Encoding=1. NB: at the time of writing libass only partially supports this field, thus hiding the issue in any libass-based renderer. A VSFilter-based DirectShow filter or XySubFilter will reveal the issue when a font not declaring support for latin characters is specified in a style. --- libavcodec/ass.c | 2 +- tests/ref/fate/sub-aqtitle | 2 +- tests/ref/fate/sub-cc| 2 +- tests/ref/fate/sub-cc-realtime | 2 +- tests/ref/fate/sub-cc-scte20 | 2 +- tests/ref/fate/sub-charenc | 2 +- tests/ref/fate/sub-jacosub | 2 +- tests/ref/fate/sub-microdvd | 2 +- tests/ref/fate/sub-movtext | 2 +- tests/ref/fate/sub-mpl2 | 2 +- tests/ref/fate/sub-mpsub | 2 +- tests/ref/fate/sub-mpsub-frames | 2 +- tests/ref/fate/sub-pjs | 2 +- tests/ref/fate/sub-realtext | 2 +- tests/ref/fate/sub-sami | 2 +- tests/ref/fate/sub-sami2 | 2 +- tests/ref/fate/sub-scc | 2 +- tests/ref/fate/sub-srt | 2 +- tests/ref/fate/sub-srt-badsyntax | 2 +- tests/ref/fate/sub-stl | 2 +- tests/ref/fate/sub-subviewer | 2 +- tests/ref/fate/sub-subviewer1| 2 +- tests/ref/fate/sub-vplayer | 2 +- tests/ref/fate/sub-webvtt| 2 +- tests/ref/fate/sub-webvtt2 | 2 +- 25 files changed, 25 insertions(+), 25 deletions(-) diff --git a/libavcodec/ass.c b/libavcodec/ass.c index d2ea4c62c3..5058dc8337 100644 --- a/libavcodec/ass.c +++ b/libavcodec/ass.c @@ -65,7 +65,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx, "0,0," /* Spacing, Angle */ "%d,1,0," /* BorderStyle, Outline, Shadow */ "%d,10,10,10," /* Alignment, Margin[LRV] */ - "0\r\n"/* Encoding */ + "1\r\n"/* Encoding */ "\r\n" "[Events]\r\n" diff --git a/tests/ref/fate/sub-aqtitle b/tests/ref/fate/sub-aqtitle index ae5edcd9ab..2980d39427 100644 --- a/tests/ref/fate/sub-aqtitle +++ b/tests/ref/fate/sub-aqtitle @@ -8,7 +8,7 @@ YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding -Style: Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0 +Style: Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,1 [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text diff --git a/tests/ref/fate/sub-cc b/tests/ref/fate/sub-cc index 516d26af9a..5e4f5ff7fc 100644 --- a/tests/ref/fate/sub-cc +++ b/tests/ref/fate/sub-cc @@ -8,7 +8,7 @@ YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding -Style: Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,0 +Style: Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,1 [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text diff --git a/tests/ref/fate/sub-cc-realtime b/tests/ref/fate/sub-cc-realtime index 98dfef5501..22f09d5cdd 100644 --- a/tests/ref/fate/sub-cc-realtime +++ b/tests/ref/fate/sub-cc-realtime @@ -8,7 +8,7 @@ YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding -Style: Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,0 +Style: Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,1 [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text diff --git a/tests/ref/fate/sub-cc-scte20 b/tests/ref/fate/sub-cc-scte20 index a97d29f70b..cded979cb8 100644 --- a/tests/ref/fate/sub-cc-scte20 +++ b/tests/ref/fate/sub-cc-scte20 @@ -8,7 +8,7 @@ YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle,
[FFmpeg-devel] [PATCH v2 2/3] avcodec/ass: accurately preserve colours
Colour values used in ASS files without a "YCbCr Matrix" header set to "None" are subject to colour mangling, due to how ASS was historically conceived. A more in-depth description can be found in the documetation inside libass' public ass_types.h header. The important part is, if this header is not set to "None", the final output colours can deviate from the literal value specified in the file. When converting from non-ASS formats we do not want any colour shift to happen, so let's set the appropiate header. NB: ffmpeg's subtitle filter, does not follow libass' documentation regarding colour mangling, thus hiding the bug. Anything based on VSFilter, XySubFilter or e.g. mpv do and might show the issue. (Of course native ASS subs, which _do_ rely on colour mangling won't work properly with the subtitle filter, but this can be fixed another time) --- Link to libass’ docs regarding colour mangling: https://github.com/libass/libass/blob/3df19c2e809b16c9cf7c925fa3bb573e2e6f4fdd/libass/ass_types.h#L152-L232 --- libavcodec/ass.c | 1 + tests/ref/fate/sub-aqtitle | 1 + tests/ref/fate/sub-cc| 1 + tests/ref/fate/sub-cc-realtime | 1 + tests/ref/fate/sub-cc-scte20 | 1 + tests/ref/fate/sub-charenc | 1 + tests/ref/fate/sub-jacosub | 1 + tests/ref/fate/sub-microdvd | 1 + tests/ref/fate/sub-movtext | 1 + tests/ref/fate/sub-mpl2 | 1 + tests/ref/fate/sub-mpsub | 1 + tests/ref/fate/sub-mpsub-frames | 1 + tests/ref/fate/sub-pjs | 1 + tests/ref/fate/sub-realtext | 1 + tests/ref/fate/sub-sami | 1 + tests/ref/fate/sub-sami2 | 1 + tests/ref/fate/sub-scc | 1 + tests/ref/fate/sub-srt | 1 + tests/ref/fate/sub-srt-badsyntax | 1 + tests/ref/fate/sub-stl | 1 + tests/ref/fate/sub-subviewer | 1 + tests/ref/fate/sub-subviewer1| 1 + tests/ref/fate/sub-vplayer | 1 + tests/ref/fate/sub-webvtt| 1 + tests/ref/fate/sub-webvtt2 | 1 + 25 files changed, 25 insertions(+) diff --git a/libavcodec/ass.c b/libavcodec/ass.c index fdf55f36ca..d2ea4c62c3 100644 --- a/libavcodec/ass.c +++ b/libavcodec/ass.c @@ -41,6 +41,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx, "PlayResX: %d\r\n" "PlayResY: %d\r\n" "ScaledBorderAndShadow: yes\r\n" + "YCbCr Matrix: None\r\n" "\r\n" "[V4+ Styles]\r\n" diff --git a/tests/ref/fate/sub-aqtitle b/tests/ref/fate/sub-aqtitle index af0c06d7c2..ae5edcd9ab 100644 --- a/tests/ref/fate/sub-aqtitle +++ b/tests/ref/fate/sub-aqtitle @@ -4,6 +4,7 @@ ScriptType: v4.00+ PlayResX: 384 PlayResY: 288 ScaledBorderAndShadow: yes +YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding diff --git a/tests/ref/fate/sub-cc b/tests/ref/fate/sub-cc index 13f393cc86..516d26af9a 100644 --- a/tests/ref/fate/sub-cc +++ b/tests/ref/fate/sub-cc @@ -4,6 +4,7 @@ ScriptType: v4.00+ PlayResX: 384 PlayResY: 288 ScaledBorderAndShadow: yes +YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding diff --git a/tests/ref/fate/sub-cc-realtime b/tests/ref/fate/sub-cc-realtime index 169361f540..98dfef5501 100644 --- a/tests/ref/fate/sub-cc-realtime +++ b/tests/ref/fate/sub-cc-realtime @@ -4,6 +4,7 @@ ScriptType: v4.00+ PlayResX: 384 PlayResY: 288 ScaledBorderAndShadow: yes +YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding diff --git a/tests/ref/fate/sub-cc-scte20 b/tests/ref/fate/sub-cc-scte20 index be28084887..a97d29f70b 100644 --- a/tests/ref/fate/sub-cc-scte20 +++ b/tests/ref/fate/sub-cc-scte20 @@ -4,6 +4,7 @@ ScriptType: v4.00+ PlayResX: 384 PlayResY: 288 ScaledBorderAndShadow: yes +YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding diff --git a/tests/ref/fate/sub-charenc b/tests/ref/fate/sub-charenc index 4efacb073d..339137ae0b 100644 --- a/tests/ref/fate/sub-charenc +++ b/tests/ref/fate/sub-charenc @@ -4,6 +4,7 @@ ScriptType: v4.00+ PlayResX: 384 PlayResY: 288 ScaledBorderAndShadow: yes +YCbCr Matrix: None [V4+ Styles] Format: Name, Fontname, Fontsize, PrimaryColour, S
[FFmpeg-devel] [PATCH v2 1/3] avcodec/ass: fix comment
There is no v4 ASS. There are versions 1 to 4 of SSA (with only v4 being supported by softsub renderers), ASS which declares itself as v4+ or v4.00+, and the rarely used v4++/v4.00++, which isn't fully supported by libass. As reflected by the [V4+ Styles] section header, FFmpeg uses ASS, not SSA v4, so adjust the comment accordingly. --- libavcodec/ass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/ass.c b/libavcodec/ass.c index 728cfb1ab5..fdf55f36ca 100644 --- a/libavcodec/ass.c +++ b/libavcodec/ass.c @@ -44,7 +44,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx, "\r\n" "[V4+ Styles]\r\n" - /* ASSv4 header */ + /* ASS (v4+) header */ "Format: Name, " "Fontname, Fontsize, " "PrimaryColour, SecondaryColour, OutlineColour, BackColour, " -- 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".
[FFmpeg-devel] [PATCH v2 0/3] Some small ASS conversion fixes
This fixes colours and font selection for files converted to ASS v2 == On Nicolas George’s request resent with plain text diff for the updated refernce files. There is no other change and applying the diff of v1 yields equal results to v2. Those files do intentionally contain CRLF line endings, but apart from tests/ref/fate/sub-scc they are not marked as "diff eol=crlf" in .gitattributes, so the diff (intentionally) contains some CRLF lines as well. Patchwork has or at least used to have bugs dealing with CRLF diffs. In particular it may wrongly fail to apply the patch (I believe this is fixed by now though) and the buttons for downloading the diff or pasting it into the clipboard corrupt line endings making the diff useless. Instead directly apply the email in your inbox or use patchwork’s mbox download. If your git is configured strictly, you may also need to use git am --keep-cr ... . (Or just apply v1) v1 == Original version sent using binary diffs for reference files. Oneric (3): avcodec/ass: fix comment avcodec/ass: accurately preserve colours avcodec/ass: specify a permissive encoding libavcodec/ass.c | 5 +++-- tests/ref/fate/sub-aqtitle | 3 ++- tests/ref/fate/sub-cc| 3 ++- tests/ref/fate/sub-cc-realtime | 3 ++- tests/ref/fate/sub-cc-scte20 | 3 ++- tests/ref/fate/sub-charenc | 3 ++- tests/ref/fate/sub-jacosub | 3 ++- tests/ref/fate/sub-microdvd | 3 ++- tests/ref/fate/sub-movtext | 3 ++- tests/ref/fate/sub-mpl2 | 3 ++- tests/ref/fate/sub-mpsub | 3 ++- tests/ref/fate/sub-mpsub-frames | 3 ++- tests/ref/fate/sub-pjs | 3 ++- tests/ref/fate/sub-realtext | 3 ++- tests/ref/fate/sub-sami | 3 ++- tests/ref/fate/sub-sami2 | 3 ++- tests/ref/fate/sub-scc | 3 ++- tests/ref/fate/sub-srt | 3 ++- tests/ref/fate/sub-srt-badsyntax | 3 ++- tests/ref/fate/sub-stl | 3 ++- tests/ref/fate/sub-subviewer | 3 ++- tests/ref/fate/sub-subviewer1| 3 ++- tests/ref/fate/sub-vplayer | 3 ++- tests/ref/fate/sub-webvtt| 3 ++- tests/ref/fate/sub-webvtt2 | 3 ++- 25 files changed, 51 insertions(+), 26 deletions(-) -- 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 2/3] avcodec/ass: accurately preserve colours
> -Original Message- > From: ffmpeg-devel On Behalf Of > Oneric > Sent: Sunday, November 13, 2022 8:22 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/3] avcodec/ass: accurately > preserve colours > > Thanks for taking a look! > > On Sun, Nov 13, 2022 at 20:12:46 +0100, Nicolas George wrote: > > Oneric (12022-11-13): > > > [...] > > > tests/ref/fate/sub-webvtt2 | Bin 1648 -> 1668 bytes > > > > These are text files. Please fix this so that we can review the > patch. > > As explained in the cover letter, those files are intentionally using > CRLF > line endings and patchwork bugs (or at least used to bug) out if it > receives patches with CRLF line endings. The last few times this > always > caused some debate, so I used binary diffs to workaround it this > time. > It just adds the "YCbCr Matrix: None" line in every file and changes > the Encoding field to "1" instead of "0". > > If you prefer and believe the patchwork bugs won’t cause confusion, > I can of course immediately send a v2 with plain text diffs. IMO, this is not necessary, because those might be better visible but nobody would be able to properly apply them. I would even go one step further and specify those files which are causing trouble in a .gitattributes file, because this will allow this (creating patches for those files as binary) to be handled automatically by git. The .gitattributes solution worked successfully as tested here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/bn0p223mb0358900908a4b2a6a37c3296ba...@bn0p223mb0358.namp223.prod.outlook.com/ PS: Thanks for your patch, will look at it later softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/ass: accurately preserve colours
Thanks for taking a look! On Sun, Nov 13, 2022 at 20:12:46 +0100, Nicolas George wrote: > Oneric (12022-11-13): > > [...] > > tests/ref/fate/sub-webvtt2 | Bin 1648 -> 1668 bytes > > These are text files. Please fix this so that we can review the patch. As explained in the cover letter, those files are intentionally using CRLF line endings and patchwork bugs (or at least used to bug) out if it receives patches with CRLF line endings. The last few times this always caused some debate, so I used binary diffs to workaround it this time. It just adds the "YCbCr Matrix: None" line in every file and changes the Encoding field to "1" instead of "0". If you prefer and believe the patchwork bugs won’t cause confusion, I can of course immediately send a v2 with plain text diffs. Regards Oneric 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] avcodec/ass: accurately preserve colours
Oneric (12022-11-13): > tests/ref/fate/sub-aqtitle | Bin 3213 -> 3233 bytes > tests/ref/fate/sub-cc| Bin 839 -> 859 bytes > tests/ref/fate/sub-cc-realtime | Bin 1524 -> 1544 bytes > tests/ref/fate/sub-cc-scte20 | Bin 945 -> 965 bytes > tests/ref/fate/sub-charenc | Bin 6008 -> 6028 bytes > tests/ref/fate/sub-jacosub | Bin 1783 -> 1803 bytes > tests/ref/fate/sub-microdvd | Bin 1375 -> 1395 bytes > tests/ref/fate/sub-movtext | Bin 783 -> 803 bytes > tests/ref/fate/sub-mpl2 | Bin 870 -> 890 bytes > tests/ref/fate/sub-mpsub | Bin 2517 -> 2537 bytes > tests/ref/fate/sub-mpsub-frames | Bin 736 -> 756 bytes > tests/ref/fate/sub-pjs | Bin 860 -> 880 bytes > tests/ref/fate/sub-realtext | Bin 939 -> 959 bytes > tests/ref/fate/sub-sami | Bin 1981 -> 2001 bytes > tests/ref/fate/sub-sami2 | Bin 9970 -> 9990 bytes > tests/ref/fate/sub-srt | Bin 6301 -> 6321 bytes > tests/ref/fate/sub-srt-badsyntax | Bin 1561 -> 1581 bytes > tests/ref/fate/sub-stl | Bin 2241 -> 2261 bytes > tests/ref/fate/sub-subviewer | Bin 780 -> 800 bytes > tests/ref/fate/sub-subviewer1| Bin 1494 -> 1514 bytes > tests/ref/fate/sub-vplayer | Bin 742 -> 762 bytes > tests/ref/fate/sub-webvtt| Bin 1985 -> 2005 bytes > tests/ref/fate/sub-webvtt2 | Bin 1648 -> 1668 bytes These are text files. Please fix this so that we can review the patch. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avcodec/ass: accurately preserve colours
Colour values used in ASS files without a "YCbCr Matrix" header set to
"None" are subject to colour mangling, due to how ASS was historically
conceived. A more in-depth description can be found in the documetation
inside libass' public ass_types.h header. The important part is, if this
header is not set to "None", the final output colours can deviate from
the literal value specified in the file. When converting from non-ASS
formats we do not want any colour shift to happen, so let's set the
appropiate header.
NB: ffmpeg's subtitle filter, does not follow libass' documentation
regarding colour mangling, thus hiding the bug. Anything based on
VSFilter, XySubFilter or e.g. mpv do and might show the issue.
(Of course native ASS subs, which _do_ rely on colour mangling won't
work properly with the subtitle filter, but this can be fixed another
time)
---
Link to libass’ docs regarding colour mangling:
https://github.com/libass/libass/blob/3df19c2e809b16c9cf7c925fa3bb573e2e6f4fdd/libass/ass_types.h#L152-L232
---
libavcodec/ass.c | 1 +
tests/ref/fate/sub-aqtitle | Bin 3213 -> 3233 bytes
tests/ref/fate/sub-cc| Bin 839 -> 859 bytes
tests/ref/fate/sub-cc-realtime | Bin 1524 -> 1544 bytes
tests/ref/fate/sub-cc-scte20 | Bin 945 -> 965 bytes
tests/ref/fate/sub-charenc | Bin 6008 -> 6028 bytes
tests/ref/fate/sub-jacosub | Bin 1783 -> 1803 bytes
tests/ref/fate/sub-microdvd | Bin 1375 -> 1395 bytes
tests/ref/fate/sub-movtext | Bin 783 -> 803 bytes
tests/ref/fate/sub-mpl2 | Bin 870 -> 890 bytes
tests/ref/fate/sub-mpsub | Bin 2517 -> 2537 bytes
tests/ref/fate/sub-mpsub-frames | Bin 736 -> 756 bytes
tests/ref/fate/sub-pjs | Bin 860 -> 880 bytes
tests/ref/fate/sub-realtext | Bin 939 -> 959 bytes
tests/ref/fate/sub-sami | Bin 1981 -> 2001 bytes
tests/ref/fate/sub-sami2 | Bin 9970 -> 9990 bytes
tests/ref/fate/sub-scc | 1 +
tests/ref/fate/sub-srt | Bin 6301 -> 6321 bytes
tests/ref/fate/sub-srt-badsyntax | Bin 1561 -> 1581 bytes
tests/ref/fate/sub-stl | Bin 2241 -> 2261 bytes
tests/ref/fate/sub-subviewer | Bin 780 -> 800 bytes
tests/ref/fate/sub-subviewer1| Bin 1494 -> 1514 bytes
tests/ref/fate/sub-vplayer | Bin 742 -> 762 bytes
tests/ref/fate/sub-webvtt| Bin 1985 -> 2005 bytes
tests/ref/fate/sub-webvtt2 | Bin 1648 -> 1668 bytes
25 files changed, 2 insertions(+)
diff --git a/libavcodec/ass.c b/libavcodec/ass.c
index fdf55f36ca..d2ea4c62c3 100644
--- a/libavcodec/ass.c
+++ b/libavcodec/ass.c
@@ -41,6 +41,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx,
"PlayResX: %d\r\n"
"PlayResY: %d\r\n"
"ScaledBorderAndShadow: yes\r\n"
+ "YCbCr Matrix: None\r\n"
"\r\n"
"[V4+ Styles]\r\n"
diff --git a/tests/ref/fate/sub-aqtitle b/tests/ref/fate/sub-aqtitle
index
af0c06d7c2809e2bfe8859f2f53cafd3c1808889..ae5edcd9abe039d33dd3e2da496fd991dcbe8490
100644
GIT binary patch
delta 29
kcmeB`TqrrAK`7EW$+<|uH?gEBv%*TjFF!AJV;w&a0GM_O{{R30
delta 10
RcmZ1|*(*7rVdE5D9sm~71J3{e
diff --git a/tests/ref/fate/sub-cc b/tests/ref/fate/sub-cc
index
13f393cc86b9f797be24f37a07aafc7272c22e59..516d26af9ab09613f939d004826e44c80b3b1054
100644
GIT binary patch
delta 29
kcmX@kcAITNgHWV%l5>%QZ(>PNW`&i4Uw&Td#=4VC0HTfx{Qv*}
delta 10
Rcmcc3cARZO!^SDcnE)Fg1kC^d
diff --git a/tests/ref/fate/sub-cc-realtime b/tests/ref/fate/sub-cc-realtime
index
169361f540e4dff43a132df395e55a19ff73..98dfef55019719911d6c5d9faa0c057cc324f227
100644
GIT binary patch
delta 29
kcmeyu-N7@VK`7EW$+<|uH?gEBv%*TjFF!AJV_g|50H13Lk^lez
delta 10
RcmeC+`NBP+VdIn%Rsb0Q1Y!UH
diff --git a/tests/ref/fate/sub-cc-scte20 b/tests/ref/fate/sub-cc-scte20
index
be28084887a9b7fb80ae4ff3369cf7192a978919..a97d29f70ba1d3984887eacb6e833abb8a406902
100644
GIT binary patch
delta 29
kcmdnUew2MegHWV%l5>%QZ(>PNW`&i4Uw&Td#yVqW0G!DRJ^%m!
delta 10
RcmX@gzL9-G!^SCw%m5g91P%ZI
diff --git a/tests/ref/fate/sub-charenc b/tests/ref/fate/sub-charenc
index
4efacb073d14b43002b58ab0b4aa55e9d34de029..339137ae0b5485c4c954f859316cf8b413b01505
100644
GIT binary patch
delta 29
kcmeyN*P}n7K`7EW$+<|uH?gEBv%*TjFF!AJW8E(?0I0?bbpQYW
delta 10
RcmeCt|DiXbVdIn^VgMYG1w{Y=
diff --git a/tests/ref/fate/sub-jacosub b/tests/ref/fate/sub-jacosub
index
b574dda54dfdee55a07f13c808ee3baa6e100798..32086d9365399ae3a968f9f61c6e3fa83a35ff65
100644
GIT binary patch
delta 29
kcmey)+s!wjK`7EW$+<|uH?gEBv%*TjFF!AJV_hX10HB5npa1{>
delta 10
RcmeC?`_4O|VdIo?HUJr21aJTV
diff --git a/tests/ref/fate/sub-microdvd b/tests/ref/fate/sub-microdvd
index
4ddb254c698245958b12e3ab0e988ef6359592a8..11440c28243f00cf99f07ff91ab2eb1c23dc2cc1
100644
GIT binary patch
delta 29
kcmcc5^_gozgHWV%l5>%QZ(>PNW`&i4Uw&Td#=3_r0I1jtPXGV_
delta 10
Rcmey&b)RcO!^SE1SpXeE1s?za
diff --git a/tests/ref/fate/sub-movtext b/tests/ref/fate/sub-movtext
index
6e2d2e35dbd94d6dded683b59436645805723372
[FFmpeg-devel] [PATCH 3/3] avcodec/ass: specify a permissive encoding
The Encoding field (and the \fe tag) allows to limit font selection to only those fonts declaring support for the specified codepage in their OS/2's table "Code Page Character Range" field. Particularly, Encoding=0 means only font's declaring support for "ANSI", or rather "Latin (Western European)", are allowed to be selected. Specifying Encoding=1 allows all fonts to be considered. We do not want to limit font selection, so specify Encoding=1. NB: at the time of writing libass only partially supports this field, thus hiding the issue in any libass-based renderer. A VSFilter-based DirectShow filter or XySubFilter will reveal the issue when a font not declaring support for latin characters is specified in a style. --- libavcodec/ass.c | 2 +- tests/ref/fate/sub-aqtitle | Bin 3233 -> 3233 bytes tests/ref/fate/sub-cc| Bin 859 -> 859 bytes tests/ref/fate/sub-cc-realtime | Bin 1544 -> 1544 bytes tests/ref/fate/sub-cc-scte20 | Bin 965 -> 965 bytes tests/ref/fate/sub-charenc | Bin 6028 -> 6028 bytes tests/ref/fate/sub-jacosub | Bin 1803 -> 1803 bytes tests/ref/fate/sub-microdvd | Bin 1395 -> 1395 bytes tests/ref/fate/sub-movtext | Bin 803 -> 803 bytes tests/ref/fate/sub-mpl2 | Bin 890 -> 890 bytes tests/ref/fate/sub-mpsub | Bin 2537 -> 2537 bytes tests/ref/fate/sub-mpsub-frames | Bin 756 -> 756 bytes tests/ref/fate/sub-pjs | Bin 880 -> 880 bytes tests/ref/fate/sub-realtext | Bin 959 -> 959 bytes tests/ref/fate/sub-sami | Bin 2001 -> 2001 bytes tests/ref/fate/sub-sami2 | Bin 9990 -> 9990 bytes tests/ref/fate/sub-scc | 2 +- tests/ref/fate/sub-srt | Bin 6321 -> 6321 bytes tests/ref/fate/sub-srt-badsyntax | Bin 1581 -> 1581 bytes tests/ref/fate/sub-stl | Bin 2261 -> 2261 bytes tests/ref/fate/sub-subviewer | Bin 800 -> 800 bytes tests/ref/fate/sub-subviewer1| Bin 1514 -> 1514 bytes tests/ref/fate/sub-vplayer | Bin 762 -> 762 bytes tests/ref/fate/sub-webvtt| Bin 2005 -> 2005 bytes tests/ref/fate/sub-webvtt2 | Bin 1668 -> 1668 bytes 25 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/ass.c b/libavcodec/ass.c index d2ea4c62c3..5058dc8337 100644 --- a/libavcodec/ass.c +++ b/libavcodec/ass.c @@ -65,7 +65,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx, "0,0," /* Spacing, Angle */ "%d,1,0," /* BorderStyle, Outline, Shadow */ "%d,10,10,10," /* Alignment, Margin[LRV] */ - "0\r\n"/* Encoding */ + "1\r\n"/* Encoding */ "\r\n" "[Events]\r\n" diff --git a/tests/ref/fate/sub-aqtitle b/tests/ref/fate/sub-aqtitle index ae5edcd9abe039d33dd3e2da496fd991dcbe8490..2980d394278644f0a1b8361833ed2bb4bd2a506b 100644 GIT binary patch delta 14 WcmZ1|xlnS$D@I1c&951^aRC4;vjw35 delta 14 WcmZ1|xlnS$D@I0x&951^aRC4;tp%U} diff --git a/tests/ref/fate/sub-cc b/tests/ref/fate/sub-cc index 516d26af9ab09613f939d004826e44c80b3b1054..5e4f5ff7fcdeb665d7de42a3d8856474e9ee2765 100644 GIT binary patch delta 14 Vcmcc3cAIU(J4Qys&F>j=7y&P41*8A~ delta 14 Vcmcc3cAIU(J4Qx>&F>j=7y&O}1)~4} diff --git a/tests/ref/fate/sub-cc-realtime b/tests/ref/fate/sub-cc-realtime index 98dfef55019719911d6c5d9faa0c057cc324f227..22f09d5cddbf7181760a9db32cc4aa21f83574cb 100644 GIT binary patch delta 14 VcmeC+>EPM$j*-!D^Ls`~762yY1iAnK delta 14 VcmeC+>EPM$j*-z|^Ls`~762yS1i1hJ diff --git a/tests/ref/fate/sub-cc-scte20 b/tests/ref/fate/sub-cc-scte20 index a97d29f70ba1d3984887eacb6e833abb8a406902..cded979cb874371943ce5eb0648b472fec9d5d1b 100644 GIT binary patch delta 14 WcmX@gew2N~J4Qys&F>knF#-TC76s%0 delta 14 WcmX@gew2N~J4Qx>&F>knF#-TC5C!7^ diff --git a/tests/ref/fate/sub-charenc b/tests/ref/fate/sub-charenc index 339137ae0b5485c4c954f859316cf8b413b01505..67e209856fccd5e1aebbacbe4c966ec769aebcd2 100644 GIT binary patch delta 14 VcmeCt@6q4zijmQ9^J~V1q5vy`1(^T< delta 14 VcmeCt@6q4zijmP^^J~V1q5vy=1(*N; diff --git a/tests/ref/fate/sub-jacosub b/tests/ref/fate/sub-jacosub index 32086d9365399ae3a968f9f61c6e3fa83a35ff65..9f555fb7470fa81d30e7668ede0fa883b105d729 100644 GIT binary patch delta 14 VcmeC?>*m|=ijmQ9^J_*0RsbhH1jGOU delta 14 VcmeC?>*m|=ijmP^^J_*0RsbhB1j7IT diff --git a/tests/ref/fate/sub-microdvd b/tests/ref/fate/sub-microdvd index 11440c28243f00cf99f07ff91ab2eb1c23dc2cc1..fa418f53db612e33dd6839b9ed1ce5ba8985e82f 100644 GIT binary patch delta 14 Vcmey&^_gqKCq_oY&7TA diff --git a/tests/ref/fate/sub-mpl2 b/tests/ref/fate/sub-mpl2 index d740fbc365460187e6b4edcf3faa00bdb5638196..f4e46e48e98bca0002f7cdfe4c78e02fa7dd436a 100644 GIT binary patch delta 14 Vcmeyx_KR)9D@I1c&952z838h$1^oa3 delta 14 Vcmeyx_KR)9D@I0x&952z838hw1^fU2 diff --git a/tests/ref/fate/sub-mpsub b/tests/ref/fate/sub-mpsub index 4c3d37fa42206d262e221b1d0b81312289329143..28c36ea40ca5bfb08e30c2ae7add905a913
[FFmpeg-devel] [PATCH 0/3] Some small ASS conversion fixes
This fixes colours and font selection for files converted to ASS. To avoid a bug with patchwork’s diff download stripping CRLFs, I formatted the updates of reference files as binary. They intentionally contain CRLF characters and without them do not pass FATE. tests/ref/fate/sub-scc keeps a text diff since it alone is marked as "diff eol=crlf" in .gitattributes. Oneric (3): avcodec/ass: fix comment avcodec/ass: accurately preserve colours avcodec/ass: specify a permissive encoding libavcodec/ass.c | 5 +++-- tests/ref/fate/sub-aqtitle | Bin 3213 -> 3233 bytes tests/ref/fate/sub-cc| Bin 839 -> 859 bytes tests/ref/fate/sub-cc-realtime | Bin 1524 -> 1544 bytes tests/ref/fate/sub-cc-scte20 | Bin 945 -> 965 bytes tests/ref/fate/sub-charenc | Bin 6008 -> 6028 bytes tests/ref/fate/sub-jacosub | Bin 1783 -> 1803 bytes tests/ref/fate/sub-microdvd | Bin 1375 -> 1395 bytes tests/ref/fate/sub-movtext | Bin 783 -> 803 bytes tests/ref/fate/sub-mpl2 | Bin 870 -> 890 bytes tests/ref/fate/sub-mpsub | Bin 2517 -> 2537 bytes tests/ref/fate/sub-mpsub-frames | Bin 736 -> 756 bytes tests/ref/fate/sub-pjs | Bin 860 -> 880 bytes tests/ref/fate/sub-realtext | Bin 939 -> 959 bytes tests/ref/fate/sub-sami | Bin 1981 -> 2001 bytes tests/ref/fate/sub-sami2 | Bin 9970 -> 9990 bytes tests/ref/fate/sub-scc | 3 ++- tests/ref/fate/sub-srt | Bin 6301 -> 6321 bytes tests/ref/fate/sub-srt-badsyntax | Bin 1561 -> 1581 bytes tests/ref/fate/sub-stl | Bin 2241 -> 2261 bytes tests/ref/fate/sub-subviewer | Bin 780 -> 800 bytes tests/ref/fate/sub-subviewer1| Bin 1494 -> 1514 bytes tests/ref/fate/sub-vplayer | Bin 742 -> 762 bytes tests/ref/fate/sub-webvtt| Bin 1985 -> 2005 bytes tests/ref/fate/sub-webvtt2 | Bin 1648 -> 1668 bytes 25 files changed, 5 insertions(+), 3 deletions(-) -- 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".
[FFmpeg-devel] [PATCH 1/3] avcodec/ass: fix comment
There is no v4 ASS. There are versions 1 to 4 of SSA (with only v4 being supported by softsub renderers), ASS which declares itself as v4+ or v4.00+, and the rarely used v4++/v4.00++, which isn't fully supported by libass. As reflected by the [V4+ Styles] section header, FFmpeg uses ASS, not SSA v4, so adjust the comment accordingly. --- libavcodec/ass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/ass.c b/libavcodec/ass.c index 728cfb1ab5..fdf55f36ca 100644 --- a/libavcodec/ass.c +++ b/libavcodec/ass.c @@ -44,7 +44,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx, "\r\n" "[V4+ Styles]\r\n" - /* ASSv4 header */ + /* ASS (v4+) header */ "Format: Name, " "Fontname, Fontsize, " "PrimaryColour, SecondaryColour, OutlineColour, BackColour, " -- 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".
[FFmpeg-devel] [PATCH 3/3] avformat/electronicarts: add option to return alpha channel in the main video stream in VP6A codec
Signed-off-by: Marton Balint
---
doc/demuxers.texi| 18
libavformat/electronicarts.c | 42 +++-
libavformat/version.h| 2 +-
3 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 2b6dd86c2a..f07f3f5318 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -285,6 +285,24 @@ This demuxer accepts the following option:
@end table
+@section ea
+
+Electronic Arts Multimedia format demuxer.
+
+This format is used by various Electronic Arts games.
+
+@subsection Options
+
+@table @option
+
+@item merge_alpha @var{bool}
+
+Normally the VP6 alpha channel (if exists) is returned as a secondary video
+stream, by setting this option you can make the demuxer return a single video
+stream which contains the alpha channel in addition to the ordinary video.
+
+@end table
+
@section imf
Interoperable Master Format demuxer.
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 0532264f38..e7f574aede 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -28,6 +28,7 @@
#include
#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
#include "avformat.h"
#include "internal.h"
@@ -75,6 +76,8 @@ typedef struct VideoProperties {
} VideoProperties;
typedef struct EaDemuxContext {
+const AVClass *class;
+
int big_endian;
VideoProperties video, alpha;
@@ -88,6 +91,7 @@ typedef struct EaDemuxContext {
int num_samples;
int platform;
+int merge_alpha;
} EaDemuxContext;
static uint32_t read_arbitrary(AVIOContext *pb)
@@ -442,6 +446,10 @@ static int process_ea_header(AVFormatContext *s)
case AVhd_TAG:
err = process_video_header_vp6(s, &ea->alpha);
+if (err >= 0 && ea->video.codec == AV_CODEC_ID_VP6 &&
ea->merge_alpha) {
+ea->alpha.codec = 0;
+ea->video.codec = AV_CODEC_ID_VP6A;
+}
break;
}
@@ -578,7 +586,7 @@ static int ea_read_packet(AVFormatContext *s, AVPacket *pkt)
int partial_packet = 0;
int hit_end = 0;
unsigned int chunk_type, chunk_size;
-int ret = 0, packet_read = 0, key = 0;
+int ret = 0, packet_read = 0, key = 0, vp6a;
int av_uninit(num_samples);
while ((!packet_read && !hit_end) || partial_packet) {
@@ -721,19 +729,28 @@ static int ea_read_packet(AVFormatContext *s, AVPacket
*pkt)
get_video_packet:
if (!chunk_size)
continue;
+if (chunk_size > INT_MAX - 3)
+return AVERROR_INVALIDDATA;
+
+vp6a = (ea->video.codec == AV_CODEC_ID_VP6A && (chunk_type ==
MV0F_TAG || chunk_type == MV0K_TAG));
if (partial_packet) {
ret = av_append_packet(pb, pkt, chunk_size);
-} else
-ret = av_get_packet(pb, pkt, chunk_size);
+} else {
+if (vp6a)
+avio_seek(pb, -3, SEEK_CUR);
+ret = av_get_packet(pb, pkt, chunk_size + (vp6a ? 3 : 0));
+if (ret >= 0 && vp6a)
+ AV_WB24(pkt->data, chunk_size);
+}
packet_read = 1;
if (ret < 0) {
partial_packet = 0;
break;
}
-partial_packet = chunk_type == MVIh_TAG;
-if (chunk_type == AV0K_TAG || chunk_type == AV0F_TAG)
+partial_packet = vp6a || chunk_type == MVIh_TAG;
+if (ea->alpha.codec && (chunk_type == AV0K_TAG || chunk_type ==
AV0F_TAG))
pkt->stream_index = ea->alpha.stream_index;
else
pkt->stream_index = ea->video.stream_index;
@@ -752,6 +769,20 @@ get_video_packet:
return ret;
}
+#define OFFSET(x) offsetof(EaDemuxContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+static const AVOption options[] = {
+{"merge_alpha", "return VP6 alpha in the main video stream",
OFFSET(merge_alpha), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS },
+{NULL}
+};
+
+static const AVClass ea_class = {
+.class_name = "ea demuxer",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
const AVInputFormat ff_ea_demuxer = {
.name = "ea",
.long_name = NULL_IF_CONFIG_SMALL("Electronic Arts Multimedia"),
@@ -759,4 +790,5 @@ const AVInputFormat ff_ea_demuxer = {
.read_probe = ea_probe,
.read_header= ea_read_header,
.read_packet= ea_read_packet,
+.priv_class = &ea_class,
};
diff --git a/libavformat/version.h b/libavformat/version.h
index 7c9d50b7b3..a7e5a9ac66 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VERSION_MINOR 34
-#define LIBAVFORMAT_VERSION_MICRO 101
+#define LIBAVFORMAT_VERSION_MICRO 102
#define
[FFmpeg-devel] [PATCH 2/3] avformat/electronicarts: set packet_read in one place
Signed-off-by: Marton Balint
---
libavformat/electronicarts.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 0a0d6249e8..0532264f38 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -726,8 +726,9 @@ get_video_packet:
ret = av_append_packet(pb, pkt, chunk_size);
} else
ret = av_get_packet(pb, pkt, chunk_size);
+packet_read = 1;
+
if (ret < 0) {
-packet_read = 1;
partial_packet = 0;
break;
}
@@ -737,7 +738,6 @@ get_video_packet:
else
pkt->stream_index = ea->video.stream_index;
pkt->flags |= key;
-packet_read = 1;
break;
default:
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avformat/electronicarts: fix EOF check
Similar to feof(), avio_feof() is only true after an actual overread.
Signed-off-by: Marton Balint
---
libavformat/electronicarts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index e7f0cb9b9e..0a0d6249e8 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -582,9 +582,9 @@ static int ea_read_packet(AVFormatContext *s, AVPacket *pkt)
int av_uninit(num_samples);
while ((!packet_read && !hit_end) || partial_packet) {
+chunk_type = avio_rl32(pb);
if (avio_feof(pb))
return AVERROR_EOF;
-chunk_type = avio_rl32(pb);
chunk_size = ea->big_endian ? avio_rb32(pb) : avio_rl32(pb);
if (chunk_size < 8)
return AVERROR_INVALIDDATA;
--
2.35.3
___
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] [Question] Technical reason why FFmpeg sets a mstack-alignment value on compile time?
Hi, On Sun, Nov 13, 2022 at 8:47 AM Nomis101 wrote: > Am 12.11.22 um 23:09 schrieb Ronald S. Bultje: > > Hi, > > > > On Sat, Nov 12, 2022 at 1:57 PM Nomis101 wrote: > > > >> Hi.If building FFmpeg, configure does set a value for mstack-alignment, > >> for example on macOS > >> -mstack-alignment=16. On HandBrake we found there is an issue with > current > >> Clang in Xcode about > >> conflicting 'override-stack-alignment' values if we build with ThinLTO. > >> > >> "ld: linking module flags 'override-stack-alignment': IDs have > conflicting > >> values" > >> > >> I found out why this is. x264 does set -mstack-alignment=64 in > configure, > >> FFmpeg does set > >> -mstack-alignment=16 and this seems to be a conflict when linking. If I > >> modify both configure files > >> and remove the mstack-alignment part, then the build does finish with no > >> error. > >> > >> And here comes my questions. I was wondering, about the technical reason > >> why FFmpeg does set > >> mstack-alignment? And if it would be safe to disable it in case FFmpeg > is > >> compiled with ThinLTO (for > >> HandBrake)? > >> > > > > It can safely be set to the higher of the two values, it has the same > > meaning. Alignment of 64 implies alignment of 16. > Thanks. I found out, that its enough to disable the mstack-alignment part > for x264 in case of > ThinLTO. This will also fix the error. > For people looking at this in the archives after a google search, trying this out and wondering why their x264 crashes, please see the following reference: https://mailman.videolan.org/pipermail/x264-devel/2022-November/012963.html (Summary: if you remove the stack alignment in x264, please also remove the assumption in x264's build that the stack *is* in fact aligned, and then everything will work fine (although a few instructions slower).) 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".
Re: [FFmpeg-devel] [Question] Technical reason why FFmpeg sets a mstack-alignment value on compile time?
Am 12.11.22 um 23:09 schrieb Ronald S. Bultje: Hi, On Sat, Nov 12, 2022 at 1:57 PM Nomis101 wrote: Hi.If building FFmpeg, configure does set a value for mstack-alignment, for example on macOS -mstack-alignment=16. On HandBrake we found there is an issue with current Clang in Xcode about conflicting 'override-stack-alignment' values if we build with ThinLTO. "ld: linking module flags 'override-stack-alignment': IDs have conflicting values" I found out why this is. x264 does set -mstack-alignment=64 in configure, FFmpeg does set -mstack-alignment=16 and this seems to be a conflict when linking. If I modify both configure files and remove the mstack-alignment part, then the build does finish with no error. And here comes my questions. I was wondering, about the technical reason why FFmpeg does set mstack-alignment? And if it would be safe to disable it in case FFmpeg is compiled with ThinLTO (for HandBrake)? It can safely be set to the higher of the two values, it has the same meaning. Alignment of 64 implies alignment of 16. Thanks. I found out, that its enough to disable the mstack-alignment part for x264 in case of ThinLTO. This will also fix the error. 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 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] avfilter/af_firequalizer: switch to TX from lavu
Patch attached.
From bf0c69dc29fa4a41de7e47308f6907adf1215df3 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sat, 12 Nov 2022 12:02:08 +0100
Subject: [PATCH] avfilter/af_firequalizer: switch to TX from lavu
Signed-off-by: Paul B Mahol
---
configure | 3 -
libavfilter/af_firequalizer.c | 119 +++---
2 files changed, 66 insertions(+), 56 deletions(-)
diff --git a/configure b/configure
index e6470dc03b..d2c5ca64b1 100755
--- a/configure
+++ b/configure
@@ -3671,8 +3671,6 @@ elbg_filter_deps="avcodec"
eq_filter_deps="gpl"
erosion_opencl_filter_deps="opencl"
find_rect_filter_deps="avcodec avformat gpl"
-firequalizer_filter_deps="avcodec"
-firequalizer_filter_select="rdft"
flip_vulkan_filter_deps="vulkan spirv_compiler"
flite_filter_deps="libflite"
framerate_filter_select="scene_sad"
@@ -7466,7 +7464,6 @@ enabled cover_rect_filter && prepend avfilter_deps "avformat avcodec"
enabled ebur128_filter && enabled swresample && prepend avfilter_deps "swresample"
enabled elbg_filter && prepend avfilter_deps "avcodec"
enabled find_rect_filter&& prepend avfilter_deps "avformat avcodec"
-enabled firequalizer_filter && prepend avfilter_deps "avcodec"
enabled mcdeint_filter && prepend avfilter_deps "avcodec"
enabled movie_filter&& prepend avfilter_deps "avformat avcodec"
enabled pan_filter && prepend avfilter_deps "swresample"
diff --git a/libavfilter/af_firequalizer.c b/libavfilter/af_firequalizer.c
index e0f35c139e..156e5e14d7 100644
--- a/libavfilter/af_firequalizer.c
+++ b/libavfilter/af_firequalizer.c
@@ -23,7 +23,7 @@
#include "libavutil/opt.h"
#include "libavutil/eval.h"
#include "libavutil/avassert.h"
-#include "libavcodec/avfft.h"
+#include "libavutil/tx.h"
#include "avfilter.h"
#include "internal.h"
#include "audio.h"
@@ -67,13 +67,20 @@ typedef struct OverlapIndex {
typedef struct FIREqualizerContext {
const AVClass *class;
-RDFTContext *analysis_rdft;
-RDFTContext *analysis_irdft;
-RDFTContext *rdft;
-RDFTContext *irdft;
-FFTContext*fft_ctx;
-RDFTContext *cepstrum_rdft;
-RDFTContext *cepstrum_irdft;
+AVTXContext *analysis_rdft;
+av_tx_fn analysis_rdft_fn;
+AVTXContext *analysis_irdft;
+av_tx_fn analysis_irdft_fn;
+AVTXContext *rdft;
+av_tx_fn rdft_fn;
+AVTXContext *irdft;
+av_tx_fn irdft_fn;
+AVTXContext *fft_ctx;
+av_tx_fn fft_fn;
+AVTXContext *cepstrum_rdft;
+av_tx_fn cepstrum_rdft_fn;
+AVTXContext *cepstrum_irdft;
+av_tx_fn cepstrum_irdft_fn;
int analysis_rdft_len;
int rdft_len;
int cepstrum_len;
@@ -151,13 +158,13 @@ AVFILTER_DEFINE_CLASS(firequalizer);
static void common_uninit(FIREqualizerContext *s)
{
-av_rdft_end(s->analysis_rdft);
-av_rdft_end(s->analysis_irdft);
-av_rdft_end(s->rdft);
-av_rdft_end(s->irdft);
-av_fft_end(s->fft_ctx);
-av_rdft_end(s->cepstrum_rdft);
-av_rdft_end(s->cepstrum_irdft);
+av_tx_uninit(&s->analysis_rdft);
+av_tx_uninit(&s->analysis_irdft);
+av_tx_uninit(&s->rdft);
+av_tx_uninit(&s->irdft);
+av_tx_uninit(&s->fft_ctx);
+av_tx_uninit(&s->cepstrum_rdft);
+av_tx_uninit(&s->cepstrum_irdft);
s->analysis_rdft = s->analysis_irdft = s->rdft = s->irdft = NULL;
s->fft_ctx = NULL;
s->cepstrum_rdft = NULL;
@@ -193,16 +200,14 @@ static void fast_convolute(FIREqualizerContext *av_restrict s, const float *av_r
memset(buf, 0, center * sizeof(*data));
memcpy(buf + center, data, nsamples * sizeof(*data));
memset(buf + center + nsamples, 0, (s->rdft_len - nsamples - center) * sizeof(*data));
-av_rdft_calc(s->rdft, buf);
+s->rdft_fn(s->rdft, buf, buf, sizeof(float));
-buf[0] *= kernel_buf[0];
-buf[1] *= kernel_buf[s->rdft_len/2];
-for (k = 1; k < s->rdft_len/2; k++) {
+for (k = 0; k <= s->rdft_len/2; k++) {
buf[2*k] *= kernel_buf[k];
buf[2*k+1] *= kernel_buf[k];
}
-av_rdft_calc(s->irdft, buf);
+s->irdft_fn(s->irdft, buf, buf, sizeof(float));
for (k = 0; k < s->rdft_len - idx->overlap_idx; k++)
buf[k] += obuf[k];
memcpy(data, buf, nsamples * sizeof(*data));
@@ -230,11 +235,9 @@ static void fast_convolute_nonlinear(FIREqualizerContext *av_restrict s, const f
memcpy(buf, data, nsamples * sizeof(*data));
memset(buf + nsamples, 0, (s->rdft_len - nsamples) * sizeof(*data));
-av_rdft_calc(s->rdft, buf);
+s->rdft_fn(s->rdft, buf, buf, sizeof(float));
-buf[0] *= kernel_buf[0];
-buf[1] *= kernel_buf[1];
-for (k = 2; k < s->rdft_len; k += 2) {
+for (k = 0; k <= s->rdft_len; k += 2) {
float re, im;
re = buf[k] * kernel_buf[k] - buf[k+1] * kernel_buf[k+1];
im = buf[k] *
[FFmpeg-devel] [PATCH] fftools/ffprobe: support 2D arrays in print_list_fmt()
Should fix undefined behavior.
Signed-off-by: James Almer
---
fftools/ffprobe.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 99adf615ae..f46925618c 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1897,12 +1897,14 @@ static void writer_register_all(void)
writer_print_string(w, k, pbuf.str, 0);\
} while (0)
-#define print_list_fmt(k, f, n, ...) do { \
+#define print_list_fmt(k, f, n, m, ...) do {\
av_bprint_clear(&pbuf); \
for (int idx = 0; idx < n; idx++) { \
-if (idx > 0)\
-av_bprint_chars(&pbuf, ' ', 1); \
-av_bprintf(&pbuf, f, __VA_ARGS__); \
+for (int idx2 = 0; idx2 < m; idx2++) { \
+if (idx > 0 || idx2 > 0)\
+av_bprint_chars(&pbuf, ' ', 1); \
+av_bprintf(&pbuf, f, __VA_ARGS__); \
+} \
} \
writer_print_string(w, k, pbuf.str, 0); \
} while (0)
@@ -2013,7 +2015,7 @@ static void print_dovi_metadata(WriterContext *w, const
AVDOVIMetadata *dovi)
const AVDOVIReshapingCurve *curve = &mapping->curves[c];
writer_print_section_header(w,
SECTION_ID_FRAME_SIDE_DATA_COMPONENT);
-print_list_fmt("pivots", "%"PRIu16, curve->num_pivots,
curve->pivots[idx]);
+print_list_fmt("pivots", "%"PRIu16, curve->num_pivots, 1,
curve->pivots[idx]);
writer_print_section_header(w,
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST);
for (int i = 0; i < curve->num_pivots - 1; i++) {
@@ -2025,7 +2027,7 @@ static void print_dovi_metadata(WriterContext *w, const
AVDOVIMetadata *dovi)
print_str("mapping_idc_name", "polynomial");
print_int("poly_order", curve->poly_order[i]);
print_list_fmt("poly_coef", "%"PRIi64,
- curve->poly_order[i] + 1,
+ curve->poly_order[i] + 1, 1,
curve->poly_coef[i][idx]);
break;
case AV_DOVI_MAPPING_MMR:
@@ -2033,8 +2035,8 @@ static void print_dovi_metadata(WriterContext *w, const
AVDOVIMetadata *dovi)
print_int("mmr_order", curve->mmr_order[i]);
print_int("mmr_constant", curve->mmr_constant[i]);
print_list_fmt("mmr_coef", "%"PRIi64,
- curve->mmr_order[i] * 7,
- curve->mmr_coef[i][0][idx]);
+ curve->mmr_order[i], 7,
+ curve->mmr_coef[i][idx][idx2]);
break;
default:
print_str("mapping_idc_name", "unknown");
@@ -2072,15 +2074,15 @@ static void print_dovi_metadata(WriterContext *w, const
AVDOVIMetadata *dovi)
print_int("dm_metadata_id", color->dm_metadata_id);
print_int("scene_refresh_flag", color->scene_refresh_flag);
print_list_fmt("ycc_to_rgb_matrix", "%d/%d",
- FF_ARRAY_ELEMS(color->ycc_to_rgb_matrix),
+ FF_ARRAY_ELEMS(color->ycc_to_rgb_matrix), 1,
color->ycc_to_rgb_matrix[idx].num,
color->ycc_to_rgb_matrix[idx].den);
print_list_fmt("ycc_to_rgb_offset", "%d/%d",
- FF_ARRAY_ELEMS(color->ycc_to_rgb_offset),
+ FF_ARRAY_ELEMS(color->ycc_to_rgb_offset), 1,
color->ycc_to_rgb_offset[idx].num,
color->ycc_to_rgb_offset[idx].den);
print_list_fmt("rgb_to_lms_matrix", "%d/%d",
- FF_ARRAY_ELEMS(color->rgb_to_lms_matrix),
+ FF_ARRAY_ELEMS(color->rgb_to_lms_matrix), 1,
color->rgb_to_lms_matrix[idx].num,
color->rgb_to_lms_matrix[idx].den);
print_int("signal_eotf",color->signal_eotf);
--
2.38.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] [Internet][PATCH 00/12] Add MediaCodec encoder and NDK MediaCodec support
> From: ffmpeg-devel On Behalf Of Olivier > Ayache > Sent: 2022年11月12日 18:00 > To: FFmpeg development discussions and patches > Cc: matthieu.bou...@stupeflix.com; a...@tmm1.net > Subject: Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec encoder > and NDK MediaCodec support > > Hello there I implemented that few years ago in > https://github.com/olivierayache/xuggle-xuggler/ I can't find where is the patch or source code of FFmpeg. > And when I tried to submit a patch to FFmpeg for add support for NDK I had > received this answer. > I think using NDK directly rather than JNI can be better in case of > developing native application on Android. NDK is still missing some important features, and some features only supported recently. So the NDK implementation doesn't meant to be a replacement of the JNI version: 1. JNI version has more features and supports more devices 2. NDK implementation combined with some JNI functions has almost the same feature As JNI version on new devices. 3. In the environment where JVM is unavailable, the NDK version is the only choice. > If I can help on these subjects I would be really happy Welcome to review and/or test the patch. > > Olivier Ayache > > > > -- Forwarded message - > From: Olivier Ayache > Date: Sun, Jun 28, 2020 at 2:48 PM > Subject: Re: [FFmpeg-devel] [PATCH] add support to Android ndk MediaCodec > for encoding/decoding > To: > > > Thank for your replies I choose the NDK approach in order to be able to be > independant from the JVM, to maximize performance and to be sure to detect > compatibility issues (using JNI approach can compile and crash at runtime). > Concerning the version of Android it is compatible from API 21 (94% of > devices) > I agree that JNI overhead is not big but in combinaison with Xuggler it > seems to me a little weird because Xuggler (Java part) already use JNI to > interact with Xuggler (C++) and FFmpeg. If FFmpeg uses JNI in the other way > (from c to Java) it seems to me an anti pattern. > > If you think it is better to begin to use JNI I could transform my encoder > and we could discuss about NDK after > > Olivier > > > > Le sam. 27 juin 2020 à 20:55, Martin Storsjö a écrit : > > > On Sat, 27 Jun 2020, Olivier Ayache wrote: > > > > > Hi everyone this is the first time I post on this mailing list. I am > > > working since several years on a fork of Xuggler for manipulating ffmpeg > > > API with Java/Kotlin. > > > This work leads me to develop encoder and decoder based on Android NDK > > > MediaCodec. > > > > > > This work can be found on my Github repository > > > > > > https://github.com/olivierayache/xuggle-xuggler > > > > > > > > > I know that FFmpeg already integrate MediaCodec for decoding via Jni > > > wrappers since version 3.1. I began this work on FFmpeg 2.8.x and I > > choose > > > the NDK in order to achieve optimum performance. > > > > If you mean you used the NDK MediaCodec API, I'd suggest you use the same > > JNI wrappers as ffmpeg has already, for consistency. The overhead of a few > > JNI calls per encoded frame is generally negligible. If it, at a later > > time, is decided to drop support for older versions at some point, it > > should be straightforward to convert it to use the NDK MediaCodec API > > instead. > > > > // Martin > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > On Sat, Nov 12, 2022 at 6:07 AM Zhao Zhili wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of Chema > > Gonzalez > > > Sent: 2022年11月12日 0:55 > > > To: FFmpeg development discussions and patches > > > Cc: matthieu.bou...@stupeflix.com; a...@tmm1.net > > > Subject: Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec > > encoder and NDK MediaCodec support > > > > > > On Thu, Nov 10, 2022 at 7:36 PM "zhilizhao(赵志立)" > > wrote: > > > > > > > > Ping for review. > > > > > > > > > On Oct 24, 2022, at 11:16, Zhao Zhili > > wrote: > > > > > > > > > > From: Zhao Zhili > > > > > > > > > > Firstly, some bugs were fixed (patch 1-4). > > > > > > > > > > Patch 5 and 6 make mediacodec_wrapper support Java MediaCodec and NDK > > > > > MediaCodec. The use case I'm considering is run FFmpeg on cmdline > > without JVM, > > > > > for example, run FFmpeg inside of termux (an Android terminal > > emulator). It's > > > > > well known that NDK MediaCodec missing some important functions, > > like get the > > > > > list of codecs, but still useable. > > > > > > > > > > Patch 7 add NDK MediaCodec decoder support. It can be enabled via > > options, > > > > > and enabled automatically if no JVM is available. > > > > > > > > > > Patch 8 add ANativeWindow support to hwcontext_mediacodec. It can be > > set by > > > > > user, and can be cre
