Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency
On Tue, Mar 10, 2020 at 05:36:40PM +0800, Jianhui Dai wrote: > Avoid constant N frames latency in video streaming. > > Signed-off-by: Jianhui Dai > --- > libavcodec/pthread_frame.c | 17 ++--- > 1 file changed, 2 insertions(+), 15 deletions(-) This patch causes segfaults ./ffmpeg_g -i tickets/466/Brazil.ts -t 3 random.avi Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault. 0x55e64a5d in submit_packet (p=0x578c5e80, user_avctx=0x5787fac0, avpkt=0x57845340) at libavcodec/pthread_frame.c:380 380 PerThreadContext *prev_thread = fctx->prev_thread; (gdb) bt #0 0x55e64a5d in submit_packet (p=0x578c5e80, user_avctx=0x5787fac0, avpkt=0x57845340) at libavcodec/pthread_frame.c:380 #1 0x55e64fea in ff_thread_decode_frame (avctx=0x5787fac0, picture=0x57845080, got_picture_ptr=0x7fffd344, avpkt=0x57845340) at libavcodec/pthread_frame.c:486 #2 0x55bc5431 in decode_simple_internal (avctx=0x5787fac0, frame=0x57845080) at libavcodec/decode.c:430 #3 0x55bc6050 in decode_simple_receive_frame (avctx=0x5787fac0, frame=0x57845080) at libavcodec/decode.c:628 #4 0x55bc6120 in decode_receive_frame_internal (avctx=0x5787fac0, frame=0x57845080) at libavcodec/decode.c:646 #5 0x55bc6380 in avcodec_send_packet (avctx=0x5787fac0, avpkt=0x7fffd530) at libavcodec/decode.c:704 #6 0x55694420 in decode (avctx=0x5787fac0, frame=0x57906280, got_frame=0x7fffd67c, pkt=0x7fffd530) at fftools/ffmpeg.c:2232 #7 0x55694cd0 in decode_video (ist=0x578f6900, pkt=0x7fffd6c0, got_output=0x7fffd67c, duration_pts=0x7fffd6b8, eof=0, decode_failed=0x7fffd680) at fftools/ffmpeg.c:2374 #8 0x55695dbd in process_input_packet (ist=0x578f6900, pkt=0x7fffd900, no_eof=0) at fftools/ffmpeg.c:2615 #9 0x5569d74a in process_input (file_index=0) at fftools/ffmpeg.c:4509 #10 0x5569dd0b in transcode_step () at fftools/ffmpeg.c:4629 #11 0x5569de88 in transcode () at fftools/ffmpeg.c:4683 #12 0x5569e7ae in main (argc=6, argv=0x7fffe268) at fftools/ffmpeg.c:4885 https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket466/ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. 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/4] avcodec/encode: restructure the core encoding code
Quoting James Almer (2020-02-27 19:02:00)
> This commit follows the same logic as 061a0c14bb, but for the encode API: The
> new public encoding API will no longer be a wrapper around the old deprecated
> one, and the internal API used by the encoders now consists of a single
> receive_packet() callback that pulls frames as required.
>
> Signed-off-by: James Almer
> ---
> libavcodec/avcodec.h | 12 +-
> libavcodec/encode.c | 268 --
> libavcodec/encode.h | 39 ++
> libavcodec/internal.h | 7 +-
> libavcodec/utils.c| 12 +-
> 5 files changed, 268 insertions(+), 70 deletions(-)
> create mode 100644 libavcodec/encode.h
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> +static int encode_simple_internal(AVCodecContext *avctx, AVPacket *avpkt)
> +{
> +AVCodecInternal *avci = avctx->internal;
> +EncodeSimpleContext *es = &avci->es;
> +AVFrame *frame = es->in_frame;
> +AVFrame *padded_frame = NULL;
> +int got_packet;
> int ret;
> -*got_packet = 0;
>
> -av_packet_unref(avctx->internal->buffer_pkt);
> -avctx->internal->buffer_pkt_valid = 0;
> +if (!frame->buf[0] && !avci->draining) {
> +av_frame_unref(frame);
> +ret = ff_encode_get_frame(avctx, frame);
> +if (ret < 0 && ret != AVERROR_EOF)
> +return ret;
> +}
>
> -if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
> -ret = avcodec_encode_video2(avctx, avctx->internal->buffer_pkt,
> -frame, got_packet);
> -} else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
> -ret = avcodec_encode_audio2(avctx, avctx->internal->buffer_pkt,
> -frame, got_packet);
> -} else {
> -ret = AVERROR(EINVAL);
> +if (avci->draining_done)
> +return AVERROR_EOF;
nit: this check would be better at the top of the function, since it
shouldn't interact with the block above
> +
> +if (!frame->buf[0]) {
> +if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
> + avctx->active_thread_type & FF_THREAD_FRAME))
> +return AVERROR_EOF;
> +
> +// Flushing is signaled with a NULL frame
> +frame = NULL;
> +}
> +
> +got_packet = 0;
> +
> +if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> +if ((avctx->flags & AV_CODEC_FLAG_PASS1) && avctx->stats_out)
> +avctx->stats_out[0] = '\0';
> +
> +if (av_image_check_size2(avctx->width, avctx->height,
> avctx->max_pixels, AV_PIX_FMT_NONE, 0, avctx)) {
> +ret = AVERROR(EINVAL);
> +goto end;
> +}
> +if (frame) {
> +if (frame->format == AV_PIX_FMT_NONE)
> +av_log(avctx, AV_LOG_WARNING, "AVFrame.format is not set\n");
> +if (frame->width == 0 || frame->height == 0)
> +av_log(avctx, AV_LOG_WARNING, "AVFrame.width or height is
> not set\n");
> +}
> +} else if (frame && avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
> +/* extract audio service type metadata */
> +AVFrameSideData *sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_AUDIO_SERVICE_TYPE);
> +if (sd && sd->size >= sizeof(enum AVAudioServiceType))
> +avctx->audio_service_type = *(enum AVAudioServiceType*)sd->data;
> +
> +/* check for valid frame size */
> +if (avctx->codec->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME) {
> +if (frame->nb_samples > avctx->frame_size) {
> +av_log(avctx, AV_LOG_ERROR, "more samples than frame size
> (avcodec_encode_audio2)\n");
> +ret = AVERROR(EINVAL);
> +goto end;
> +}
> +} else if (!(avctx->codec->capabilities &
> AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
> +/* if we already got an undersized frame, that must have been
> the last */
> +if (avctx->internal->last_audio_frame) {
> +av_log(avctx, AV_LOG_ERROR, "frame_size (%d) was not
> respected for a non-last frame (avcodec_encode_audio2)\n", avctx->frame_size);
> +ret = AVERROR(EINVAL);
> +goto end;
> +}
> +
> +if (frame->nb_samples < avctx->frame_size) {
> +ret = pad_last_frame(avctx, &padded_frame, frame);
> +if (ret < 0)
> +goto end;
> +
> +av_frame_unref(frame);
> +frame = padded_frame;
> +avctx->internal->last_audio_frame = 1;
> +}
> +
> +if (frame->nb_samples != avctx->frame_size) {
> +av_log(avctx, AV_LOG_ERROR, "nb_samples (%d) != frame_size
> (%d) (avcodec_encode_audio2)\n", frame->nb_samples, avctx->frame_size);
> +ret = AVERROR(EINVAL);
> +goto end;
> +}
> +}
> +}
Nothing about this block looks specific to the simple enco
[FFmpeg-devel] [PATCH] lavc/vp9: fix reference frame dimensions check
With the description in frame size with refs semantics (SPEC 7.2.5),
it is a requirement of bitstream conformance that for at least one
reference frame has the valid dimensions.
Modify the check to make sure the decoder works well in the condition
that not all references frames have valid dimensions.
Signed-off-by: Linjie Fu
---
Fix the the decoding faiure for frames with dimension-ilegal refs.
Verifying with native vp9 and libvpx-vp9 decoder, the md5 result matches.
https://github.com/webmproject/libvpx/blob/master/vp9/decoder/vp9_decodeframe.c#L1580
libavcodec/vp9.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 7aaae9b..61d60ef 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -794,6 +794,7 @@ static int decode_frame_header(AVCodecContext *avctx,
/* check reference frames */
if (!s->s.h.keyframe && !s->s.h.intraonly) {
+int valid_ref_frame = 0;
for (i = 0; i < 3; i++) {
AVFrame *ref = s->s.refs[s->s.h.refidx[i]].f;
int refw = ref->width, refh = ref->height;
@@ -807,18 +808,23 @@ static int decode_frame_header(AVCodecContext *avctx,
} else if (refw == w && refh == h) {
s->mvscale[i][0] = s->mvscale[i][1] = 0;
} else {
+/* Check to make sure at least one of frames that */
+/* this frame references has valid dimensions. */
if (w * 2 < refw || h * 2 < refh || w > 16 * refw || h > 16 *
refh) {
-av_log(avctx, AV_LOG_ERROR,
+av_log(avctx, AV_LOG_WARNING,
"Invalid ref frame dimensions %dx%d for frame size
%dx%d\n",
refw, refh, w, h);
-return AVERROR_INVALIDDATA;
+continue;
}
s->mvscale[i][0] = (refw << 14) / w;
s->mvscale[i][1] = (refh << 14) / h;
s->mvstep[i][0] = 16 * s->mvscale[i][0] >> 14;
s->mvstep[i][1] = 16 * s->mvscale[i][1] >> 14;
}
+valid_ref_frame++;
}
+if (!valid_ref_frame)
+return AVERROR_INVALIDDATA;
}
if (s->s.h.keyframe || s->s.h.errorres || (s->s.h.intraonly &&
s->s.h.resetctx == 3)) {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/qsvenc_hevc: add qmax/qmin support for HEVC encoding
Add qmax/qmin support for HEVC software bitrate control(SWBRC).
Limitations:
- RateControlMethod != MFX_RATECONTROL_CQP
- with EXTBRC ON
Signed-off-by: Dmitry Rogozhkin
Signed-off-by: Linjie Fu
---
Relative code in MSDK for the limitation:
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/encode_hw/hevc/agnostic/g9/hevcehw_g9_legacy.cpp#L4267
libavcodec/qsvenc.c | 11 +--
libavcodec/qsvenc_hevc.c | 2 ++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 52b4e43..2c22eb7 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -732,6 +732,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (q->adaptive_b >= 0)
q->extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
#endif
+}
+
+if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
AV_CODEC_ID_HEVC) {
+if (q->extbrc >= 0)
+q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
#if QSV_VERSION_ATLEAST(1, 9)
if (avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
avctx->qmax) {
@@ -747,12 +752,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
q->extco2.MaxQPP = q->extco2.MaxQPB = q->extco2.MaxQPI;
}
#endif
-}
-
-if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
AV_CODEC_ID_HEVC) {
-if (q->extbrc >= 0)
-q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
-
q->extco2.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2;
q->extco2.Header.BufferSz = sizeof(q->extco2);
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 27e2232..3bdca7d 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -262,6 +262,8 @@ static const AVCodecDefault qsv_enc_defaults[] = {
// same as the x264 default
{ "g", "248" },
{ "bf","8" },
+{ "qmin", "-1"},
+{ "qmax", "-1"},
{ "trellis", "-1"},
{ "flags", "+cgop" },
#if FF_API_PRIVATE_OPT
--
2.7.4
___
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] lavc/vp9: fix reference frame dimensions check
Am Mi., 11. März 2020 um 11:44 Uhr schrieb Linjie Fu : > > With the description in frame size with refs semantics (SPEC 7.2.5), > it is a requirement of bitstream conformance that for at least one > reference frame has the valid dimensions. > > Modify the check to make sure the decoder works well in the condition > that not all references frames have valid dimensions. > > Signed-off-by: Linjie Fu > --- > Fix the the decoding faiure for frames with dimension-ilegal refs. > Verifying with native vp9 and libvpx-vp9 decoder, the md5 result matches. > https://github.com/webmproject/libvpx/blob/master/vp9/decoder/vp9_decodeframe.c#L1580 Did you provide a sample? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/5] doc/general.texi: AviSynth+ works on Linux now, AvxSynth is gone.
---
doc/general.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/general.texi b/doc/general.texi
index 87eaad7791..e92de9d954 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -58,8 +58,8 @@ For Windows, supported AviSynth variants are
@url{http://avisynth.nl, AviSynth 2.6 RC1 or higher} for 32-bit builds and
@url{http://avisynth.nl/index.php/AviSynth+, AviSynth+ r1718 or higher} for
32-bit and 64-bit builds.
-For Linux and OS X, the supported AviSynth variant is
-@url{https://github.com/avxsynth/avxsynth, AvxSynth}.
+For Linux and OS X, the only supported AviSynth variant is
+@url{https://github.com/AviSynth/AviSynthPlus, AviSynth+}, starting with
version 3.5.
@float NOTE
In 2016, AviSynth+ added support for building with GCC. However, due to
@@ -77,9 +77,9 @@ GCC builds of AviSynth+ without any special flags.
@end float
@float NOTE
-AviSynth and AvxSynth are loaded dynamically. Distributors can build FFmpeg
+AviSynth(+) is loaded dynamically. Distributors can build FFmpeg
with @code{--enable-avisynth}, and the binaries will work regardless of the
-end user having AviSynth or AvxSynth installed - they'll only need to be
+end user having AviSynth installed - they'll only need to be
installed to use AviSynth scripts (obviously).
@end float
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/5] Switch from AvxSynth to AviSynth+ on non-Windows
Since there were no responses to my question about whether we should use a warning message about AvxSynth's deprecation before switching over at a later time, or to just do the switch immediately, I've gone ahead and sent just the switchover patch. Stephen Hutchinson (5): compat/avisynth: update headers avisynth: switch to AviSynth+ on Linux compat/avisynth: remove AvxSynth headers doc/general.texi: AviSynth+ works on Linux now, AvxSynth is gone. avisynth: fix deprecation warning compat/avisynth/avisynth_c.h | 24 +- compat/avisynth/avs/capi.h| 16 + compat/avisynth/avs/config.h | 46 +- compat/avisynth/avs/posix.h | 111 +++ compat/avisynth/avs/types.h | 13 +- compat/avisynth/avxsynth_c.h | 728 -- .../windowsPorts/basicDataTypeConversions.h | 85 -- compat/avisynth/windowsPorts/windows2linux.h | 77 -- doc/general.texi | 8 +- libavformat/avisynth.c| 58 +- 10 files changed, 205 insertions(+), 961 deletions(-) create mode 100644 compat/avisynth/avs/posix.h delete mode 100644 compat/avisynth/avxsynth_c.h delete mode 100644 compat/avisynth/windowsPorts/basicDataTypeConversions.h delete mode 100644 compat/avisynth/windowsPorts/windows2linux.h -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/5] compat/avisynth: update headers
AviSynth+ can now be used on Linux, which required some changes
to the headers.
---
compat/avisynth/avisynth_c.h | 24
compat/avisynth/avs/capi.h | 16 +
compat/avisynth/avs/config.h | 46 +--
compat/avisynth/avs/posix.h | 111 +++
compat/avisynth/avs/types.h | 13 ++--
5 files changed, 185 insertions(+), 25 deletions(-)
create mode 100644 compat/avisynth/avs/posix.h
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 9ff9321552..03c3530ca9 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -341,7 +341,7 @@ typedef struct AVS_VideoInfo {
int audio_samples_per_second; // 0 means no audio
int sample_type;
- INT64 num_audio_samples;
+ int64_t num_audio_samples;
int nchannels;
// Image type properties
@@ -444,16 +444,16 @@ AVSC_INLINE int avs_bytes_per_channel_sample(const
AVS_VideoInfo * p)
AVSC_INLINE int avs_bytes_per_audio_sample(const AVS_VideoInfo * p)
{ return p->nchannels*avs_bytes_per_channel_sample(p);}
-AVSC_INLINE INT64 avs_audio_samples_from_frames(const AVS_VideoInfo * p, INT64
frames)
-{ return ((INT64)(frames) * p->audio_samples_per_second *
p->fps_denominator / p->fps_numerator); }
+AVSC_INLINE int64_t avs_audio_samples_from_frames(const AVS_VideoInfo * p,
int64_t frames)
+{ return ((int64_t)(frames) * p->audio_samples_per_second *
p->fps_denominator / p->fps_numerator); }
-AVSC_INLINE int avs_frames_from_audio_samples(const AVS_VideoInfo * p, INT64
samples)
-{ return (int)(samples * (INT64)p->fps_numerator /
(INT64)p->fps_denominator / (INT64)p->audio_samples_per_second); }
+AVSC_INLINE int avs_frames_from_audio_samples(const AVS_VideoInfo * p, int64_t
samples)
+{ return (int)(samples * (int64_t)p->fps_numerator /
(int64_t)p->fps_denominator / (int64_t)p->audio_samples_per_second); }
-AVSC_INLINE INT64 avs_audio_samples_from_bytes(const AVS_VideoInfo * p, INT64
bytes)
+AVSC_INLINE int64_t avs_audio_samples_from_bytes(const AVS_VideoInfo * p,
int64_t bytes)
{ return bytes / avs_bytes_per_audio_sample(p); }
-AVSC_INLINE INT64 avs_bytes_from_audio_samples(const AVS_VideoInfo * p, INT64
samples)
+AVSC_INLINE int64_t avs_bytes_from_audio_samples(const AVS_VideoInfo * p,
int64_t samples)
{ return samples * avs_bytes_per_audio_sample(p); }
AVSC_INLINE int avs_audio_channels(const AVS_VideoInfo * p)
@@ -764,7 +764,7 @@ AVSC_API(int, avs_get_parity)(AVS_Clip *, int n);
// return field parity if field_based, else parity of first field in frame
AVSC_API(int, avs_get_audio)(AVS_Clip *, void * buf,
- INT64 start, INT64 count);
+ int64_t start, int64_t count);
// start and count are in samples
AVSC_API(int, avs_set_cache_hints)(AVS_Clip *,
@@ -784,7 +784,7 @@ struct AVS_FilterInfo
AVS_VideoFrame * (AVSC_CC * get_frame)(AVS_FilterInfo *, int n);
int (AVSC_CC * get_parity)(AVS_FilterInfo *, int n);
int (AVSC_CC * get_audio)(AVS_FilterInfo *, void * buf,
- INT64 start, INT64 count);
+ int64_t start, int64_t count);
int (AVSC_CC * set_cache_hints)(AVS_FilterInfo *, int cachehints,
int frame_range);
void (AVSC_CC * free_filter)(AVS_FilterInfo *);
@@ -933,6 +933,8 @@ AVSC_API(void,
avs_delete_script_environment)(AVS_ScriptEnvironment *);
AVSC_API(AVS_VideoFrame *, avs_subframe_planar)(AVS_ScriptEnvironment *,
AVS_VideoFrame * src, int rel_offset, int new_pitch, int new_row_size, int
new_height, int rel_offsetU, int rel_offsetV, int new_pitchUV);
// The returned video frame must be be released
+#if defined(AVS_WINDOWS)
+// The following stuff is only relevant for Windows DLL handling; Linux does
it completely differently.
#ifdef AVSC_NO_DECLSPEC
// This part uses LoadLibrary and related functions to dynamically load
Avisynth instead of declspec(dllimport)
// When AVSC_NO_DECLSPEC is defined, you can use avs_load_library to populate
API functions into a struct
@@ -944,7 +946,7 @@ AVSC_API(AVS_VideoFrame *,
avs_subframe_planar)(AVS_ScriptEnvironment *, AVS_Vid
void* malloc(size_t)
void free(void*);
- HMODULE LoadLibrary(const char*);
+ HMODULE LoadLibraryA(const char*);
void* GetProcAddress(HMODULE, const char*);
FreeLibrary(HMODULE);
*/
@@ -1261,4 +1263,6 @@ AVSC_INLINE void avs_free_library(AVS_Library *library) {
}
#endif
+#endif // AVS_WINDOWS
+
#endif
diff --git a/compat/avisynth/avs/capi.h b/compat/avisynth/avs/capi.h
index 8799bf1fbb..4e31a5de48 100644
--- a/compat/avisynth/avs/capi.h
+++ b/compat/avisynth/avs/capi.h
@@ -33,12 +33,20 @@
#ifndef AVS_CAPI_H
#define AVS_CAPI_H
+#include "config.h"
+
+#ifdef AVS_POSIX
+// this is also defined in avs/posix.h
+#define __declspec(x)
+#endif
+
#ifdef __cplusplus
# define EXTERN_C extern "C"
#else
# define EXTERN_C
[FFmpeg-devel] [PATCH 5/5] avisynth: fix deprecation warning
--- libavformat/avisynth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c index 1970553e49..f3e8df933f 100644 --- a/libavformat/avisynth.c +++ b/libavformat/avisynth.c @@ -555,7 +555,7 @@ static int avisynth_open_file(AVFormatContext *s) #ifdef _WIN32 /* Convert UTF-8 to ANSI code page */ -MultiByteToWideChar(CP_UTF8, 0, s->filename, -1, filename_wc, MAX_PATH * 4); +MultiByteToWideChar(CP_UTF8, 0, s->url, -1, filename_wc, MAX_PATH * 4); WideCharToMultiByte(CP_THREAD_ACP, 0, filename_wc, -1, filename_ansi, MAX_PATH * 4, NULL, NULL); arg = avs_new_value_string(filename_ansi); -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/5] avisynth: switch to AviSynth+ on Linux
AviSynth+ now supports non-Windows OSes, making AvxSynth
obsolete. Since we no longer support AviSynth 2.5 (which is
essentially what AvxSynth is), remove AvxSynth support and
replace it with AviSynth+.
As a result, the USING_AVISYNTH defines can be switched back
to generic _WIN32.
---
libavformat/avisynth.c | 56 +++---
1 file changed, 15 insertions(+), 41 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 55a2efd884..1970553e49 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -1,5 +1,5 @@
/*
- * AviSynth/AvxSynth support
+ * AviSynth(+) support
* Copyright (c) 2012 AvxSynth Team
*
* This file is part of FFmpeg
@@ -31,20 +31,19 @@
/* Enable function pointer definitions for runtime loading. */
#define AVSC_NO_DECLSPEC
-/* Platform-specific directives for AviSynth vs AvxSynth. */
+/* Platform-specific directives. */
#ifdef _WIN32
#include "compat/w32dlfcn.h"
#undef EXTERN_C
- #include "compat/avisynth/avisynth_c.h"
#define AVISYNTH_LIB "avisynth"
- #define USING_AVISYNTH
#else
#include
- #include "compat/avisynth/avxsynth_c.h"
- #define AVISYNTH_NAME "libavxsynth"
+ #define AVISYNTH_NAME "libavisynth"
#define AVISYNTH_LIB AVISYNTH_NAME SLIBSUF
#endif
+#include "compat/avisynth/avisynth_c.h"
+
typedef struct AviSynthLibrary {
void *library;
#define AVSC_DECLARE_FUNC(name) name ## _func name
@@ -62,7 +61,6 @@ typedef struct AviSynthLibrary {
AVSC_DECLARE_FUNC(avs_release_value);
AVSC_DECLARE_FUNC(avs_release_video_frame);
AVSC_DECLARE_FUNC(avs_take_clip);
-#ifdef USING_AVISYNTH
AVSC_DECLARE_FUNC(avs_bits_per_pixel);
AVSC_DECLARE_FUNC(avs_get_height_p);
AVSC_DECLARE_FUNC(avs_get_pitch_p);
@@ -70,7 +68,6 @@ typedef struct AviSynthLibrary {
AVSC_DECLARE_FUNC(avs_get_row_size_p);
AVSC_DECLARE_FUNC(avs_is_planar_rgb);
AVSC_DECLARE_FUNC(avs_is_planar_rgba);
-#endif
#undef AVSC_DECLARE_FUNC
} AviSynthLibrary;
@@ -97,14 +94,12 @@ static const int avs_planes_packed[1] = { 0 };
static const int avs_planes_grey[1] = { AVS_PLANAR_Y };
static const int avs_planes_yuv[3]= { AVS_PLANAR_Y, AVS_PLANAR_U,
AVS_PLANAR_V };
-#ifdef USING_AVISYNTH
static const int avs_planes_rgb[3]= { AVS_PLANAR_G, AVS_PLANAR_B,
AVS_PLANAR_R };
static const int avs_planes_yuva[4] = { AVS_PLANAR_Y, AVS_PLANAR_U,
AVS_PLANAR_V, AVS_PLANAR_A };
static const int avs_planes_rgba[4] = { AVS_PLANAR_G, AVS_PLANAR_B,
AVS_PLANAR_R, AVS_PLANAR_A };
-#endif
/* A conflict between C++ global objects, atexit, and dynamic loading requires
* us to register our own atexit handler to prevent double freeing. */
@@ -142,7 +137,6 @@ static av_cold int avisynth_load_library(void)
LOAD_AVS_FUNC(avs_release_value, 0);
LOAD_AVS_FUNC(avs_release_video_frame, 0);
LOAD_AVS_FUNC(avs_take_clip, 0);
-#ifdef USING_AVISYNTH
LOAD_AVS_FUNC(avs_bits_per_pixel, 1);
LOAD_AVS_FUNC(avs_get_height_p, 1);
LOAD_AVS_FUNC(avs_get_pitch_p, 1);
@@ -150,7 +144,6 @@ static av_cold int avisynth_load_library(void)
LOAD_AVS_FUNC(avs_get_row_size_p, 1);
LOAD_AVS_FUNC(avs_is_planar_rgb, 1);
LOAD_AVS_FUNC(avs_is_planar_rgba, 1);
-#endif
#undef LOAD_AVS_FUNC
atexit(avisynth_atexit_handler);
@@ -249,7 +242,6 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
avpriv_set_pts_info(st, 32, avs->vi->fps_denominator,
avs->vi->fps_numerator);
switch (avs->vi->pixel_type) {
-#ifdef USING_AVISYNTH
/* 10~16-bit YUV pix_fmts (AviSynth+) */
case AVS_CS_YUV444P10:
st->codecpar->format = AV_PIX_FMT_YUV444P10;
@@ -434,8 +426,7 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
case AVS_CS_BGR64:
st->codecpar->format = AV_PIX_FMT_BGRA64;
break;
-#endif
-/* AviSynth 2.5 and AvxSynth pix_fmts */
+/* AviSynth 2.5 pix_fmts */
case AVS_CS_BGR24:
st->codecpar->format = AV_PIX_FMT_BGR24;
break;
@@ -461,7 +452,6 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
}
switch (planar) {
-#ifdef USING_AVISYNTH
case 5: // Planar RGB + Alpha
avs->n_planes = 4;
avs->planes = avs_planes_rgba;
@@ -474,7 +464,6 @@ static int avisynth_create_stream_video(AVFormatContext *s,
AVStream *st)
avs->n_planes = 3;
avs->planes = avs_planes_rgb;
break;
-#endif
case 2: // Y8
avs->n_planes = 1;
avs->planes = avs_planes_grey;
@@ -556,7 +545,7 @@ static int avisynth_open_file(AVFormatContext *s)
AviSynthContext *avs = s->priv_data;
AVS_Value arg, val;
int ret;
-#ifdef USING_AVISYNTH
+#ifdef _WIN32
char filename_ansi[MAX_PATH * 4];
wchar_t filename_wc[MAX_
[FFmpeg-devel] [PATCH 3/5] compat/avisynth: remove AvxSynth headers
---
compat/avisynth/avxsynth_c.h | 728 --
.../windowsPorts/basicDataTypeConversions.h | 85 --
compat/avisynth/windowsPorts/windows2linux.h | 77 --
3 files changed, 890 deletions(-)
delete mode 100644 compat/avisynth/avxsynth_c.h
delete mode 100644 compat/avisynth/windowsPorts/basicDataTypeConversions.h
delete mode 100644 compat/avisynth/windowsPorts/windows2linux.h
diff --git a/compat/avisynth/avxsynth_c.h b/compat/avisynth/avxsynth_c.h
deleted file mode 100644
index 991f4be1ab..00
--- a/compat/avisynth/avxsynth_c.h
+++ /dev/null
@@ -1,728 +0,0 @@
-// Avisynth C Interface Version 0.20
-// Copyright 2003 Kevin Atkinson
-
-// This program is free software; you can redistribute it and/or modify
-// it under the terms of the GNU General Public License as published by
-// the Free Software Foundation; either version 2 of the License, or
-// (at your option) any later version.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, write to the Free Software
-// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
-// MA 02110-1301 USA, or visit
-// http://www.gnu.org/copyleft/gpl.html .
-//
-// As a special exception, I give you permission to link to the
-// Avisynth C interface with independent modules that communicate with
-// the Avisynth C interface solely through the interfaces defined in
-// avisynth_c.h, regardless of the license terms of these independent
-// modules, and to copy and distribute the resulting combined work
-// under terms of your choice, provided that every copy of the
-// combined work is accompanied by a complete copy of the source code
-// of the Avisynth C interface and Avisynth itself (with the version
-// used to produce the combined work), being distributed under the
-// terms of the GNU General Public License plus this exception. An
-// independent module is a module which is not derived from or based
-// on Avisynth C Interface, such as 3rd-party filters, import and
-// export plugins, or graphical user interfaces.
-
-#ifndef __AVXSYNTH_C__
-#define __AVXSYNTH_C__
-
-#include "windowsPorts/windows2linux.h"
-#include
-
-#ifdef __cplusplus
-# define EXTERN_C extern "C"
-#else
-# define EXTERN_C
-#endif
-
-#define AVSC_USE_STDCALL 1
-
-#ifndef AVSC_USE_STDCALL
-# define AVSC_CC __cdecl
-#else
-# define AVSC_CC __stdcall
-#endif
-
-#define AVSC_INLINE static __inline
-
-#ifdef AVISYNTH_C_EXPORTS
-# define AVSC_EXPORT EXTERN_C
-# define AVSC_API(ret, name) EXTERN_C __declspec(dllexport) ret AVSC_CC name
-#else
-# define AVSC_EXPORT EXTERN_C __declspec(dllexport)
-# ifndef AVSC_NO_DECLSPEC
-#define AVSC_API(ret, name) EXTERN_C __declspec(dllimport) ret AVSC_CC name
-# else
-#define AVSC_API(ret, name) typedef ret (AVSC_CC *name##_func)
-# endif
-#endif
-
-#ifdef __GNUC__
-typedef long long int INT64;
-#else
-typedef __int64 INT64;
-#endif
-
-
-/
-//
-// Constants
-//
-
-#ifndef __AVXSYNTH_H__
-enum { AVISYNTH_INTERFACE_VERSION = 3 };
-#endif
-
-enum {AVS_SAMPLE_INT8 = 1<<0,
- AVS_SAMPLE_INT16 = 1<<1,
- AVS_SAMPLE_INT24 = 1<<2,
- AVS_SAMPLE_INT32 = 1<<3,
- AVS_SAMPLE_FLOAT = 1<<4};
-
-enum {AVS_PLANAR_Y=1<<0,
- AVS_PLANAR_U=1<<1,
- AVS_PLANAR_V=1<<2,
- AVS_PLANAR_ALIGNED=1<<3,
- AVS_PLANAR_Y_ALIGNED=AVS_PLANAR_Y|AVS_PLANAR_ALIGNED,
- AVS_PLANAR_U_ALIGNED=AVS_PLANAR_U|AVS_PLANAR_ALIGNED,
- AVS_PLANAR_V_ALIGNED=AVS_PLANAR_V|AVS_PLANAR_ALIGNED};
-
- // Colorspace properties.
-enum {AVS_CS_BGR = 1<<28,
- AVS_CS_YUV = 1<<29,
- AVS_CS_INTERLEAVED = 1<<30,
- AVS_CS_PLANAR = 1<<31};
-
- // Specific colorformats
-enum {
- AVS_CS_UNKNOWN = 0,
- AVS_CS_BGR24 = 1<<0 | AVS_CS_BGR | AVS_CS_INTERLEAVED,
- AVS_CS_BGR32 = 1<<1 | AVS_CS_BGR | AVS_CS_INTERLEAVED,
- AVS_CS_YUY2 = 1<<2 | AVS_CS_YUV | AVS_CS_INTERLEAVED,
- AVS_CS_YV12 = 1<<3 | AVS_CS_YUV | AVS_CS_PLANAR, // y-v-u, planar
- AVS_CS_I420 = 1<<4 | AVS_CS_YUV | AVS_CS_PLANAR, // y-u-v, planar
- AVS_CS_IYUV = 1<<4 | AVS_CS_YUV | AVS_CS_PLANAR // same as above
-};
-
-enum {
- AVS_IT_BFF = 1<<0,
- AVS_IT_TFF = 1<<1,
- AVS_IT_FIELDBASED = 1<<2};
-
-enum {
- AVS_FILTER_TYPE=1,
- AVS_FILTER_INPUT_COLORSPACE=2,
- AVS_FILTER_OUTPUT_TYPE=9,
- AVS_FILTER_NAME=4,
- AVS_FILTER_AUTHOR=5,
- AVS_FILTER_VERSION=6,
- AVS_FILTER_ARGS=7,
- AVS_FILTER_ARGS_INFO=8,
- AVS_FILTER_ARGS_DESCRIPTION=10,
- AVS_FILTER_DESCRIPTION=11};
-
-enum { //SUBTYPES
- AVS_FILTER_TYPE_AUDIO=1,
- AVS_FILTER_TYPE_VIDEO=2,
- AVS_FILTER_OUTPUT_TYPE_SAME=3,
- AVS_FILTER_OUTPUT_TYPE_DIFFERENT=4};
-
-enum {
- AVS_CACHE_NOTHING=0,
- AVS_CACHE_RANGE
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_hevc: add qmax/qmin support for HEVC encoding
On Wed, Mar 11, 2020 at 11:44 AM Linjie Fu wrote:
> Add qmax/qmin support for HEVC software bitrate control(SWBRC).
>
> Limitations:
> - RateControlMethod != MFX_RATECONTROL_CQP
> - with EXTBRC ON
>
> Signed-off-by: Dmitry Rogozhkin
> Signed-off-by: Linjie Fu
> ---
>
> Relative code in MSDK for the limitation:
>
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/encode_hw/hevc/agnostic/g9/hevcehw_g9_legacy.cpp#L4267
>
> libavcodec/qsvenc.c | 11 +--
> libavcodec/qsvenc_hevc.c | 2 ++
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 52b4e43..2c22eb7 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -732,6 +732,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (q->adaptive_b >= 0)
> q->extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON
> : MFX_CODINGOPTION_OFF;
> #endif
> +}
> +
> +if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> AV_CODEC_ID_HEVC) {
> +if (q->extbrc >= 0)
> +q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
>
> #if QSV_VERSION_ATLEAST(1, 9)
> if (avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
> avctx->qmax) {
> @@ -747,12 +752,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
> q->extco2.MaxQPP = q->extco2.MaxQPB = q->extco2.MaxQPI;
> }
> #endif
> -}
> -
> -if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> AV_CODEC_ID_HEVC) {
> -if (q->extbrc >= 0)
> -q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
> -
> q->extco2.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2;
> q->extco2.Header.BufferSz = sizeof(q->extco2);
>
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 27e2232..3bdca7d 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -262,6 +262,8 @@ static const AVCodecDefault qsv_enc_defaults[] = {
> // same as the x264 default
> { "g", "248" },
> { "bf","8" },
> +{ "qmin", "-1"},
> +{ "qmax", "-1"},
> { "trellis", "-1"},
> { "flags", "+cgop" },
> #if FF_API_PRIVATE_OPT
> --
> 2.7.4
>
>
>
looks reasonable
regards
Max
___
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] lavc/qsv: adding DX11 support
On Tue, Mar 10, 2020 at 10:36 PM Soft Works wrote: > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Artem Galin > > Sent: Tuesday, March 10, 2020 5:10 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > > > Any comments on updated patch by link below: > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200306130954.8938- > > 1-artem.ga...@gmail.com/ > > I don't see any comments there. > > I can help commenting below: > Allow selection of a specific DXGI adapter QSV can make use only one Intel's adapter for currently available HW, if changed in the future - this comment should be addressed. > Change filters to support mfxHandlePair Filters should come in next patches, This is initial implementation which will establish base for later filters change(s). > Allow deriving from D3D11VA hw context please explain more to this comment. > [...] > > > > >> > > > > Could you help me to reproduce this unusual behavior where texture > > > > need > > > not > > > > be the same for all frames in a frames context? > > > > > > It's the default behaviour of a D3D11 frames context; it only makes a > > > single array texture when you set a fixed size at the start > > > (specifically for the decode use-case which requires a single array > > > texture). So for example d3d11 + hwupload filter will do this. > > The D3D11 hardware context needs to be extended to support non-array > texture-pools. Otherwise a significant range of graphics devices would fail > to work (practically all that don’t have drivers supporting the most > recent SDK > versions. > > preferences of ffmpeg is to keep using array-texture and therefore goal of patch to add such implementation, Current QSV HW and drivers already support array-texture, no issue here. > softworkz > regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]lavc/aarch64: Move non-neon vp9 copy functions out of neon source file
Hi! Attached patch fixes part of ticket #8565 (compilation with --disable-neon is broken on aarch64). Please comment, Carl Eugen From d96c8d26802978077d5d32b7aa2b535eca99cfea Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Wed, 11 Mar 2020 13:01:02 +0100 Subject: [PATCH] lavc/aarch64: Move non-neon vp9 copy functions out of neon source file. Fixes part of ticket #8565. --- libavcodec/aarch64/Makefile | 1 + libavcodec/aarch64/vp9mc_16bpp_neon.S | 25 - libavcodec/aarch64/vp9mc_aarch64.c| 81 +++ libavcodec/aarch64/vp9mc_neon.S | 30 -- 4 files changed, 82 insertions(+), 55 deletions(-) create mode 100644 libavcodec/aarch64/vp9mc_aarch64.c diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index 00f93bf59f..90e7210ee0 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -21,6 +21,7 @@ OBJS-$(CONFIG_VC1DSP) += aarch64/vc1dsp_init_aarch64.o OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_init.o OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9dsp_init_10bpp_aarch64.o \ aarch64/vp9dsp_init_12bpp_aarch64.o \ + aarch64/vp9mc_aarch64.o \ aarch64/vp9dsp_init_aarch64.o # ARMv8 optimizations diff --git a/libavcodec/aarch64/vp9mc_16bpp_neon.S b/libavcodec/aarch64/vp9mc_16bpp_neon.S index cac6428709..53b372c262 100644 --- a/libavcodec/aarch64/vp9mc_16bpp_neon.S +++ b/libavcodec/aarch64/vp9mc_16bpp_neon.S @@ -25,31 +25,6 @@ //const uint8_t *ref, ptrdiff_t ref_stride, //int h, int mx, int my); -function ff_vp9_copy128_aarch64, export=1 -1: -ldp x5, x6, [x2] -ldp x7, x8, [x2, #16] -stp x5, x6, [x0] -ldp x9, x10, [x2, #32] -stp x7, x8, [x0, #16] -subsw4, w4, #1 -ldp x11, x12, [x2, #48] -stp x9, x10, [x0, #32] -stp x11, x12, [x0, #48] -ldp x5, x6, [x2, #64] -ldp x7, x8, [x2, #80] -stp x5, x6, [x0, #64] -ldp x9, x10, [x2, #96] -stp x7, x8, [x0, #80] -ldp x11, x12, [x2, #112] -stp x9, x10, [x0, #96] -stp x11, x12, [x0, #112] -add x2, x2, x3 -add x0, x0, x1 -b.ne1b -ret -endfunc - function ff_vp9_avg64_16_neon, export=1 mov x5, x0 sub x1, x1, #64 diff --git a/libavcodec/aarch64/vp9mc_aarch64.c b/libavcodec/aarch64/vp9mc_aarch64.c new file mode 100644 index 00..f17a8cf04a --- /dev/null +++ b/libavcodec/aarch64/vp9mc_aarch64.c @@ -0,0 +1,81 @@ +/* + * Copyright (c) 2016 Google Inc. + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/aarch64/asm.S" + +// All public functions in this file have the following signature: +// typedef void (*vp9_mc_func)(uint8_t *dst, ptrdiff_t dst_stride, +//const uint8_t *ref, ptrdiff_t ref_stride, +//int h, int mx, int my); + +function ff_vp9_copy128_aarch64, export=1 +1: +ldp x5, x6, [x2] +ldp x7, x8, [x2, #16] +stp x5, x6, [x0] +ldp x9, x10, [x2, #32] +stp x7, x8, [x0, #16] +subsw4, w4, #1 +ldp x11, x12, [x2, #48] +stp x9, x10, [x0, #32] +stp x11, x12, [x0, #48] +ldp x5, x6, [x2, #64] +ldp x7, x8, [x2, #80] +stp x5, x6, [x0, #64] +ldp x9, x10, [x2, #96] +stp x7, x8, [x0, #80] +ldp x11, x12, [x2, #112] +stp x9, x10, [x0, #96] +stp x11, x12, [x0, #112] +add x2, x2, x3 +add x0,
[FFmpeg-devel] [PATCH]lavc/aarch64: Fix compilation with --disable-neon
Hi!
Attached patch fixes the remaining part of ticket #8565.
Please comment, Carl Eugen
From c6451d3e57eca639e0272609fd817bf22390111e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Wed, 11 Mar 2020 13:16:47 +0100
Subject: [PATCH] lavc/aarch64: Fix compilation with --disable-neon
Fixes ticket #8565.
---
libavcodec/aarch64/Makefile | 4 ++--
libavcodec/aarch64/idctdsp_init_aarch64.c | 6 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 00f93bf59f..aa0b6e5488 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -6,6 +6,7 @@ OBJS-$(CONFIG_H264DSP) += aarch64/h264dsp_init_aarch64.o
OBJS-$(CONFIG_H264PRED) += aarch64/h264pred_init.o
OBJS-$(CONFIG_H264QPEL) += aarch64/h264qpel_init_aarch64.o
OBJS-$(CONFIG_HPELDSP) += aarch64/hpeldsp_init_aarch64.o
+OBJS-$(CONFIG_IDCTDSP) += aarch64/idctdsp_init_aarch64.o
OBJS-$(CONFIG_MPEGAUDIODSP) += aarch64/mpegaudiodsp_init.o
OBJS-$(CONFIG_NEON_CLOBBER_TEST)+= aarch64/neontest.o
OBJS-$(CONFIG_VIDEODSP) += aarch64/videodsp_init.o
@@ -41,8 +42,7 @@ NEON-OBJS-$(CONFIG_H264PRED)+= aarch64/h264pred_neon.o
NEON-OBJS-$(CONFIG_H264QPEL)+= aarch64/h264qpel_neon.o \
aarch64/hpeldsp_neon.o
NEON-OBJS-$(CONFIG_HPELDSP) += aarch64/hpeldsp_neon.o
-NEON-OBJS-$(CONFIG_IDCTDSP) += aarch64/idctdsp_init_aarch64.o \
- aarch64/simple_idct_neon.o
+NEON-OBJS-$(CONFIG_IDCTDSP) += aarch64/simple_idct_neon.o
NEON-OBJS-$(CONFIG_MDCT)+= aarch64/mdct_neon.o
NEON-OBJS-$(CONFIG_MPEGAUDIODSP)+= aarch64/mpegaudiodsp_neon.o
NEON-OBJS-$(CONFIG_VP8DSP) += aarch64/vp8dsp_neon.o
diff --git a/libavcodec/aarch64/idctdsp_init_aarch64.c b/libavcodec/aarch64/idctdsp_init_aarch64.c
index 0406e60830..742a3372e3 100644
--- a/libavcodec/aarch64/idctdsp_init_aarch64.c
+++ b/libavcodec/aarch64/idctdsp_init_aarch64.c
@@ -21,6 +21,8 @@
*/
#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/arm/cpu.h"
#include "libavcodec/avcodec.h"
#include "libavcodec/idctdsp.h"
#include "idct.h"
@@ -28,7 +30,9 @@
av_cold void ff_idctdsp_init_aarch64(IDCTDSPContext *c, AVCodecContext *avctx,
unsigned high_bit_depth)
{
-if (!avctx->lowres && !high_bit_depth) {
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags) && !avctx->lowres && !high_bit_depth) {
if (avctx->idct_algo == FF_IDCT_AUTO ||
avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
avctx->idct_algo == FF_IDCT_SIMPLENEON) {
--
2.24.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]lavc/aarch64: Move non-neon vp9 copy functions out of neon source file
On Wed, 11 Mar 2020, Carl Eugen Hoyos wrote: Hi! Attached patch fixes part of ticket #8565 (compilation with --disable-neon is broken on aarch64). This looks ok to me. // 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".
Re: [FFmpeg-devel] [PATCH]lavc/aarch64: Fix compilation with --disable-neon
On Wed, 11 Mar 2020, Carl Eugen Hoyos wrote: Hi! Attached patch fixes the remaining part of ticket #8565. This looks correct. // 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".
Re: [FFmpeg-devel] [PATCH] lavc/vp9: fix reference frame dimensions check
> From: ffmpeg-devel On Behalf Of > Carl Eugen Hoyos > Sent: Wednesday, March 11, 2020 18:48 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vp9: fix reference frame > dimensions check > > Am Mi., 11. März 2020 um 11:44 Uhr schrieb Linjie Fu : > > > > With the description in frame size with refs semantics (SPEC 7.2.5), > > it is a requirement of bitstream conformance that for at least one > > reference frame has the valid dimensions. > > > > Modify the check to make sure the decoder works well in the condition > > that not all references frames have valid dimensions. > > > > Signed-off-by: Linjie Fu > > --- > > Fix the the decoding faiure for frames with dimension-ilegal refs. > > Verifying with native vp9 and libvpx-vp9 decoder, the md5 result matches. > > > https://github.com/webmproject/libvpx/blob/master/vp9/decoder/vp9_de > codeframe.c#L1580 > > Did you provide a sample? > I'd like to, but to be honest, it seems kind of hard to produce such a stream available for public (compared with setting TU depth for one frame), hence I could not promise but will try. (any hints for this?) To elaborate more, one of the failure case is a 480x272 inter frame with two refs: Ref[0]: 1920x1088 key frame, invalid; Ref[1]: 960x 544 inter frame, valid; Which reports: [vp9 @ 0x55b18d9be280] Invalid ref frame dimensions 1920x1088 for frame size 480x272 - Linjie ___ 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] lavc/qsvenc_hevc: add qmax/qmin support for HEVC encoding
> From: ffmpeg-devel On Behalf Of
> Max Dmitrichenko
> Sent: Wednesday, March 11, 2020 19:37
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_hevc: add qmax/qmin
> support for HEVC encoding
>
> On Wed, Mar 11, 2020 at 11:44 AM Linjie Fu wrote:
>
> > Add qmax/qmin support for HEVC software bitrate control(SWBRC).
> >
> > Limitations:
> > - RateControlMethod != MFX_RATECONTROL_CQP
> > - with EXTBRC ON
> >
> > Signed-off-by: Dmitry Rogozhkin
> > Signed-off-by: Linjie Fu
> > ---
> >
> > Relative code in MSDK for the limitation:
> >
> > https://github.com/Intel-Media-
> SDK/MediaSDK/blob/master/_studio/mfx_lib/encode_hw/hevc/agnostic/g9
> /hevcehw_g9_legacy.cpp#L4267
> >
> > libavcodec/qsvenc.c | 11 +--
> > libavcodec/qsvenc_hevc.c | 2 ++
> > 2 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index 52b4e43..2c22eb7 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -732,6 +732,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > if (q->adaptive_b >= 0)
> > q->extco2.AdaptiveB = q->adaptive_b ?
> MFX_CODINGOPTION_ON
> > : MFX_CODINGOPTION_OFF;
> > #endif
> > +}
> > +
> > +if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> > AV_CODEC_ID_HEVC) {
> > +if (q->extbrc >= 0)
> > +q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> > MFX_CODINGOPTION_OFF;
> >
> > #if QSV_VERSION_ATLEAST(1, 9)
> > if (avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
> > avctx->qmax) {
> > @@ -747,12 +752,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > q->extco2.MaxQPP = q->extco2.MaxQPB = q->extco2.MaxQPI;
> > }
> > #endif
> > -}
> > -
> > -if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> > AV_CODEC_ID_HEVC) {
> > -if (q->extbrc >= 0)
> > -q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> > MFX_CODINGOPTION_OFF;
> > -
> > q->extco2.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2;
> > q->extco2.Header.BufferSz = sizeof(q->extco2);
> >
> > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> > index 27e2232..3bdca7d 100644
> > --- a/libavcodec/qsvenc_hevc.c
> > +++ b/libavcodec/qsvenc_hevc.c
> > @@ -262,6 +262,8 @@ static const AVCodecDefault qsv_enc_defaults[] = {
> > // same as the x264 default
> > { "g", "248" },
> > { "bf","8" },
> > +{ "qmin", "-1"},
> > +{ "qmax", "-1"},
> > { "trellis", "-1"},
> > { "flags", "+cgop" },
> > #if FF_API_PRIVATE_OPT
> > --
> > 2.7.4
> >
> >
> >
> looks reasonable
Thanks for review.
___
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 1/7] avformat/hlsenc: Avoid setting unused variables
Andreas Rheinhardt:
> Several variables which are only used when the HLS_SINGLE_FILE flag is
> unset have been set even when this flag is set. This has been changed.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Now not moving variables into a smaller scope.
>
> libavformat/hlsenc.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index f6dd894343..51cbfba151 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2332,11 +2332,6 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
> }
>
> -if (oc->url[0]) {
> -proto = avio_find_protocol_name(oc->url);
> -use_temp_file = proto && !strcmp(proto, "file") && (hls->flags &
> HLS_TEMP_FILE);
> -}
> -
> if (hls->flags & HLS_SINGLE_FILE) {
> ret = flush_dynbuf(vs, &range_length);
> av_freep(&vs->temp_buffer);
> @@ -2345,6 +2340,12 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
> vs->size = range_length;
> } else {
> +if (oc->url[0]) {
> +proto = avio_find_protocol_name(oc->url);
> +use_temp_file = proto && !strcmp(proto, "file")
> + && (hls->flags & HLS_TEMP_FILE);
> +}
> +
> if ((hls->max_seg_size > 0 && (vs->size >= hls->max_seg_size))
> || !byterange_mode) {
> AVDictionary *options = NULL;
> char *filename = NULL;
> @@ -2394,10 +2395,9 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> av_freep(&vs->temp_buffer);
> av_freep(&filename);
> }
> -}
>
> -if (use_temp_file && !(hls->flags & HLS_SINGLE_FILE)) {
> -hls_rename_temp_file(s, oc);
> +if (use_temp_file)
> +hls_rename_temp_file(s, oc);
> }
>
> old_filename = av_strdup(oc->url);
>
Ping.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/encode: restructure the core encoding code
On 3/11/2020 7:18 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-02-27 19:02:00)
>> This commit follows the same logic as 061a0c14bb, but for the encode API: The
>> new public encoding API will no longer be a wrapper around the old deprecated
>> one, and the internal API used by the encoders now consists of a single
>> receive_packet() callback that pulls frames as required.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/avcodec.h | 12 +-
>> libavcodec/encode.c | 268 --
>> libavcodec/encode.h | 39 ++
>> libavcodec/internal.h | 7 +-
>> libavcodec/utils.c| 12 +-
>> 5 files changed, 268 insertions(+), 70 deletions(-)
>> create mode 100644 libavcodec/encode.h
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> +static int encode_simple_internal(AVCodecContext *avctx, AVPacket *avpkt)
>> +{
>> +AVCodecInternal *avci = avctx->internal;
>> +EncodeSimpleContext *es = &avci->es;
>> +AVFrame *frame = es->in_frame;
>> +AVFrame *padded_frame = NULL;
>> +int got_packet;
>> int ret;
>> -*got_packet = 0;
>>
>> -av_packet_unref(avctx->internal->buffer_pkt);
>> -avctx->internal->buffer_pkt_valid = 0;
>> +if (!frame->buf[0] && !avci->draining) {
>> +av_frame_unref(frame);
>> +ret = ff_encode_get_frame(avctx, frame);
>> +if (ret < 0 && ret != AVERROR_EOF)
>> +return ret;
>> +}
>>
>> -if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
>> -ret = avcodec_encode_video2(avctx, avctx->internal->buffer_pkt,
>> -frame, got_packet);
>> -} else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
>> -ret = avcodec_encode_audio2(avctx, avctx->internal->buffer_pkt,
>> -frame, got_packet);
>> -} else {
>> -ret = AVERROR(EINVAL);
>> +if (avci->draining_done)
>> +return AVERROR_EOF;
>
> nit: this check would be better at the top of the function, since it
> shouldn't interact with the block above
>
>> +
>> +if (!frame->buf[0]) {
>> +if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
>> + avctx->active_thread_type & FF_THREAD_FRAME))
>> +return AVERROR_EOF;
>> +
>> +// Flushing is signaled with a NULL frame
>> +frame = NULL;
>> +}
>> +
>> +got_packet = 0;
>> +
>> +if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
>> +if ((avctx->flags & AV_CODEC_FLAG_PASS1) && avctx->stats_out)
>> +avctx->stats_out[0] = '\0';
>> +
>> +if (av_image_check_size2(avctx->width, avctx->height,
>> avctx->max_pixels, AV_PIX_FMT_NONE, 0, avctx)) {
>> +ret = AVERROR(EINVAL);
>> +goto end;
>> +}
>> +if (frame) {
>> +if (frame->format == AV_PIX_FMT_NONE)
>> +av_log(avctx, AV_LOG_WARNING, "AVFrame.format is not
>> set\n");
>> +if (frame->width == 0 || frame->height == 0)
>> +av_log(avctx, AV_LOG_WARNING, "AVFrame.width or height is
>> not set\n");
>> +}
>> +} else if (frame && avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
>> +/* extract audio service type metadata */
>> +AVFrameSideData *sd = av_frame_get_side_data(frame,
>> AV_FRAME_DATA_AUDIO_SERVICE_TYPE);
>> +if (sd && sd->size >= sizeof(enum AVAudioServiceType))
>> +avctx->audio_service_type = *(enum AVAudioServiceType*)sd->data;
>> +
>> +/* check for valid frame size */
>> +if (avctx->codec->capabilities & AV_CODEC_CAP_SMALL_LAST_FRAME) {
>> +if (frame->nb_samples > avctx->frame_size) {
>> +av_log(avctx, AV_LOG_ERROR, "more samples than frame size
>> (avcodec_encode_audio2)\n");
>> +ret = AVERROR(EINVAL);
>> +goto end;
>> +}
>> +} else if (!(avctx->codec->capabilities &
>> AV_CODEC_CAP_VARIABLE_FRAME_SIZE)) {
>> +/* if we already got an undersized frame, that must have been
>> the last */
>> +if (avctx->internal->last_audio_frame) {
>> +av_log(avctx, AV_LOG_ERROR, "frame_size (%d) was not
>> respected for a non-last frame (avcodec_encode_audio2)\n",
>> avctx->frame_size);
>> +ret = AVERROR(EINVAL);
>> +goto end;
>> +}
>> +
>> +if (frame->nb_samples < avctx->frame_size) {
>> +ret = pad_last_frame(avctx, &padded_frame, frame);
>> +if (ret < 0)
>> +goto end;
>> +
>> +av_frame_unref(frame);
>> +frame = padded_frame;
>> +avctx->internal->last_audio_frame = 1;
>> +}
>> +
>> +if (frame->nb_samples != avctx->frame_size) {
>> +av_log(avctx, AV_LOG_ERROR, "nb_samples (%d) != frame_size
>> (%d) (avcodec_encode_audio2)\n", frame->nb_samples, avctx->frame_size)
Re: [FFmpeg-devel] [PATCH]lavc/aarch64: Move non-neon vp9 copy functions out of neon source file
Am Mi., 11. März 2020 um 13:35 Uhr schrieb Martin Storsjö : > > On Wed, 11 Mar 2020, Carl Eugen Hoyos wrote: > > > Hi! > > > > Attached patch fixes part of ticket #8565 (compilation with > > --disable-neon is broken on aarch64). > > This looks ok to me. Patch applied (and fixed). Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavc/aarch64: Fix compilation with --disable-neon
Am Mi., 11. März 2020 um 13:36 Uhr schrieb Martin Storsjö : > > On Wed, 11 Mar 2020, Carl Eugen Hoyos wrote: > > > Hi! > > > > Attached patch fixes the remaining part of ticket #8565. > > This looks correct. Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vp9: fix reference frame dimensions check
Am Mi., 11. März 2020 um 13:44 Uhr schrieb Fu, Linjie : > > > From: ffmpeg-devel On Behalf Of > > Carl Eugen Hoyos > > Sent: Wednesday, March 11, 2020 18:48 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vp9: fix reference frame > > dimensions check > > > > Am Mi., 11. März 2020 um 11:44 Uhr schrieb Linjie Fu : > > > > > > With the description in frame size with refs semantics (SPEC 7.2.5), > > > it is a requirement of bitstream conformance that for at least one > > > reference frame has the valid dimensions. > > > > > > Modify the check to make sure the decoder works well in the condition > > > that not all references frames have valid dimensions. > > > > > > Signed-off-by: Linjie Fu > > > --- > > > Fix the the decoding faiure for frames with dimension-ilegal refs. > > > Verifying with native vp9 and libvpx-vp9 decoder, the md5 result matches. > > > > > https://github.com/webmproject/libvpx/blob/master/vp9/decoder/vp9_de > > codeframe.c#L1580 > > > > Did you provide a sample? > > > I'd like to, but to be honest, it seems kind of hard to produce such a stream > available > for public (compared with setting TU depth for one frame), hence I could not > promise > but will try. (any hints for this?) > > To elaborate more, one of the failure case is a 480x272 inter frame with two > refs: > Ref[0]: 1920x1088 key frame, invalid; > Ref[1]: 960x 544 inter frame, valid; > > Which reports: > [vp9 @ 0x55b18d9be280] Invalid ref frame dimensions 1920x1088 for frame size > 480x272 This should be even more part of the commit message if you cannot provide a sample. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency
On 11/03/2020 03:28, Dai, Jianhui J wrote: > As reply in another thread, the sequence of output frames still follows > standard, like display order POC in H264. > Big enough frame cache can guarantee deterministic delay in some extent, but > not always (decoding time > caching time). That was my point. As an API user, I *do not want* the headache of a non-deterministic amount of delay, both from a debugging standpoint, and a usability standpoint. Purposely adding non-determinism in this way gets a NAK from me, for whatever my opinion is worth on this list... (Aside: Having a calculable and deterministic is important for frame-accurate seeking (using e.g. a packet-to-frame map), since you *cannot* just 'decode until $timestamp', since monontonic timestamps aren;t a guaranatee in reality (e.g. MPEG_-TS)). > E.g. in FF_THREAD_FRAME 4320x2160 30fps video streaming, 4 threads, the frame > caching is 99ms (33ms x 3frames) > If the cpu-decoding-execution-time is 80ms ~ 120ms (dependent on video frame > content). Also aside: It is not useful to measure frame delay in time. It's also not, IMO, maningful to use in-flight (wallclock) time. > The const frame latency cannot be met. [...] - Derek ___ 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] pthread_frame: attempt to get frame to reduce latency
On 11/03/2020 05:29, Dai, Jianhui J wrote: > Like RTSP/RTMP/DASH, the latency is variable according to network bandwidth. He is not talking about wallclock or een latency in the time domain. Latency as in 'number of packets passed in before a frame is output'. Which this patch makes both non-deterministic, and non-calculable/non-knowable. At no point does a network or even the time domain factor in, in this definition. - Derek ___ 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] configure: Add llviddsp to mvha deps
lgtm On 3/11/20, Thierry Foucu wrote: > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index 8b17134944..2d2e4d8817 100755 > --- a/configure > +++ b/configure > @@ -2790,7 +2790,7 @@ msmpeg4v3_decoder_select="h263_decoder" > msmpeg4v3_encoder_select="h263_encoder" > mss2_decoder_select="mpegvideo qpeldsp vc1_decoder" > mts2_decoder_select="mss34dsp" > -mvha_decoder_deps="zlib" > +mvha_decoder_select="llviddsp zlib" > mwsc_decoder_deps="zlib" > mxpeg_decoder_select="mjpeg_decoder" > nellymoser_decoder_select="mdct sinewin" > -- > 2.25.1.481.gfbce0eb801-goog > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/6] mpegvideo: drop an unnecessary function parameter
On Tue, Mar 10, 2020 at 06:45:58PM +0100, Anton Khirnov wrote: > It is always 0. > --- > libavcodec/mpegvideo.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle 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] pthread_frame: attempt to get frame to reduce latency
On Wed, Mar 11, 2020 at 10:28 AM Derek Buitenhuis wrote: > > E.g. in FF_THREAD_FRAME 4320x2160 30fps video streaming, 4 threads, the > > frame caching is 99ms (33ms x 3frames) > > If the cpu-decoding-execution-time is 80ms ~ 120ms (dependent on video > > frame content). > > Also aside: It is not useful to measure frame delay in time. It's also not, > IMO, maningful to use > in-flight (wallclock) time. Regardless of the actual proposed patch, I think the author's use of wallclock time to describe the problem is very reasonable. I do a large amount of work where I'm measuring "glass-to-glass" latency, where I am interested in the total pipeline (encode/network/decode), and I definitely went through the experience of trying to figure out why ffmpeg was introducing nearly 500ms of extra latency during decoding. It turned out that it was because my particular platform had 8-cores and thus 16 decoding threads and thus 15x33ms of delay, regardless of the stream complexity. You may not personally care about latency, but there are lots of people operating in a world where actual latency matters (e.g. news interviews) and they want to be able to use ffmpeg for decoding in such environments. The "problem" is not how many threads are used. The problem is "there's way too much latency" and proposed solutions include reducing the thread count or changing the heuristic for dequeuing frames from the thread pool. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency
> > Regardless of the actual proposed patch, I think the author's use of > wallclock time to describe the problem is very reasonable. I do a > large amount of work where I'm measuring "glass-to-glass" latency, > where I am interested in the total pipeline (encode/network/decode), > and I definitely went through the experience of trying to figure out > why ffmpeg was introducing nearly 500ms of extra latency during > decoding. It turned out that it was because my particular platform > had 8-cores and thus 16 decoding threads and thus 15x33ms of delay, > regardless of the stream complexity. > You shouldn't be using frame threads for this kind of application. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency
On 11/03/2020 14:53, Devin Heitmueller wrote: > Regardless of the actual proposed patch, I think the author's use of > wallclock time to describe the problem is very reasonable. I do a > large amount of work where I'm measuring "glass-to-glass" latency, > where I am interested in the total pipeline (encode/network/decode), > and I definitely went through the experience of trying to figure out > why ffmpeg was introducing nearly 500ms of extra latency during > decoding. It turned out that it was because my particular platform > had 8-cores and thus 16 decoding threads and thus 15x33ms of delay, > regardless of the stream complexity. Heavy disagree. The measurement is *specifically* referring to an API call here, and it *specifically* effects the delay, in frames. The email in question is conflating timestamps (33ms) per frame with wallclock time later on. It is not a meaningful comparison to make. Only pain lies down the path of mixing timestamps and wallclock like that. Glass-to-glass measurement is important too, but don't conflate the two. For what it's worth, I pick deterministic delay (in frames! packets-in-to-frames-out) over the possibility of less delay but non-deterministic every day of the week. For my own sanity. *Certainly* not as the default and only mode of operation. > You may not personally care about latency, but there are lots of > people operating in a world where actual latency matters (e.g. news > interviews) and they want to be able to use ffmpeg for decoding in > such environments. The "problem" is not how many threads are used. > The problem is "there's way too much latency" and proposed solutions > include reducing the thread count or changing the heuristic for > dequeuing frames from the thread pool. You are again conflating wallclock latency with frame delay latency. Having a deterministic amount of decoding delay (in frames, packets-in-to-frames-out) will certainly cause soem wallclock latency, but it *IS NOT* (N x 33ms) (or whatever timestamp your framerate causes to be the case). It is confusing and not useful to mix the two concepts like this. And again, I will choose a deterministic API every day of the week. In this case, by deterministic I mean 'the exact same code and file/stream will take the same number of packets in before outputting a frame', not 'it takes the same amount of time'. I understand It's important for some usecases to have the fastest glass-to-glass time, but it's not worth destroying the API with non-determinism to accomplish that. At the *very least* it should be behind a flag or option so people can choose to shoot their debugger in the foot by choice. But mostly I want people to stop conflating timestamps and wallclock, as well as decoding delay (in frames/packets) vs wallclock-time-toprocess. They're both important but nobody wins by mixing the two up like this. - Derek ___ 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] lavc/vp9: fix reference frame dimensions check
> From: ffmpeg-devel On Behalf Of > Carl Eugen Hoyos > Sent: Wednesday, March 11, 2020 21:42 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vp9: fix reference frame > dimensions check > > Am Mi., 11. März 2020 um 13:44 Uhr schrieb Fu, Linjie : > > > > > From: ffmpeg-devel On Behalf Of > > > Carl Eugen Hoyos > > > Sent: Wednesday, March 11, 2020 18:48 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vp9: fix reference frame > > > dimensions check > > > > > > Am Mi., 11. März 2020 um 11:44 Uhr schrieb Linjie Fu > : > > > > > > > > With the description in frame size with refs semantics (SPEC 7.2.5), > > > > it is a requirement of bitstream conformance that for at least one > > > > reference frame has the valid dimensions. > > > > > > > > Modify the check to make sure the decoder works well in the condition > > > > that not all references frames have valid dimensions. > > > > > > > > Signed-off-by: Linjie Fu > > > > --- > > > > Fix the the decoding faiure for frames with dimension-ilegal refs. > > > > Verifying with native vp9 and libvpx-vp9 decoder, the md5 result > matches. > > > > > > > > https://github.com/webmproject/libvpx/blob/master/vp9/decoder/vp9_de > > > codeframe.c#L1580 > > > > > > Did you provide a sample? > > > > > I'd like to, but to be honest, it seems kind of hard to produce such a > > stream > available > > for public (compared with setting TU depth for one frame), hence I could > not promise > > but will try. (any hints for this?) > > > > To elaborate more, one of the failure case is a 480x272 inter frame with two > refs: > > Ref[0]: 1920x1088 key frame, invalid; > > Ref[1]: 960x 544 inter frame, valid; > > > > Which reports: > > [vp9 @ 0x55b18d9be280] Invalid ref frame dimensions 1920x1088 for frame > size 480x272 > > This should be even more part of the commit message if you cannot > provide a sample. > Ok, will elaborate more in the commit message. Waiting for more comments (if there is any) before doing this, thanks - Linjie ___ 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] libavformat/matroskaenc.c: Check if we can seek before writing the end of the ebml of the segment.
Thierry Foucu:
> ---
> libavformat/matroskaenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 42f21eae8b..cf436f9e3e 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2630,7 +2630,7 @@ static int mkv_write_trailer(AVFormatContext *s)
> avio_seek(pb, currentpos, SEEK_SET);
> }
>
> -if (!mkv->is_live) {
> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && !mkv->is_live) {
> end_ebml_master(pb, mkv->segment);
> }
>
>
Why? Even if the output is unseekable, the seek to the beginning might
succeed if it happens in the output buffer (unlikely but possible). Or
do you have a specific usecase in mind where the segment should be
unknown-length?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] QP table API
On Tue, Mar 10, 2020 at 06:45:56PM +0100, Anton Khirnov wrote: > Hi, > sending a proposed new API for exporting QP tables (and possibly other > things in the future). It is based on a patch from Juan De León > (cf. <20190819233655.171637-1-jua...@google.com>). > > The set is intended for dicussion, not merging at this point. It does > not adapt the filters and thus breaks FATE. > > Some points to discuss: > - should the per-block structure store the final per-block quantizer or > the delta from the per-frame value (each can be easily computed from > the other, so it's more of a convenience question)? deltas are used in > the current set as suggested by Lynne If deltas are used then it should be documented how they are applied to find the final value. some codecs might use something like (global + delta) % M in the bitstream, which seems not ideal for generically interpretable data > - do we want per-plane quantizers in each block? The original patch > didn't have them. Do we want separate AC/DC quantizers? Anything else? I suspect whatever we put in now, one day an important codec will require an additional value per block. Thus i think its important that its extendible. I think the patch was extendible so thats probably already fine, iam just mentioning it as its important IMHO > - what to do with (M)JPEG? AFAIU it doesn't have a quantizer scale like > later codecs, just full quantization matrices. Our decoder currently > exports some number calculated from those in a non-obvious way. Is > that useful or should that be dropped? postprocessing improves (low bitrate) jpeg. So something that provides information about the quatization step size would be usefull. In which way that is done isnt important. Exporting the quantization tables themselfs via side data would be the obvious option thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. 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] libavformat/matroskaenc.c: Check if we can seek before writing the end of the ebml of the segment.
On Wed, Mar 11, 2020 at 10:13 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Thierry Foucu:
> > ---
> > libavformat/matroskaenc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > index 42f21eae8b..cf436f9e3e 100644
> > --- a/libavformat/matroskaenc.c
> > +++ b/libavformat/matroskaenc.c
> > @@ -2630,7 +2630,7 @@ static int mkv_write_trailer(AVFormatContext *s)
> > avio_seek(pb, currentpos, SEEK_SET);
> > }
> >
> > -if (!mkv->is_live) {
> > +if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && !mkv->is_live) {
> > end_ebml_master(pb, mkv->segment);
> > }
> >
> >
> Why? Even if the output is unseekable, the seek to the beginning might
> succeed if it happens in the output buffer (unlikely but possible). Or
> do you have a specific usecase in mind where the segment should be
> unknown-length?
>
>
In most cases in the muxer, we are checking if the file support seeking
before writing some ebml, like we do for the cues in the trailer function.
It is true that in some cases, the offset will be in the output buffer,
then why not as well check it for cues?
but most of the time, this offset will not when we are in streaming more.
Maybe the aviobuf layer should not then call io_seek if the under
layer has is_streamed
= true?
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thierry Foucu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix typos
On Thu, 05. Mar 00:02, Andriy Gelman wrote: > From: Andriy Gelman > > Signed-off-by: Andriy Gelman > --- > libavcodec/avcodec.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index 5a0fc3405c5..8cda2422efa 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -5037,7 +5037,7 @@ int avcodec_receive_frame(AVCodecContext *avctx, > AVFrame *frame); > * AVERROR(EINVAL): codec not opened, refcounted_frames not set, it > is a > * decoder, or requires flush > * AVERROR(ENOMEM): failed to add packet to internal queue, or similar > - * other errors: legitimate decoding errors > + * other errors: legitimate encoding errors > */ > int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame); > > @@ -5053,8 +5053,8 @@ int avcodec_send_frame(AVCodecContext *avctx, const > AVFrame *frame); > * must try to send input > * AVERROR_EOF: the encoder has been fully flushed, and there > will be > * no more output packets > - * AVERROR(EINVAL): codec not opened, or it is an encoder > - * other errors: legitimate decoding errors > + * AVERROR(EINVAL): codec not opened, or it is a decoder > + * other errors: legitimate encoding errors > */ > int avcodec_receive_packet(AVCodecContext *avctx, AVPacket *avpkt); > > -- > 2.25.0 > ping -- Andriy ___ 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] pthread_frame: attempt to get frame to reduce latency
On Wed, 11 Mar 2020, Derek Buitenhuis wrote: On 11/03/2020 14:53, Devin Heitmueller wrote: Regardless of the actual proposed patch, I think the author's use of wallclock time to describe the problem is very reasonable. I do a large amount of work where I'm measuring "glass-to-glass" latency, where I am interested in the total pipeline (encode/network/decode), and I definitely went through the experience of trying to figure out why ffmpeg was introducing nearly 500ms of extra latency during decoding. It turned out that it was because my particular platform had 8-cores and thus 16 decoding threads and thus 15x33ms of delay, regardless of the stream complexity. Heavy disagree. The measurement is *specifically* referring to an API call here, and it *specifically* effects the delay, in frames. The email in question is conflating timestamps (33ms) per frame with wallclock time later on. It is not a meaningful comparison to make. Only pain lies down the path of mixing timestamps and wallclock like that. Glass-to-glass measurement is important too, but don't conflate the two. For what it's worth, I pick deterministic delay (in frames! packets-in-to-frames-out) over the possibility of less delay but non-deterministic every day of the week. For my own sanity. *Certainly* not as the default and only mode of operation. FWIW, while I agree it shouldn't be the default, I have occasionally considered the need for this particular feature. Consider a live stream with a very variable framerate, essentially varying in the full range between 0 and 60 fps. To cope with decoding the high end of the framerate range, one needs to have frame threading enabled - maybe not with something crazy like 16 threads, but say at least 5 or so. Then you need to feed 5 packets into the decoder before you get the first frame output (for a stream without any reordering). Now if packets are received at 60 fps, you get one new packet to feed the decoder per 16 ms, and you get the first frame to output 83 ms later, assuming that the decoding of that individual frame on that thread took less than 83 ms. However, if the rate of input packets drops to e.g. 1 packet per second, it will take 5 seconds before I have 5 packets to feed to the decoder, before I have the first frame output, even though it actually was finished decoding in say less than 100 ms after the first input packet was given to the decoder. So in such a setup, being able to fetch output frames from the decoder sooner would be very useful - giving a closer to fixed decoding time in wallclock time, regardless of the packet input rate. // 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".
[FFmpeg-devel] [PATCH] lavf/dashenc: add dash SegmentBase manifest generator
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this box
to have a reference to all fragments in the media.
---
doc/muxers.texi | 5 +
libavformat/dashenc.c | 35 ++-
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..fbaa357f2d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -309,6 +309,11 @@ escaped.
@item global_sidx @var{global_sidx}
Write global SIDX atom. Applicable only for single file, mp4 output,
non-streaming mode.
+@item use_segmentbase @var{use_segmentbase}
+Generates a dash SegmentBase manifest as defined in section 5.3.9.2 of the ISO
+DASH specification. Only applicable when global sidx is enabled since the
player
+uses it to have a reference of all the segments in the media
+
@item dash_segment_type @var{dash_segment_type}
Possible values:
@table @option
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94d463972a..e8b418e74c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -193,6 +193,8 @@ typedef struct DASHContext {
int profile;
int64_t target_latency;
int target_latency_refid;
+int use_segmentbase;
+int64_t sidx_size;
} DASHContext;
static struct codec_string {
@@ -696,16 +698,23 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, AVFormatCont
avio_printf(out, "\t\t\t\t\n");
} else if (c->single_file) {
avio_printf(out, "\t\t\t\t%s\n", os->initfile);
-avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
-avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, os->init_start_pos +
os->init_range_length - 1);
-for (i = start_index; i < os->nb_segments; i++) {
-Segment *seg = os->segments[i];
-avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
-if (seg->index_length)
-avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
-avio_printf(out, "/>\n");
+int64_t init_segment_size = os->init_start_pos + os->init_range_length;
+if (c->use_segmentbase && final) {
+avio_printf(out, "\t\t\t\t\n", init_segment_size - c->sidx_size, init_segment_size - 1,
AV_TIME_BASE);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size -
c->sidx_size - 1);
+avio_printf(out, "\t\t\t\t\n");
+} else {
+avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size - 1);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
+if (seg->index_length)
+avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
+avio_printf(out, "/>\n");
+}
+avio_printf(out, "\t\t\t\t\n");
}
-avio_printf(out, "\t\t\t\t\n");
} else {
avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
avio_printf(out, "\t\t\t\t\t\n",
os->initfile);
@@ -1389,6 +1398,12 @@ static int dash_init(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as
streaming is enabled\n");
c->global_sidx = 0;
}
+
+if (c->use_segmentbase && !c->global_sidx) {
+av_log(s, AV_LOG_WARNING, "SegmentBase manifest signaling option will
be ignored as global SIDX is not enabled\n");
+c->use_segmentbase = 0;
+}
+
if (c->frag_type == FRAG_TYPE_NONE && c->streaming) {
av_log(s, AV_LOG_VERBOSE, "Changing frag_type from none to every_frame
as streaming is enabled\n");
c->frag_type = FRAG_TYPE_EVERY_FRAME;
@@ -1981,6 +1996,7 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
if (c->global_sidx) {
int j, start_index, start_number;
int64_t sidx_size = avio_tell(os->ctx->pb) - file_size;
+c->sidx_size = sidx_size;
get_start_index_number(os, c, &start_index, &start_number);
if (start_index >= os->nb_segments ||
os->segment_type != SEGMENT_TYPE_MP4)
@@ -2350,6 +2366,7 @@ static const AVOption options[] = {
{ "index_correction", "Enable/Disable segment index correction logic",
OFFSET(index_correction), AV_OPT_T
Re: [FFmpeg-devel] [PATCH] lavf/dashenc: add dash SegmentBase manifest generator
Am Mi., 11. März 2020 um 22:12 Uhr schrieb David Martin : > > Support to generate dash SegmentBase manifests, by adding > "use_segmentbase" option to dash muxer. SegmentBase manifest > is defined in ISO DASH Specification section 5.3.9.2 and has as > prerequisite the option "global_sidx" as players will use this box > to have a reference to all fragments in the media. Please remove the re-indentation from the patch to make it more readable, feel free to also send a second patch that only contains the re-indentation. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/dashenc: add dash SegmentBase manifest generator
Support to generate dash SegmentBase manifests, by adding
"use_segmentbase" option to dash muxer. SegmentBase manifest
is defined in ISO DASH Specification section 5.3.9.2 and has as
prerequisite the option "global_sidx" as players will use this box
to have a reference to all fragments in the media.
---
doc/muxers.texi | 5 +
libavformat/dashenc.c | 35 ++-
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d304181671..fbaa357f2d 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -309,6 +309,11 @@ escaped.
@item global_sidx @var{global_sidx}
Write global SIDX atom. Applicable only for single file, mp4 output,
non-streaming mode.
+@item use_segmentbase @var{use_segmentbase}
+Generates a dash SegmentBase manifest as defined in section 5.3.9.2 of the ISO
+DASH specification. Only applicable when global sidx is enabled since the
player
+uses it to have a reference of all the segments in the media
+
@item dash_segment_type @var{dash_segment_type}
Possible values:
@table @option
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94d463972a..e8b418e74c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -193,6 +193,8 @@ typedef struct DASHContext {
int profile;
int64_t target_latency;
int target_latency_refid;
+int use_segmentbase;
+int64_t sidx_size;
} DASHContext;
static struct codec_string {
@@ -696,16 +698,23 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, AVFormatCont
avio_printf(out, "\t\t\t\t\n");
} else if (c->single_file) {
avio_printf(out, "\t\t\t\t%s\n", os->initfile);
-avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
-avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, os->init_start_pos +
os->init_range_length - 1);
-for (i = start_index; i < os->nb_segments; i++) {
-Segment *seg = os->segments[i];
-avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
-if (seg->index_length)
-avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
-avio_printf(out, "/>\n");
+int64_t init_segment_size = os->init_start_pos + os->init_range_length;
+if (c->use_segmentbase && final) {
+avio_printf(out, "\t\t\t\t\n", init_segment_size - c->sidx_size, init_segment_size - 1,
AV_TIME_BASE);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size -
c->sidx_size - 1);
+avio_printf(out, "\t\t\t\t\n");
+} else {
+avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
+avio_printf(out, "\t\t\t\t\t\n", os->init_start_pos, init_segment_size - 1);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+avio_printf(out, "\t\t\t\t\tstart_pos, seg->start_pos +
seg->range_length - 1);
+if (seg->index_length)
+avio_printf(out, "indexRange=\"%"PRId64"-%"PRId64"\" ",
seg->start_pos, seg->start_pos + seg->index_length - 1);
+avio_printf(out, "/>\n");
+}
+avio_printf(out, "\t\t\t\t\n");
}
-avio_printf(out, "\t\t\t\t\n");
} else {
avio_printf(out, "\t\t\t\t\n", AV_TIME_BASE,
FFMIN(os->seg_duration, os->last_duration), start_number);
avio_printf(out, "\t\t\t\t\t\n",
os->initfile);
@@ -1389,6 +1398,12 @@ static int dash_init(AVFormatContext *s)
av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as
streaming is enabled\n");
c->global_sidx = 0;
}
+
+if (c->use_segmentbase && !c->global_sidx) {
+av_log(s, AV_LOG_WARNING, "SegmentBase manifest signaling option will
be ignored as global SIDX is not enabled\n");
+c->use_segmentbase = 0;
+}
+
if (c->frag_type == FRAG_TYPE_NONE && c->streaming) {
av_log(s, AV_LOG_VERBOSE, "Changing frag_type from none to every_frame
as streaming is enabled\n");
c->frag_type = FRAG_TYPE_EVERY_FRAME;
@@ -1981,6 +1996,7 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
if (c->global_sidx) {
int j, start_index, start_number;
int64_t sidx_size = avio_tell(os->ctx->pb) - file_size;
+c->sidx_size = sidx_size;
get_start_index_number(os, c, &start_index, &start_number);
if (start_index >= os->nb_segments ||
os->segment_type != SEGMENT_TYPE_MP4)
@@ -2350,6 +2366,7 @@ static const AVOption options[] = {
{ "index_correction", "Enable/Disable segment index correction logic",
OFFSET(index_correction), AV_OPT_T
[FFmpeg-devel] [PATCH] lavf/mux: bypass interleave delay early when waiting on subtitle streams
This avoids long delays when converting live streams that have sparse subtitles
---
libavformat/avformat.h | 9 +
libavformat/mux.c | 25 +
libavformat/options_table.h | 1 +
libavformat/version.h | 2 +-
4 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9b9b634ec3..da7e5755e8 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1957,6 +1957,15 @@ typedef struct AVFormatContext {
* - decoding: set by user
*/
int max_probe_packets;
+
+/**
+ * Maximum buffering duration for interleaving sparse streams.
+ *
+ * @see max_interleave_delta
+ *
+ * Applies only to subtitle and data streams.
+ */
+int64_t max_sparse_interleave_delta;
} AVFormatContext;
#if FF_API_FORMAT_GET_SET
diff --git a/libavformat/mux.c b/libavformat/mux.c
index d88746e8c5..f2f272cf65 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1033,6 +1033,7 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
AVPacket *out,
AVPacketList *pktl;
int stream_count = 0;
int noninterleaved_count = 0;
+int sparse_count = 0;
int i, ret;
int eof = flush;
@@ -1044,6 +1045,9 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
AVPacket *out,
for (i = 0; i < s->nb_streams; i++) {
if (s->streams[i]->last_in_packet_buffer) {
++stream_count;
+} else if (s->streams[i]->codecpar->codec_type ==
AVMEDIA_TYPE_SUBTITLE ||
+ s->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_DATA) {
+++sparse_count;
} else if (s->streams[i]->codecpar->codec_type !=
AVMEDIA_TYPE_ATTACHMENT &&
s->streams[i]->codecpar->codec_id != AV_CODEC_ID_VP8 &&
s->streams[i]->codecpar->codec_id != AV_CODEC_ID_VP9) {
@@ -1054,10 +1058,12 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
AVPacket *out,
if (s->internal->nb_interleaved_streams == stream_count)
flush = 1;
-if (s->max_interleave_delta > 0 &&
-s->internal->packet_buffer &&
+if (s->internal->packet_buffer &&
!flush &&
-s->internal->nb_interleaved_streams ==
stream_count+noninterleaved_count
+((s->max_interleave_delta > 0 &&
+ s->internal->nb_interleaved_streams ==
stream_count+noninterleaved_count+sparse_count) ||
+ (s->max_sparse_interleave_delta > 0 &&
+ s->internal->nb_interleaved_streams == stream_count+sparse_count))
) {
AVPacket *top_pkt = &s->internal->packet_buffer->pkt;
int64_t delta_dts = INT64_MIN;
@@ -1078,12 +1084,23 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
AVPacket *out,
delta_dts = FFMAX(delta_dts, last_dts - top_dts);
}
-if (delta_dts > s->max_interleave_delta) {
+if (s->max_interleave_delta > 0 &&
+delta_dts > s->max_interleave_delta &&
+s->internal->nb_interleaved_streams ==
stream_count+noninterleaved_count+sparse_count) {
av_log(s, AV_LOG_DEBUG,
"Delay between the first packet and last packet in the "
"muxing queue is %"PRId64" > %"PRId64": forcing output\n",
delta_dts, s->max_interleave_delta);
flush = 1;
+} else if (s->max_sparse_interleave_delta > 0 &&
+ delta_dts > s->max_sparse_interleave_delta &&
+ s->internal->nb_interleaved_streams ==
stream_count+sparse_count) {
+av_log(s, AV_LOG_DEBUG,
+ "Delay between the first packet and last packet in the "
+ "muxing queue is %"PRId64" > %"PRId64" and all delayed "
+ "streams are sparse: forcing output\n",
+ delta_dts, s->max_sparse_interleave_delta);
+flush = 1;
}
}
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index e26b512440..db04f970e2 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -91,6 +91,7 @@ static const AVOption avformat_options[] = {
{"metadata_header_padding", "set number of bytes to be written as padding in a
metadata header", OFFSET(metadata_header_padding), AV_OPT_TYPE_INT, {.i64 =
-1}, -1, INT_MAX, E},
{"output_ts_offset", "set output timestamp offset", OFFSET(output_ts_offset),
AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX, INT64_MAX, E},
{"max_interleave_delta", "maximum buffering duration for interleaving",
OFFSET(max_interleave_delta), AV_OPT_TYPE_INT64, { .i64 = 1000 }, 0,
INT64_MAX, E },
+{"max_sparse_interleave_delta", "maximum buffering duration for interleaving
sparse streams", OFFSET(max_sparse_interleave_delta), AV_OPT_TYPE_INT64, { .i64
= 100 }, 0, INT64_MAX, E },
{"f_strict", "how strictly to follow the standards (deprecated; use strict,
save via avconv)", OFFSET(strict_std_compliance), AV_OPT_
Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support
> -Original Message- > From: ffmpeg-devel On Behalf Of > Max Dmitrichenko > Sent: Wednesday, March 11, 2020 12:49 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > On Tue, Mar 10, 2020 at 10:36 PM Soft Works > wrote: > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Artem Galin > > > Sent: Tuesday, March 10, 2020 5:10 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: adding DX11 support > > > > > > Any comments on updated patch by link below: > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200306130954.893 > > > 8- > > > 1-artem.ga...@gmail.com/ > > > > I don't see any comments there. > > > > > I can help commenting below: > > Allow selection of a specific DXGI adapter > QSV can make use only one Intel's adapter for currently available HW, if > changed in the future - this comment should be addressed. 1. It wil change this year because Intel is about to release discrete gpu boards 2. Users can have other GPU boars installed so Intel's GPU is not always the first DXGI/D3D11 adapter > > Change filters to support mfxHandlePair > Filters should come in next patches, > This is initial implementation which will establish base for later filters > change(s). I don't think it is a good idea to submit a path that will break filtering functionality. The submitted patch is far away from being complete. I know it because I've already done a full implementation of D3D11 support for QuickSync (but not yet submitted). 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]lsws/input: Do not change transparency range
Am Mi., 26. Feb. 2020 um 19:50 Uhr schrieb Carl Eugen Hoyos : > > Am Sa., 15. Feb. 2020 um 20:21 Uhr schrieb Michael Niedermayer > : > > > > On Sat, Feb 15, 2020 at 10:10:45AM +0100, Carl Eugen Hoyos wrote: > > > Hi! > > > > > > Transparency levels are currently changed when reading bgra and > > > friends, this patch changes behaviour and fixes ticket #8509. > > > > > > Please comment, Carl Eugen > > > > > libswscale/input.c|6 > > > tests/ref/fate/ffmpeg-filter_colorkey | 20 +- > > > tests/ref/fate/filter-overlay-dvdsub-2397 | 180 > > > +- > > > tests/ref/fate/filter-overlay_gbrap_gbrap |2 > > > tests/ref/fate/filter-overlay_gbrp_gbrap |2 > > > tests/ref/fate/filter-overlay_yuv420_yuva420 |2 > > > tests/ref/fate/filter-overlay_yuv422_yuva422 |2 > > > tests/ref/fate/filter-overlay_yuv444_yuva444 |2 > > > tests/ref/fate/filter-overlay_yuva420_yuva420 |2 > > > tests/ref/fate/filter-overlay_yuva422_yuva422 |2 > > > tests/ref/fate/filter-overlay_yuva444_yuva444 |2 > > > 11 files changed, 111 insertions(+), 111 deletions(-) > > > d8ed3bafeca2ed15b41a2fca0dc5600e3aeab671 > > > 0001-lsws-input-Do-not-change-transparency-range.patch > > > From a71053df9131be803d9a359a7232e5193747f351 Mon Sep 17 00:00:00 2001 > > > From: Carl Eugen Hoyos > > > Date: Sat, 15 Feb 2020 10:07:51 +0100 > > > Subject: [PATCH] lsws/input: Do not change transparency range. > > > > > > Fixes ticket #8509. > > [...] > > > > > @@ -457,7 +457,7 @@ static void palToA_c(uint8_t *_dst, const uint8_t > > > *src, const uint8_t *unused1, > > > for (i=0; i > > int d= src[i]; > > > > > > -dst[i]= (pal[d] >> 24)<<6; > > > +dst[i]= (pal[d] >> 24)<<6 | pal[d]>>2; > > > > this looks wrong, theres a 24 missing in some form > > New patch attached, thank you! Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/5] compat/avisynth: update headers
On Wed, Mar 11, 2020 at 06:50:15AM -0400, Stephen Hutchinson wrote: > AviSynth+ can now be used on Linux, which required some changes > to the headers. > --- > compat/avisynth/avisynth_c.h | 24 > compat/avisynth/avs/capi.h | 16 + > compat/avisynth/avs/config.h | 46 +-- > compat/avisynth/avs/posix.h | 111 +++ > compat/avisynth/avs/types.h | 13 ++-- > 5 files changed, 185 insertions(+), 25 deletions(-) > create mode 100644 compat/avisynth/avs/posix.h breaks fate-source make fate-source TESTsource --- ./tests/ref/fate/source 2020-03-11 22:59:07.757862801 +0100 +++ tests/data/fate/source 2020-03-11 23:00:22.237644535 +0100 @@ -22,6 +22,7 @@ compat/avisynth/avisynth_c.h compat/avisynth/avs/capi.h compat/avisynth/avs/config.h +compat/avisynth/avs/posix.h compat/avisynth/avs/types.h compat/avisynth/avxsynth_c.h compat/avisynth/windowsPorts/basicDataTypeConversions.h Test source failed. Look at tests/data/fate/source.err for details. tests/Makefile:250: recipe for target 'fate-source' failed make: *** [fate-source] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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] configure: Add llviddsp to mvha deps
On Wed, Mar 11, 2020 at 03:39:23PM +0100, Paul B Mahol wrote: > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn 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] configure: Add llviddsp to mvha deps
On Wed, Mar 11, 2020 at 11:20:48PM +0100, Michael Niedermayer wrote: > On Wed, Mar 11, 2020 at 03:39:23PM +0100, Paul B Mahol wrote: > > lgtm > > will apply actually, i wont apply this yet, it looks a bit odd -mvha_decoder_deps="zlib" +mvha_decoder_select="llviddsp zlib" zlib should be a _deps not _select i think thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency
On 11/03/2020 20:42, Martin Storsjö wrote: > FWIW, while I agree it shouldn't be the default, I have occasionally > considered the need for this particular feature. Arguably slice threading should be used, but that assumes you have sane input, which is obviously not always the case for some. > Consider a live stream with a very variable framerate, essentially varying > in the full range between 0 and 60 fps. To cope with decoding the high end > of the framerate range, one needs to have frame threading enabled - maybe > not with something crazy like 16 threads, but say at least 5 or so. > > Then you need to feed 5 packets into the decoder before you get the first > frame output (for a stream without any reordering). That last bit is key there, but yes. > > Now if packets are received at 60 fps, you get one new packet to feed the > decoder per 16 ms, and you get the first frame to output 83 ms later, > assuming that the decoding of that individual frame on that thread took > less than 83 ms (I'm assuming network, etc. has been left out for example's sake. :)) > However, if the rate of input packets drops to e.g. 1 packet per second, > it will take 5 seconds before I have 5 packets to feed to the decoder, > before I have the first frame output, even though it actually was finished > decoding in say less than 100 ms after the first input packet was given to > the decoder. > > So in such a setup, being able to fetch output frames from the decoder > sooner would be very useful - giving a closer to fixed decoding time in > wallclock time, regardless of the packet input rate. Not sure I would refer to it as closer to fixed, but the use case is certainly valid - I never claimed otherwise. If it is added, it needs be behind a flag/option with big bold letters saying the risks, and off by default. And that segfault Michael saw investigated. Thanks for the clear response that doesn't conflate the two. - Derek ___ 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/2] avcodec/adpcm: Fix invalid shift in AV_CODEC_ID_ADPCM_PSX
On Sun, Mar 01, 2020 at 11:59:34PM +0100, Michael Niedermayer wrote: > Fixes: left shift of negative value -1 > Fixes: > 20859/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_PSX_fuzzer-5720391507247104 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/adpcm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_jpeg: Check length for SOS
On Sat, Mar 07, 2020 at 11:40:42PM +0100, Michael Niedermayer wrote: > Fixes: out of array access > Fixes: > 19734/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5673507031875584 > Fixes: > 19353/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5703944462663680 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/cbs_jpeg.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] fate/ffmpeg: add test for time limited sub2video instance
On Thu, Mar 12, 2020 at 1:42 AM Jan Ekström wrote: > > Utilizes a subpicture sample with one decodable subpicture for the > test. > > Based on a failing test case in reported by Michael in > https://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240398.html > which at the time had no test case for it. > > Additionally, this is the first test case for the presentation > graphics format. > --- > tests/fate/ffmpeg.mak | 10 ++ > tests/ref/fate/sub2video_time_limited | 8 > 2 files changed, 18 insertions(+) > create mode 100644 tests/ref/fate/sub2video_time_limited > The sample file for this is available at https://megumin.fushizen.eu/samples/pgs_sub.sup and contains a single decodable PGS subpicture. Before the actually logic-affecting patch, this test would output nothing as per to Michael's comment. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] fate/ffmpeg: add a second, simple sub2video test
--- tests/fate/ffmpeg.mak | 9 tests/ref/fate/sub2video_basic | 95 ++ 2 files changed, 104 insertions(+) create mode 100644 tests/ref/fate/sub2video_basic diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 967150983a..835aab3665 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -56,6 +56,15 @@ fate-sub2video: CMD = framecrc \ -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:0]scale=720:480[v]\;[v][1:0]overlay[v2]" \ -map "[v2]" -c:v rawvideo -map 1:s -c:s dvdsub +# Very basic sub2video example, decode and convert to AVFrame with sub2video. +# Attempt to not touch timestamps. +FATE_SAMPLES_FFMPEG-$(call ALLYES, VOBSUB_DEMUXER DVDSUB_DECODER AVFILTER) += fate-sub2video_basic +fate-sub2video_basic: CMD = framecrc \ + -i $(TARGET_SAMPLES)/sub/vobsub.idx \ + -vsync passthrough -copyts \ + -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ + -c:v rawvideo + FATE_FFMPEG-$(call ALLYES, PCM_S16LE_DEMUXER PCM_S16LE_MUXER PCM_S16LE_DECODER PCM_S16LE_ENCODER) += fate-unknown_layout-pcm fate-unknown_layout-pcm: $(AREF) fate-unknown_layout-pcm: CMD = md5 \ diff --git a/tests/ref/fate/sub2video_basic b/tests/ref/fate/sub2video_basic new file mode 100644 index 00..5f72e292c9 --- /dev/null +++ b/tests/ref/fate/sub2video_basic @@ -0,0 +1,95 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 720x480 +#sar 0: 0/1 +0, 3312, 3312,1, 1382400, 0x +0, 3312, 3312,1, 1382400, 0x8c93c2ba +0, 3436, 3436,1, 1382400, 0x +0, 3684, 3684,1, 1382400, 0xb02e32ca +0, 3802, 3802,1, 1382400, 0x +0, 4520, 4520,1, 1382400, 0x83b71116 +0, 4584, 4584,1, 1382400, 0x +0, 4586, 4586,1, 1382400, 0x85547fd1 +0, 4645, 4645,1, 1382400, 0x +0, 4648, 4648,1, 1382400, 0x +0, 4648, 4648,1, 1382400, 0xb6a8f181 +0, 4715, 4715,1, 1382400, 0x +0, 4717, 4717,1, 1382400, 0xb64d1a2c +0, 4748, 4748,1, 1382400, 0x +0, 4750, 4750,1, 1382400, 0x7b37ecf3 +0, 4792, 4792,1, 1382400, 0x +0, 4993, 4993,1, 1382400, 0xdc025bd1 +0, 5027, 5027,1, 1382400, 0x +0, 5029, 5029,1, 1382400, 0x688b294d +0, 5068, 5068,1, 1382400, 0x +0, 5070, 5070,1, 1382400, 0xa2b33d1b +0, 5117, 5117,1, 1382400, 0x +0, 5119, 5119,1, 1382400, 0xb3e525e3 +0, 5168, 5168,1, 1382400, 0x +0, 5170, 5170,1, 1382400, 0xaa8fbdd7 +0, 5216, 5216,1, 1382400, 0x +0, 5218, 5218,1, 1382400, 0x7b7f26dd +0, 5249, 5249,1, 1382400, 0x +0, 5251, 5251,1, 1382400, 0x15e2f836 +0, 5289, 5289,1, 1382400, 0x +0, 5291, 5291,1, 1382400, 0x0fee9b0c +0, 5358, 5358,1, 1382400, 0x +0, 5360, 5360,1, 1382400, 0x89d62791 +0, 5429, 5429,1, 1382400, 0x +0, 5431, 5431,1, 1382400, 0xa6a9fd74 +0, 5490, 5490,1, 1382400, 0x +0, 5491, 5491,1, 1382400, 0x7896178d +0, 5537, 5537,1, 1382400, 0x +0, 5588, 5588,1, 1382400, 0x01751a52 +0, 5647, 5647,1, 1382400, 0x +0, 5688, 5688,1, 1382400, 0xa3959c6f +0, 5770, 5770,1, 1382400, 0x +0, 5772, 5772,1, 1382400, 0x3d3ea47b +0, 5826, 5826,1, 1382400, 0x +0, 5828, 5828,1, 1382400, 0x593f8b24 +0, 5931, 5931,1, 1382400, 0x +0, 5933, 5933,1, 1382400, 0x171f05ba +0, 6001, 6001,1, 1382400, 0x +0, 6003, 6003,1, 1382400, 0xb014cdf1 +0, 6054, 6054,1, 1382400, 0x +0, 6839, 6839,1, 1382400, 0xd918e667 +0, 6880, 6880,1, 1382400, 0x +0, 7386, 7386,1, 1382400, 0xc9406331 +0, 7419, 7419,1, 1382400, 0x +0, 7501, 7501,1, 1382400, 0xaf08b10d +0, 7549, 7549,1, 1382400, 0x +0, 7551, 7551,1, 1382400, 0x +0, 7551, 7551,1, 1382400, 0x853a9d93 +0, 7589, 7589,1, 1382400, 0x +0, 7605, 7605,1, 1382400, 0
[FFmpeg-devel] [PATCH 3/3] fate/ffmpeg: add test for time limited sub2video instance
Utilizes a subpicture sample with one decodable subpicture for the test. Based on a failing test case in reported by Michael in https://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240398.html which at the time had no test case for it. Additionally, this is the first test case for the presentation graphics format. --- tests/fate/ffmpeg.mak | 10 ++ tests/ref/fate/sub2video_time_limited | 8 2 files changed, 18 insertions(+) create mode 100644 tests/ref/fate/sub2video_time_limited diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 835aab3665..0b0610f647 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -65,6 +65,16 @@ fate-sub2video_basic: CMD = framecrc \ -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ -c:v rawvideo +# Time-limited run with a sample that doesn't require seeking and +# contains samples within the initial period. +FATE_SAMPLES_FFMPEG-$(call ALLYES, SUP_DEMUXER PGSSUB_DECODER AVFILTER) += fate-sub2video_time_limited +fate-sub2video_time_limited: CMD = framecrc \ + -i $(TARGET_SAMPLES)/sub/pgs_sub.sup \ + -vsync passthrough -copyts \ + -t 15 \ + -filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ + -c:v rawvideo + FATE_FFMPEG-$(call ALLYES, PCM_S16LE_DEMUXER PCM_S16LE_MUXER PCM_S16LE_DECODER PCM_S16LE_ENCODER) += fate-unknown_layout-pcm fate-unknown_layout-pcm: $(AREF) fate-unknown_layout-pcm: CMD = md5 \ diff --git a/tests/ref/fate/sub2video_time_limited b/tests/ref/fate/sub2video_time_limited new file mode 100644 index 00..9fb6fb06f9 --- /dev/null +++ b/tests/ref/fate/sub2video_time_limited @@ -0,0 +1,8 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1920x1080 +#sar 0: 0/1 +0, 2, 2,1, 8294400, 0x +0, 2, 2,1, 8294400, 0xa87c518f +0, 10, 10,1, 8294400, 0xa87c518f -- 2.24.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] fate/ffmpeg: add a second, simple sub2video test
On Thu, Mar 12, 2020 at 1:42 AM Jan Ekström wrote: > > --- > tests/fate/ffmpeg.mak | 9 > tests/ref/fate/sub2video_basic | 95 ++ > 2 files changed, 104 insertions(+) > create mode 100644 tests/ref/fate/sub2video_basic > Before the logic affecting patch, this test could be executed and it would output the same amount of packets, but it would force the PTS and DTS of the first packet to be zero. The diff would be as follows from before to after: -0, 0, 0,1, 1382400, 0x +0, 3312, 3312,1, 1382400, 0x Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] ffmpeg: explicitly handle sub2video subpicture initialization
Each time the sub2video structure is initialized, the sub2video
subpicture is initialized together with the first received heartbeat.
The heartbeat's PTS is utilized as the subpicture start time.
Additionally, add some documentation on the stages.
---
fftools/ffmpeg.c| 22 +++---
fftools/ffmpeg.h| 3 ++-
fftools/ffmpeg_filter.c | 8 +++-
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e5fbd479a8..aaaf241314 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -237,7 +237,7 @@ static void sub2video_push_ref(InputStream *ist, int64_t
pts)
}
}
-void sub2video_update(InputStream *ist, AVSubtitle *sub)
+void sub2video_update(InputStream *ist, int64_t heartbeat_pts, AVSubtitle *sub)
{
AVFrame *frame = ist->sub2video.frame;
int8_t *dst;
@@ -254,7 +254,12 @@ void sub2video_update(InputStream *ist, AVSubtitle *sub)
AV_TIME_BASE_Q, ist->st->time_base);
num_rects = sub->num_rects;
} else {
-pts = ist->sub2video.end_pts;
+/* If we are initializing the system, utilize current heartbeat
+ PTS as the start time, and show until the following subpicture
+ is received. Otherwise, utilize the previous subpicture's end time
+ as the fall-back value. */
+pts = ist->sub2video.initialize ?
+heartbeat_pts : ist->sub2video.end_pts;
end_pts = INT64_MAX;
num_rects = 0;
}
@@ -269,6 +274,7 @@ void sub2video_update(InputStream *ist, AVSubtitle *sub)
sub2video_copy_rect(dst, dst_linesize, frame->width, frame->height,
sub->rects[i]);
sub2video_push_ref(ist, pts);
ist->sub2video.end_pts = end_pts;
+ist->sub2video.initialize = 0;
}
static void sub2video_heartbeat(InputStream *ist, int64_t pts)
@@ -291,9 +297,11 @@ static void sub2video_heartbeat(InputStream *ist, int64_t
pts)
/* do not send the heartbeat frame if the subtitle is already ahead */
if (pts2 <= ist2->sub2video.last_pts)
continue;
-if (pts2 >= ist2->sub2video.end_pts ||
-(!ist2->sub2video.frame->data[0] && ist2->sub2video.end_pts <
INT64_MAX))
-sub2video_update(ist2, NULL);
+if (pts2 >= ist2->sub2video.end_pts || ist2->sub2video.initialize)
+/* if we have hit the end of the current displayed subpicture,
+ or if we need to initialize the system, update the
+ overlayed subpicture and its start/end times */
+sub2video_update(ist2, pts2 + 1, NULL);
for (j = 0, nb_reqs = 0; j < ist2->nb_filters; j++)
nb_reqs +=
av_buffersrc_get_nb_failed_requests(ist2->filters[j]->filter);
if (nb_reqs)
@@ -307,7 +315,7 @@ static void sub2video_flush(InputStream *ist)
int ret;
if (ist->sub2video.end_pts < INT64_MAX)
-sub2video_update(ist, NULL);
+sub2video_update(ist, INT64_MAX, NULL);
for (i = 0; i < ist->nb_filters; i++) {
ret = av_buffersrc_add_frame(ist->filters[i]->filter, NULL);
if (ret != AVERROR_EOF && ret < 0)
@@ -2507,7 +2515,7 @@ static int transcode_subtitles(InputStream *ist, AVPacket
*pkt, int *got_output,
return ret;
if (ist->sub2video.frame) {
-sub2video_update(ist, &subtitle);
+sub2video_update(ist, INT64_MIN, &subtitle);
} else if (ist->nb_filters) {
if (!ist->sub2video.sub_queue)
ist->sub2video.sub_queue = av_fifo_alloc(8 * sizeof(AVSubtitle));
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index c0b8eb599f..fbaae15377 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -348,6 +348,7 @@ typedef struct InputStream {
AVFifoBuffer *sub_queue;///< queue of AVSubtitle* before filter
init
AVFrame *frame;
int w, h;
+unsigned int initialize; ///< marks if sub2video_update should force
an initialization
} sub2video;
int dr1;
@@ -645,7 +646,7 @@ int filtergraph_is_simple(FilterGraph *fg);
int init_simple_filtergraph(InputStream *ist, OutputStream *ost);
int init_complex_filtergraph(FilterGraph *fg);
-void sub2video_update(InputStream *ist, AVSubtitle *sub);
+void sub2video_update(InputStream *ist, int64_t heartbeat_pts, AVSubtitle
*sub);
int ifilter_parameters_from_frame(InputFilter *ifilter, const AVFrame *frame);
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 40cc4c191c..b66faa50b5 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -740,6 +740,12 @@ static int sub2video_prepare(InputStream *ist, InputFilter
*ifilter)
return AVERROR(ENOMEM);
ist->sub2video.last_pts = INT64_MIN;
ist->sub2video.end_pts = INT64_MIN;
+
+/* sub2video structure has been (re-)initialized.
+ Mark it as such so that the system will be
+ initialized with the first received heartbeat. */
+ist->sub2video.i
Re: [FFmpeg-devel] [PATCH] libavformat/matroskaenc.c: Check if we can seek before writing the end of the ebml of the segment.
Thierry Foucu:
> On Wed, Mar 11, 2020 at 10:13 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> Thierry Foucu:
>>> ---
>>> libavformat/matroskaenc.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>>> index 42f21eae8b..cf436f9e3e 100644
>>> --- a/libavformat/matroskaenc.c
>>> +++ b/libavformat/matroskaenc.c
>>> @@ -2630,7 +2630,7 @@ static int mkv_write_trailer(AVFormatContext *s)
>>> avio_seek(pb, currentpos, SEEK_SET);
>>> }
>>>
>>> -if (!mkv->is_live) {
>>> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && !mkv->is_live) {
>>> end_ebml_master(pb, mkv->segment);
>>> }
>>>
>>>
>> Why? Even if the output is unseekable, the seek to the beginning might
>> succeed if it happens in the output buffer (unlikely but possible). Or
>> do you have a specific usecase in mind where the segment should be
>> unknown-length?
>>
>>
> In most cases in the muxer, we are checking if the file support seeking
> before writing some ebml, like we do for the cues in the trailer function.
> It is true that in some cases, the offset will be in the output buffer,
> then why not as well check it for cues?
Because in order to write cues, one would have to store them first and
we don't do that given that it is very unlikely for the cues to be
used later.
Furthermore, in the other cases (e.g. the Info element): These are
already written and freed when writing the header if the output is
unseekable (or actually: if the output was unseekable during writing
the header; the logic is wrong if the output's seekability status
changes and dangerous if it was unseekable when writing the header and
changes to seekable later; I'll send a patch for this).
> but most of the time, this offset will not when we are in streaming more.
>
> Maybe the aviobuf layer should not then call io_seek if the under
> layer has is_streamed
> = true?
>
First of all, the aviobuf layer doesn't call io_seek() any more
because it has been removed in 6e8e8431. And does it matter from which
layer the error for a failed seek comes if the seek was unsuccessfull?
(Furthermore, there is (at least?) an instance where the is_streamed
is wrong: Namely if you use the seekable option for file output. But
that seems to be intentional.)
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/5] compat/avisynth: update headers
AviSynth+ can now be used on Linux, which required some changes
to the headers.
As part of this, and to not cause issues with adding a new header,
correct the header inclusion guards to make FATE happy.
---
compat/avisynth/avisynth_c.h | 30 ++
compat/avisynth/avs/capi.h | 22 ++-
compat/avisynth/avs/config.h | 52 +---
compat/avisynth/avs/posix.h | 111 +++
compat/avisynth/avs/types.h | 19 +++---
tests/ref/fate/source| 4 --
6 files changed, 197 insertions(+), 41 deletions(-)
create mode 100644 compat/avisynth/avs/posix.h
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 9ff9321552..d30d7caca9 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -51,8 +51,8 @@
// Example#2: avs_bits_per_component will return 8 for all colorspaces
(Classic Avisynth supports only 8 bits/pixel)
// Thus the Avisynth+ specific API functions are safely callable even
when connected to classic Avisynth DLL
-#ifndef __AVISYNTH_C__
-#define __AVISYNTH_C__
+#ifndef COMPAT_AVISYNTH_AVISYNTH_C_H
+#define COMPAT_AVISYNTH_AVISYNTH_C_H
#include "avs/config.h"
#include "avs/capi.h"
@@ -341,7 +341,7 @@ typedef struct AVS_VideoInfo {
int audio_samples_per_second; // 0 means no audio
int sample_type;
- INT64 num_audio_samples;
+ int64_t num_audio_samples;
int nchannels;
// Image type properties
@@ -444,16 +444,16 @@ AVSC_INLINE int avs_bytes_per_channel_sample(const
AVS_VideoInfo * p)
AVSC_INLINE int avs_bytes_per_audio_sample(const AVS_VideoInfo * p)
{ return p->nchannels*avs_bytes_per_channel_sample(p);}
-AVSC_INLINE INT64 avs_audio_samples_from_frames(const AVS_VideoInfo * p, INT64
frames)
-{ return ((INT64)(frames) * p->audio_samples_per_second *
p->fps_denominator / p->fps_numerator); }
+AVSC_INLINE int64_t avs_audio_samples_from_frames(const AVS_VideoInfo * p,
int64_t frames)
+{ return ((int64_t)(frames) * p->audio_samples_per_second *
p->fps_denominator / p->fps_numerator); }
-AVSC_INLINE int avs_frames_from_audio_samples(const AVS_VideoInfo * p, INT64
samples)
-{ return (int)(samples * (INT64)p->fps_numerator /
(INT64)p->fps_denominator / (INT64)p->audio_samples_per_second); }
+AVSC_INLINE int avs_frames_from_audio_samples(const AVS_VideoInfo * p, int64_t
samples)
+{ return (int)(samples * (int64_t)p->fps_numerator /
(int64_t)p->fps_denominator / (int64_t)p->audio_samples_per_second); }
-AVSC_INLINE INT64 avs_audio_samples_from_bytes(const AVS_VideoInfo * p, INT64
bytes)
+AVSC_INLINE int64_t avs_audio_samples_from_bytes(const AVS_VideoInfo * p,
int64_t bytes)
{ return bytes / avs_bytes_per_audio_sample(p); }
-AVSC_INLINE INT64 avs_bytes_from_audio_samples(const AVS_VideoInfo * p, INT64
samples)
+AVSC_INLINE int64_t avs_bytes_from_audio_samples(const AVS_VideoInfo * p,
int64_t samples)
{ return samples * avs_bytes_per_audio_sample(p); }
AVSC_INLINE int avs_audio_channels(const AVS_VideoInfo * p)
@@ -764,7 +764,7 @@ AVSC_API(int, avs_get_parity)(AVS_Clip *, int n);
// return field parity if field_based, else parity of first field in frame
AVSC_API(int, avs_get_audio)(AVS_Clip *, void * buf,
- INT64 start, INT64 count);
+ int64_t start, int64_t count);
// start and count are in samples
AVSC_API(int, avs_set_cache_hints)(AVS_Clip *,
@@ -784,7 +784,7 @@ struct AVS_FilterInfo
AVS_VideoFrame * (AVSC_CC * get_frame)(AVS_FilterInfo *, int n);
int (AVSC_CC * get_parity)(AVS_FilterInfo *, int n);
int (AVSC_CC * get_audio)(AVS_FilterInfo *, void * buf,
- INT64 start, INT64 count);
+ int64_t start, int64_t count);
int (AVSC_CC * set_cache_hints)(AVS_FilterInfo *, int cachehints,
int frame_range);
void (AVSC_CC * free_filter)(AVS_FilterInfo *);
@@ -933,6 +933,8 @@ AVSC_API(void,
avs_delete_script_environment)(AVS_ScriptEnvironment *);
AVSC_API(AVS_VideoFrame *, avs_subframe_planar)(AVS_ScriptEnvironment *,
AVS_VideoFrame * src, int rel_offset, int new_pitch, int new_row_size, int
new_height, int rel_offsetU, int rel_offsetV, int new_pitchUV);
// The returned video frame must be be released
+#if defined(AVS_WINDOWS)
+// The following stuff is only relevant for Windows DLL handling; Linux does
it completely differently.
#ifdef AVSC_NO_DECLSPEC
// This part uses LoadLibrary and related functions to dynamically load
Avisynth instead of declspec(dllimport)
// When AVSC_NO_DECLSPEC is defined, you can use avs_load_library to populate
API functions into a struct
@@ -944,7 +946,7 @@ AVSC_API(AVS_VideoFrame *,
avs_subframe_planar)(AVS_ScriptEnvironment *, AVS_Vid
void* malloc(size_t)
void free(void*);
- HMODULE LoadLibrary(const char*);
+ HMODULE LoadLibraryA(const char*);
void* GetProcA
[FFmpeg-devel] [PATCH 3/5] compat/avisynth: remove AvxSynth headers
---
compat/avisynth/avxsynth_c.h | 728 --
.../windowsPorts/basicDataTypeConversions.h | 85 --
compat/avisynth/windowsPorts/windows2linux.h | 77 --
tests/ref/fate/source | 5 -
4 files changed, 895 deletions(-)
delete mode 100644 compat/avisynth/avxsynth_c.h
delete mode 100644 compat/avisynth/windowsPorts/basicDataTypeConversions.h
delete mode 100644 compat/avisynth/windowsPorts/windows2linux.h
diff --git a/compat/avisynth/avxsynth_c.h b/compat/avisynth/avxsynth_c.h
deleted file mode 100644
index 991f4be1ab..00
--- a/compat/avisynth/avxsynth_c.h
+++ /dev/null
@@ -1,728 +0,0 @@
-// Avisynth C Interface Version 0.20
-// Copyright 2003 Kevin Atkinson
-
-// This program is free software; you can redistribute it and/or modify
-// it under the terms of the GNU General Public License as published by
-// the Free Software Foundation; either version 2 of the License, or
-// (at your option) any later version.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, write to the Free Software
-// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
-// MA 02110-1301 USA, or visit
-// http://www.gnu.org/copyleft/gpl.html .
-//
-// As a special exception, I give you permission to link to the
-// Avisynth C interface with independent modules that communicate with
-// the Avisynth C interface solely through the interfaces defined in
-// avisynth_c.h, regardless of the license terms of these independent
-// modules, and to copy and distribute the resulting combined work
-// under terms of your choice, provided that every copy of the
-// combined work is accompanied by a complete copy of the source code
-// of the Avisynth C interface and Avisynth itself (with the version
-// used to produce the combined work), being distributed under the
-// terms of the GNU General Public License plus this exception. An
-// independent module is a module which is not derived from or based
-// on Avisynth C Interface, such as 3rd-party filters, import and
-// export plugins, or graphical user interfaces.
-
-#ifndef __AVXSYNTH_C__
-#define __AVXSYNTH_C__
-
-#include "windowsPorts/windows2linux.h"
-#include
-
-#ifdef __cplusplus
-# define EXTERN_C extern "C"
-#else
-# define EXTERN_C
-#endif
-
-#define AVSC_USE_STDCALL 1
-
-#ifndef AVSC_USE_STDCALL
-# define AVSC_CC __cdecl
-#else
-# define AVSC_CC __stdcall
-#endif
-
-#define AVSC_INLINE static __inline
-
-#ifdef AVISYNTH_C_EXPORTS
-# define AVSC_EXPORT EXTERN_C
-# define AVSC_API(ret, name) EXTERN_C __declspec(dllexport) ret AVSC_CC name
-#else
-# define AVSC_EXPORT EXTERN_C __declspec(dllexport)
-# ifndef AVSC_NO_DECLSPEC
-#define AVSC_API(ret, name) EXTERN_C __declspec(dllimport) ret AVSC_CC name
-# else
-#define AVSC_API(ret, name) typedef ret (AVSC_CC *name##_func)
-# endif
-#endif
-
-#ifdef __GNUC__
-typedef long long int INT64;
-#else
-typedef __int64 INT64;
-#endif
-
-
-/
-//
-// Constants
-//
-
-#ifndef __AVXSYNTH_H__
-enum { AVISYNTH_INTERFACE_VERSION = 3 };
-#endif
-
-enum {AVS_SAMPLE_INT8 = 1<<0,
- AVS_SAMPLE_INT16 = 1<<1,
- AVS_SAMPLE_INT24 = 1<<2,
- AVS_SAMPLE_INT32 = 1<<3,
- AVS_SAMPLE_FLOAT = 1<<4};
-
-enum {AVS_PLANAR_Y=1<<0,
- AVS_PLANAR_U=1<<1,
- AVS_PLANAR_V=1<<2,
- AVS_PLANAR_ALIGNED=1<<3,
- AVS_PLANAR_Y_ALIGNED=AVS_PLANAR_Y|AVS_PLANAR_ALIGNED,
- AVS_PLANAR_U_ALIGNED=AVS_PLANAR_U|AVS_PLANAR_ALIGNED,
- AVS_PLANAR_V_ALIGNED=AVS_PLANAR_V|AVS_PLANAR_ALIGNED};
-
- // Colorspace properties.
-enum {AVS_CS_BGR = 1<<28,
- AVS_CS_YUV = 1<<29,
- AVS_CS_INTERLEAVED = 1<<30,
- AVS_CS_PLANAR = 1<<31};
-
- // Specific colorformats
-enum {
- AVS_CS_UNKNOWN = 0,
- AVS_CS_BGR24 = 1<<0 | AVS_CS_BGR | AVS_CS_INTERLEAVED,
- AVS_CS_BGR32 = 1<<1 | AVS_CS_BGR | AVS_CS_INTERLEAVED,
- AVS_CS_YUY2 = 1<<2 | AVS_CS_YUV | AVS_CS_INTERLEAVED,
- AVS_CS_YV12 = 1<<3 | AVS_CS_YUV | AVS_CS_PLANAR, // y-v-u, planar
- AVS_CS_I420 = 1<<4 | AVS_CS_YUV | AVS_CS_PLANAR, // y-u-v, planar
- AVS_CS_IYUV = 1<<4 | AVS_CS_YUV | AVS_CS_PLANAR // same as above
-};
-
-enum {
- AVS_IT_BFF = 1<<0,
- AVS_IT_TFF = 1<<1,
- AVS_IT_FIELDBASED = 1<<2};
-
-enum {
- AVS_FILTER_TYPE=1,
- AVS_FILTER_INPUT_COLORSPACE=2,
- AVS_FILTER_OUTPUT_TYPE=9,
- AVS_FILTER_NAME=4,
- AVS_FILTER_AUTHOR=5,
- AVS_FILTER_VERSION=6,
- AVS_FILTER_ARGS=7,
- AVS_FILTER_ARGS_INFO=8,
- AVS_FILTER_ARGS_DESCRIPTION=10,
- AVS_FILTER_DESCRIPTION=11};
-
-enum { //SUBTYPES
- AVS_FILTER_TYPE_AUDIO=1,
- AVS_FILTER_TYPE_VIDEO=2,
- AVS_FILTER_OUTPUT_TYPE_SAME=3,
- AVS_FILTER_OUTPUT_TYPE_DIFFERENT=4
Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency
Thanks for clarify the packets-to-frames delay. I will respect that decoder design principle. Add a few backgrounds for this issue. I work on 4K@30fps streaming playback on 16-cores host. Initially I use FF_THREAD_SLICE, but "avcodec_send_packet" takes ~100ms, only 10fps playback (I want 30fps). It is not good for UHD video decoding, and not fully utilizing modern multiple CPU core. Then I switch to FF_THREAD_FRAME (slices parallel disabled), the fps is able to achieve 30fps, but latency also increasing to ~500ms. Ideally, I wish to have FF_THREAD_FRAME+ FF_THREAD_SLICE simultaneously：） Thanks, Jianhui Dai -Original Message- From: ffmpeg-devel On Behalf Of Derek Buitenhuis Sent: Thursday, March 12, 2020 6:44 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] pthread_frame: attempt to get frame to reduce latency On 11/03/2020 20:42, Martin Storsjö wrote: > FWIW, while I agree it shouldn't be the default, I have occasionally > considered the need for this particular feature. Arguably slice threading should be used, but that assumes you have sane input, which is obviously not always the case for some. > Consider a live stream with a very variable framerate, essentially > varying in the full range between 0 and 60 fps. To cope with decoding > the high end of the framerate range, one needs to have frame threading > enabled - maybe not with something crazy like 16 threads, but say at least 5 > or so. > > Then you need to feed 5 packets into the decoder before you get the > first frame output (for a stream without any reordering). That last bit is key there, but yes. > > Now if packets are received at 60 fps, you get one new packet to feed > the decoder per 16 ms, and you get the first frame to output 83 ms > later, assuming that the decoding of that individual frame on that > thread took less than 83 ms (I'm assuming network, etc. has been left out for example's sake. :)) > However, if the rate of input packets drops to e.g. 1 packet per > second, it will take 5 seconds before I have 5 packets to feed to the > decoder, before I have the first frame output, even though it actually > was finished decoding in say less than 100 ms after the first input > packet was given to the decoder. > > So in such a setup, being able to fetch output frames from the decoder > sooner would be very useful - giving a closer to fixed decoding time > in wallclock time, regardless of the packet input rate. Not sure I would refer to it as closer to fixed, but the use case is certainly valid - I never claimed otherwise. If it is added, it needs be behind a flag/option with big bold letters saying the risks, and off by default. And that segfault Michael saw investigated. Thanks for the clear response that doesn't conflate the two. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_hevc: add qmax/qmin support for HEVC encoding
Linjie Fu 于2020年3月11日周三 下午6:44写道：
>
> Add qmax/qmin support for HEVC software bitrate control(SWBRC).
>
> Limitations:
> - RateControlMethod != MFX_RATECONTROL_CQP
> - with EXTBRC ON
>
> Signed-off-by: Dmitry Rogozhkin
> Signed-off-by: Linjie Fu
> ---
>
> Relative code in MSDK for the limitation:
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/encode_hw/hevc/agnostic/g9/hevcehw_g9_legacy.cpp#L4267
>
> libavcodec/qsvenc.c | 11 +--
> libavcodec/qsvenc_hevc.c | 2 ++
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 52b4e43..2c22eb7 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -732,6 +732,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (q->adaptive_b >= 0)
> q->extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
> #endif
> +}
> +
> +if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> AV_CODEC_ID_HEVC) {
> +if (q->extbrc >= 0)
> +q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
>
> #if QSV_VERSION_ATLEAST(1, 9)
> if (avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
> avctx->qmax) {
> @@ -747,12 +752,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
> q->extco2.MaxQPP = q->extco2.MaxQPB = q->extco2.MaxQPI;
> }
> #endif
> -}
> -
> -if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
> AV_CODEC_ID_HEVC) {
> -if (q->extbrc >= 0)
> -q->extco2.ExtBRC = q->extbrc ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
> -
> q->extco2.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2;
> q->extco2.Header.BufferSz = sizeof(q->extco2);
>
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 27e2232..3bdca7d 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -262,6 +262,8 @@ static const AVCodecDefault qsv_enc_defaults[] = {
> // same as the x264 default
> { "g", "248" },
> { "bf","8" },
> +{ "qmin", "-1"},
> +{ "qmax", "-1"},
> { "trellis", "-1"},
> { "flags", "+cgop" },
> #if FF_API_PRIVATE_OPT
> --
> 2.7.4
LGTM, 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".
[FFmpeg-devel] [PATCH] avformat/hlsenc: remove redundant hlsenc_io_close in hls_write_trailer
fix ticket: 8566
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4b28c412fa..75e75ff57a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2587,7 +2587,6 @@ static int hls_write_trailer(struct AVFormatContext *s)
goto failed;
vs->size = range_length;
-hlsenc_io_close(s, &vs->out, filename);
ret = hlsenc_io_close(s, &vs->out, filename);
if (ret < 0) {
av_log(s, AV_LOG_WARNING, "upload segment failed, will retry with
a new http session.\n");
--
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: remove redundant hlsenc_io_close in hls_write_trailer
> 2020年3月12日 上午11:02，Steven Liu 写道：
>
> fix ticket: 8566
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 4b28c412fa..75e75ff57a 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2587,7 +2587,6 @@ static int hls_write_trailer(struct AVFormatContext *s)
> goto failed;
>
> vs->size = range_length;
> -hlsenc_io_close(s, &vs->out, filename);
> ret = hlsenc_io_close(s, &vs->out, filename);
> if (ret < 0) {
> av_log(s, AV_LOG_WARNING, "upload segment failed, will retry with
> a new http session.\n");
> --
> 2.25.0
>
This patch should remove the comment fix ticket: 8566
Just remove the redundant hlsenc_io_close
Thanks
Steven
___
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] avformat/hlsenc: Fix initial setting for start_pts
> 2020年3月11日 上午7:06，Steven Liu 写道：
>
>>
>> 2020年3月7日 上午11:26，Steven Liu 写道：
>>
>>
>>
>>> 2020年3月6日 上午11:58，Hongcheng Zhong 写道：
>>>
>>> This patch fixes Bug #8469
>>> If x264 baseline profile is used with other profiles,
>>> start_pts will be initialized to audio stream's first pts,
>>> while the duration is calculated based on video stream's pts.
>>> In this patch the start_pts is initialized with the correct stream's first
>>> pts.
>>>
>>> Signed-off-by: Hongcheng Zhong
>>> ---
>>> libavformat/hlsenc.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index f6dd894..19aa2b1 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -126,6 +126,7 @@ typedef struct VariantStream {
>>> int has_video;
>>> int has_subtitle;
>>> int new_start;
>>> +int start_pts_from_audio;
>>> double dpp; // duration per packet
>>> int64_t start_pts;
>>> int64_t end_pts;
>>> @@ -2274,6 +2275,12 @@ static int hls_write_packet(AVFormatContext *s,
>>> AVPacket *pkt)
>>>
>>> if (vs->start_pts == AV_NOPTS_VALUE) {
>>> vs->start_pts = pkt->pts;
>>> +if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO)
>>> +vs->start_pts_from_audio = 1;
>>> +}
>>> +if (vs->start_pts_from_audio && st->codecpar->codec_type ==
>>> AVMEDIA_TYPE_VIDEO && vs->start_pts > pkt->pts) {
>>> +vs->start_pts = pkt->pts;
>>> +vs->start_pts_from_audio = 0;
>>> }
>>>
>>> if (vs->has_video) {
>>> --
>>> 2.7.4
>>>
>>> ___
>>> 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”.
>> LGTM
>>
>
> Will apply if there have no more comments.
Applied
>
> Thanks
>
> Steven
___
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".
