Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for FreeBSD
On 19.05.2024 02:00, Brad Smith wrote: configure: enable ffnvcodec, nvenc, nvdec for FreeBSD Signed-off-by: Brad Smith --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index b16722d83d..96b181fd21 100755 --- a/configure +++ b/configure @@ -7350,7 +7350,7 @@ fi if enabled x86; then case $target_os in -mingw32*|mingw64*|win32|win64|linux|cygwin*) +freebsd|mingw32*|mingw64*|win32|win64|linux|cygwin*) Does this actually work? Everything I find online indicates that the FreeBSD driver is lacking support for CUDA, nvenc and most of anything compute related. ___ 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] [RFC 00/13] flvdec/flvenc: add support for enhanced rtmp codecs and multitrack/multichannel
This is based on the preliminary spec for enhanced rtmp v2: https://veovera.org/docs/enhanced/enhanced-rtmp-v2 The spec is not final, and can still undergo breaking changes, hence this set is purely for comments and review, and not ready to be merged until the final v2 spec is published. There are no samples out in the wild yet, so testing interoperability with other software has not happened yet either. Specially the two other multitrack modes, where multiple tracks are in the same packet, have not been tested at all, since no software can write such files. The set can also be found on GitHub, where ignoring whitespaces makes specially the last patch a lot more readable: https://github.com/BtbN/FFmpeg/tree/enhanced-flv Dennis Sädtler via ffmpeg-devel (2): avformat/flvenc: Implement support for multi-track video avformat/flvdec: Add support for demuxing multi-track FLV Timo Rothenpieler (11): avformat/flvenc: add enhanced audio codecs avformat/flvenc: remove !size check for audio packets avformat/flvdec: add enhanced audio codecs avformat/flvenc: refactor fourcc writing avformat/flvenc: write enhanced rtmp multichannel info for audio with more than two channels avformat/flvdec: parse enhanced rtmp multichannel info avformat/flvenc: add support for writing multi track audio avformat/flvdec: add support for reading multi track audio avformat/rtmpproto: add more enhanced rtmp codecs avformat/flvdec: stop shadowing local variables avformat/flvdec: support all multi-track modes libavformat/flv.h | 21 ++ libavformat/flvdec.c| 654 +++- libavformat/flvenc.c| 443 +-- libavformat/rtmpproto.c | 11 +- 4 files changed, 819 insertions(+), 310 deletions(-) -- 2.43.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 01/13] avformat/flvenc: Implement support for multi-track video
From: Dennis Sädtler via ffmpeg-devel
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2
This implementation maintains some backwards compatibility by only
writing the track information for track indices > 0. This means that
older FFmpeg versions - and possibly other software - can still read the
first video track properly and skip over unsupported packets.
Signed-off-by: Dennis Sädtler
---
libavformat/flv.h| 7 ++
libavformat/flvenc.c | 158 ++-
2 files changed, 118 insertions(+), 47 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index f710963b92..653c2bc82c 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -125,6 +125,13 @@ enum {
PacketTypeCodedFramesX = 3,
PacketTypeMetadata = 4,
PacketTypeMPEG2TSSequenceStart = 5,
+PacketTypeMultitrack= 6,
+};
+
+enum {
+ MultitrackTypeOneTrack = 0x00,
+ MultitrackTypeManyTracks = 0x10,
+ MultitrackTypeManyTracksManyCodecs = 0x20,
};
enum {
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index aba1d7d80b..7ddc59e369 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -125,8 +125,9 @@ typedef struct FLVContext {
AVCodecParameters *data_par;
int flags;
-int64_t last_ts[FLV_STREAM_TYPE_NB];
-int metadata_pkt_written;
+int64_t *last_ts;
+int *metadata_pkt_written;
+int *video_track_idx_map;
} FLVContext;
static int get_audio_flags(AVFormatContext *s, AVCodecParameters *par)
@@ -484,7 +485,7 @@ static void write_metadata(AVFormatContext *s, unsigned int
ts)
avio_wb32(pb, flv->metadata_totalsize + 11);
}
-static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters
*par, unsigned int ts)
+static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters
*par, unsigned int ts, int stream_idx)
{
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
@@ -494,7 +495,9 @@ static void flv_write_metadata_packet(AVFormatContext *s,
AVCodecParameters *par
int64_t total_size = 0;
const AVPacketSideData *side_data = NULL;
-if (flv->metadata_pkt_written) return;
+if (flv->metadata_pkt_written[stream_idx])
+return;
+
if (par->codec_id == AV_CODEC_ID_HEVC || par->codec_id == AV_CODEC_ID_AV1
||
par->codec_id == AV_CODEC_ID_VP9) {
int flags_size = 5;
@@ -616,7 +619,7 @@ static void flv_write_metadata_packet(AVFormatContext *s,
AVCodecParameters *par
avio_wb24(pb, total_size);
avio_skip(pb, total_size + 10 - 3);
avio_wb32(pb, total_size + 11); // previous tag size
-flv->metadata_pkt_written = 1;
+flv->metadata_pkt_written[stream_idx] = 1;
}
}
@@ -631,7 +634,7 @@ static int unsupported_codec(AVFormatContext *s,
return AVERROR(ENOSYS);
}
-static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts) {
+static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts, int stream_index) {
int64_t data_size;
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
@@ -681,12 +684,32 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
}
avio_write(pb, par->extradata, par->extradata_size);
} else {
-if (par->codec_id == AV_CODEC_ID_HEVC) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY); // ExVideoTagHeader mode with PacketTypeSequenceStart
-avio_write(pb, "hvc1", 4);
-} else if (par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY);
-avio_write(pb, par->codec_id == AV_CODEC_ID_AV1 ? "av01" :
"vp09", 4);
+int track_idx = flv->video_track_idx_map[stream_index];
+// If video stream has track_idx > 0 we need to send H.264 as
extended video packet
+int extended_flv = (par->codec_id == AV_CODEC_ID_H264 && track_idx)
+|| par->codec_id == AV_CODEC_ID_HEVC
+|| par->codec_id == AV_CODEC_ID_AV1
+|| par->codec_id == AV_CODEC_ID_VP9;
+
+if (extended_flv) {
+if (track_idx) {
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMultitrack |
FLV_FRAME_KEY);
+avio_w8(pb, MultitrackTypeOneTrack |
PacketTypeSequenceStart);
+} else {
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY);
+}
+
+if (par->codec_id == AV_CODEC_ID_H264)
+avio_write(pb, "avc1", 4);
+else if (par->codec_id == AV_CODEC_
[FFmpeg-devel] [PATCH 02/13] avformat/flvdec: Add support for demuxing multi-track FLV
From: Dennis Sädtler via ffmpeg-devel
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2
Signed-off-by: Dennis Sädtler
---
libavformat/flvdec.c | 117 +++
1 file changed, 96 insertions(+), 21 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 22a9b9e4a7..2445d1fd5e 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -105,6 +105,10 @@ typedef struct FLVContext {
FLVMetaVideoColor *metaVideoColor;
int meta_color_info_flag;
+
+uint8_t **mt_extradata;
+int *mt_extradata_sz;
+int mt_extradata_cnt;
} FLVContext;
/* AMF date type */
@@ -187,13 +191,18 @@ static void add_keyframes_index(AVFormatContext *s)
}
}
-static AVStream *create_stream(AVFormatContext *s, int codec_type)
+static AVStream *create_stream(AVFormatContext *s, int codec_type, int
track_idx)
{
FLVContext *flv = s->priv_data;
AVStream *st = avformat_new_stream(s, NULL);
if (!st)
return NULL;
st->codecpar->codec_type = codec_type;
+st->id = track_idx;
+avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
+if (track_idx)
+return st;
+
if (s->nb_streams>=3 ||( s->nb_streams==2
&& s->streams[0]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
&& s->streams[1]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
@@ -210,8 +219,6 @@ static AVStream *create_stream(AVFormatContext *s, int
codec_type)
st->avg_frame_rate = flv->framerate;
}
-
-avpriv_set_pts_info(st, 32, 1, 1000); /* 32 bit pts in ms */
flv->last_keyframe_stream_index = s->nb_streams - 1;
add_keyframes_index(s);
return st;
@@ -351,6 +358,7 @@ static int flv_same_video_codec(AVCodecParameters *vpar,
uint32_t flv_codecid)
case FLV_CODECID_VP6A:
return vpar->codec_id == AV_CODEC_ID_VP6A;
case FLV_CODECID_H264:
+case MKBETAG('a', 'v', 'c', '1'):
return vpar->codec_id == AV_CODEC_ID_H264;
default:
return vpar->codec_tag == flv_codecid;
@@ -407,6 +415,7 @@ static int flv_set_video_codec(AVFormatContext *s, AVStream
*vstream,
ret = 1; // 1 byte body size adjustment for flv_read_packet()
break;
case FLV_CODECID_H264:
+case MKBETAG('a', 'v', 'c', '1'):
par->codec_id = AV_CODEC_ID_H264;
vstreami->need_parsing = AVSTREAM_PARSE_HEADERS;
break;
@@ -676,7 +685,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream
*astream,
} else if (!strcmp(key, "height") && vpar) {
vpar->height = num_val;
} else if (!strcmp(key, "datastream")) {
-AVStream *st = create_stream(s, AVMEDIA_TYPE_SUBTITLE);
+AVStream *st = create_stream(s, AVMEDIA_TYPE_SUBTITLE,
0);
if (!st)
return AVERROR(ENOMEM);
st->codecpar->codec_id = AV_CODEC_ID_TEXT;
@@ -885,6 +894,9 @@ static int flv_read_close(AVFormatContext *s)
FLVContext *flv = s->priv_data;
for (i=0; inew_extradata[i]);
+for (i=0; i < flv->mt_extradata_cnt; i++)
+av_freep(&flv->mt_extradata[i]);
+av_freep(&flv->mt_extradata_sz);
av_freep(&flv->keyframe_times);
av_freep(&flv->keyframe_filepositions);
av_freep(&flv->metaVideoColor);
@@ -904,18 +916,47 @@ static int flv_get_extradata(AVFormatContext *s, AVStream
*st, int size)
}
static int flv_queue_extradata(FLVContext *flv, AVIOContext *pb, int stream,
- int size)
+ int size, int multitrack)
{
if (!size)
return 0;
-av_free(flv->new_extradata[stream]);
-flv->new_extradata[stream] = av_mallocz(size +
-AV_INPUT_BUFFER_PADDING_SIZE);
-if (!flv->new_extradata[stream])
-return AVERROR(ENOMEM);
-flv->new_extradata_size[stream] = size;
-avio_read(pb, flv->new_extradata[stream], size);
+if (!multitrack) {
+av_free(flv->new_extradata[stream]);
+flv->new_extradata[stream] = av_mallocz(size +
+AV_INPUT_BUFFER_PADDING_SIZE);
+if (!flv->new_extradata[stream])
+return AVERROR(ENOMEM);
+flv->new_extradata_size[stream] = size;
+avio_read(pb, flv->new_extradata[stream], size);
+} else {
+int new_count = stream + 1;
+
+if (flv->mt_extradata_cnt < new_count) {
+flv->mt_extradata = av_realloc(flv->mt_extradata,
+ sizeof(*flv->mt_extradata) *
+ new_count);
+flv->mt_extradata_sz = av_realloc(flv->mt_extradata_sz,
+ sizeof(*flv->mt_extradata_sz) *
[FFmpeg-devel] [PATCH 03/13] avformat/flvenc: add enhanced audio codecs
---
libavformat/flv.h| 6 ++
libavformat/flvenc.c | 143 +++
2 files changed, 111 insertions(+), 38 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index 653c2bc82c..d030d576f3 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -103,6 +103,7 @@ enum {
FLV_CODECID_NELLYMOSER = 6 << FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_PCM_ALAW = 7 << FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_PCM_MULAW= 8 << FLV_AUDIO_CODECID_OFFSET,
+FLV_CODECID_EX_HEADER= 9 << FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_AAC = 10<< FLV_AUDIO_CODECID_OFFSET,
FLV_CODECID_SPEEX= 11<< FLV_AUDIO_CODECID_OFFSET,
};
@@ -128,6 +129,11 @@ enum {
PacketTypeMultitrack= 6,
};
+enum {
+AudioPacketTypeSequenceStart = 0,
+AudioPacketTypeCodedFrames= 1,
+};
+
enum {
MultitrackTypeOneTrack = 0x00,
MultitrackTypeManyTracks = 0x10,
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 7ddc59e369..4e79b06499 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -68,6 +68,10 @@ static const AVCodecTag flv_audio_codec_ids[] = {
{ AV_CODEC_ID_PCM_MULAW, FLV_CODECID_PCM_MULAW >>
FLV_AUDIO_CODECID_OFFSET },
{ AV_CODEC_ID_PCM_ALAW, FLV_CODECID_PCM_ALAW >>
FLV_AUDIO_CODECID_OFFSET },
{ AV_CODEC_ID_SPEEX, FLV_CODECID_SPEEX >>
FLV_AUDIO_CODECID_OFFSET },
+{ AV_CODEC_ID_OPUS, MKBETAG('O', 'p', 'u', 's') },
+{ AV_CODEC_ID_FLAC, MKBETAG('f', 'L', 'a', 'C') },
+{ AV_CODEC_ID_AC3,MKBETAG('a', 'c', '-', '3') },
+{ AV_CODEC_ID_EAC3, MKBETAG('e', 'c', '-', '3') },
{ AV_CODEC_ID_NONE, 0 }
};
@@ -138,6 +142,9 @@ static int get_audio_flags(AVFormatContext *s,
AVCodecParameters *par)
if (par->codec_id == AV_CODEC_ID_AAC) // specs force these parameters
return FLV_CODECID_AAC | FLV_SAMPLERATE_44100HZ |
FLV_SAMPLESSIZE_16BIT | FLV_STEREO;
+if (par->codec_id == AV_CODEC_ID_OPUS || par->codec_id == AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3 || par->codec_id ==
AV_CODEC_ID_EAC3)
+return FLV_CODECID_EX_HEADER; // only needed for codec support check
else if (par->codec_id == AV_CODEC_ID_SPEEX) {
if (par->sample_rate != 16000) {
av_log(s, AV_LOG_ERROR,
@@ -634,6 +641,42 @@ static int unsupported_codec(AVFormatContext *s,
return AVERROR(ENOSYS);
}
+static void flv_write_aac_header(AVFormatContext* s, AVCodecParameters* par)
+{
+AVIOContext *pb = s->pb;
+FLVContext *flv = s->priv_data;
+
+if (!par->extradata_size && (flv->flags & FLV_AAC_SEQ_HEADER_DETECT)) {
+PutBitContext pbc;
+int samplerate_index;
+int channels = par->ch_layout.nb_channels
+- (par->ch_layout.nb_channels == 8 ? 1 : 0);
+uint8_t data[2];
+
+for (samplerate_index = 0; samplerate_index < 16;
+samplerate_index++)
+if (par->sample_rate
+== ff_mpeg4audio_sample_rates[samplerate_index])
+break;
+
+init_put_bits(&pbc, data, sizeof(data));
+put_bits(&pbc, 5, par->profile + 1); //profile
+put_bits(&pbc, 4, samplerate_index); //sample rate index
+put_bits(&pbc, 4, channels);
+put_bits(&pbc, 1, 0); //frame length - 1024 samples
+put_bits(&pbc, 1, 0); //does not depend on core coder
+put_bits(&pbc, 1, 0); //is not extension
+flush_put_bits(&pbc);
+
+avio_w8(pb, data[0]);
+avio_w8(pb, data[1]);
+
+av_log(s, AV_LOG_WARNING, "AAC sequence header: %02x %02x.\n",
+data[0], data[1]);
+}
+avio_write(pb, par->extradata, par->extradata_size);
+}
+
static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts, int stream_index) {
int64_t data_size;
AVIOContext *pb = s->pb;
@@ -641,7 +684,9 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC
-|| par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9) {
+|| par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9
+|| par->codec_id == AV_CODEC_ID_OPUS || par->codec_id ==
AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3 || par->codec_id ==
AV_CODEC_ID_EAC3) {
int64_t pos;
avio_w8(pb,
par->codec_type == AVMEDIA_TYPE_VIDEO ?
@@ -650,39 +695,38 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
put_timestamp(pb, ts);
avio_wb24(pb, 0); // streamid
pos = avio_tell(pb);
-if (par->codec_id == A
[FFmpeg-devel] [PATCH 04/13] avformat/flvenc: remove !size check for audio packets
---
libavformat/flvenc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 4e79b06499..13e06aedbb 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -1067,11 +1067,6 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
|| par->codec_id == AV_CODEC_ID_AC3
|| par->codec_id == AV_CODEC_ID_EAC3;
-if (par->codec_type == AVMEDIA_TYPE_AUDIO && !pkt->size) {
-av_log(s, AV_LOG_WARNING, "Empty audio Packet\n");
-return AVERROR(EINVAL);
-}
-
if (extended_audio)
flags_size = 5;
else if (par->codec_id == AV_CODEC_ID_VP6F || par->codec_id ==
AV_CODEC_ID_VP6A ||
@@ -1146,8 +1141,6 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
case AVMEDIA_TYPE_AUDIO:
flags = get_audio_flags(s, par);
-av_assert0(size);
-
avio_w8(pb, FLV_TAG_TYPE_AUDIO);
break;
case AVMEDIA_TYPE_SUBTITLE:
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 11/13] avformat/rtmpproto: add more enhanced rtmp codecs
---
libavformat/rtmpproto.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index bc3d9df7b9..7bbb6d5313 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -356,9 +356,16 @@ static int gen_connect(URLContext *s, RTMPContext *rt)
while(fourcc_data - rt->enhanced_codecs < fourcc_str_len) {
unsigned char fourcc[5];
-if (!strncmp(fourcc_data, "hvc1", 4) ||
+if (!strncmp(fourcc_data, "avc1", 4) ||
+!strncmp(fourcc_data, "hvc1", 4) ||
!strncmp(fourcc_data, "av01", 4) ||
-!strncmp(fourcc_data, "vp09", 4)) {
+!strncmp(fourcc_data, "vp09", 4) ||
+!strncmp(fourcc_data, "mp4a", 4) ||
+!strncmp(fourcc_data, "Opus", 4) ||
+!strncmp(fourcc_data, "fLaC", 4) ||
+!strncmp(fourcc_data, ".mp3", 4) ||
+!strncmp(fourcc_data, "ac-3", 4) ||
+!strncmp(fourcc_data, "ec-3", 4)) {
av_strlcpy(fourcc, fourcc_data, sizeof(fourcc));
ff_amf_write_string(&p, fourcc);
} else {
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 12/13] avformat/flvdec: stop shadowing local variables
---
libavformat/flvdec.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 5877828c52..4f98ff348c 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1394,8 +1394,8 @@ retry:
if (enhanced_flv && (flags & FLV_VIDEO_FRAMETYPE_MASK) ==
FLV_FRAME_VIDEO_INFO_CMD) {
if (pkt_type == PacketTypeMetadata) {
-int ret = flv_parse_video_color_info(s, st, next);
-av_log(s, AV_LOG_DEBUG, "enhanced flv parse metadata ret %d
and skip\n", ret);
+int sret = flv_parse_video_color_info(s, st, next);
+av_log(s, AV_LOG_DEBUG, "enhanced flv parse metadata ret %d
and skip\n", sret);
}
goto skip;
} else if ((flags & FLV_VIDEO_FRAMETYPE_MASK) ==
FLV_FRAME_VIDEO_INFO_CMD) {
@@ -1498,25 +1498,25 @@ skip:
if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
(!s->duration || s->duration == AV_NOPTS_VALUE) &&
!flv->searched_for_end) {
-int size;
+int final_size;
const int64_t pos = avio_tell(s->pb);
// Read the last 4 bytes of the file, this should be the size of the
// previous FLV tag. Use the timestamp of its payload as duration.
int64_t fsize = avio_size(s->pb);
retry_duration:
avio_seek(s->pb, fsize - 4, SEEK_SET);
-size = avio_rb32(s->pb);
-if (size > 0 && size < fsize) {
-// Seek to the start of the last FLV tag at position (fsize - 4 -
size)
+final_size = avio_rb32(s->pb);
+if (final_size > 0 && final_size < fsize) {
+// Seek to the start of the last FLV tag at position (fsize - 4 -
final_size)
// but skip the byte indicating the type.
-avio_seek(s->pb, fsize - 3 - size, SEEK_SET);
-if (size == avio_rb24(s->pb) + 11) {
+avio_seek(s->pb, fsize - 3 - final_size, SEEK_SET);
+if (final_size == avio_rb24(s->pb) + 11) {
uint32_t ts = avio_rb24(s->pb);
ts |= (unsigned)avio_r8(s->pb) << 24;
if (ts)
s->duration = ts * (int64_t)AV_TIME_BASE / 1000;
-else if (fsize >= 8 && fsize - 8 >= size) {
-fsize -= size+4;
+else if (fsize >= 8 && fsize - 8 >= final_size) {
+fsize -= final_size+4;
goto retry_duration;
}
}
@@ -1610,10 +1610,10 @@ retry_duration:
goto leave;
}
} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
-int ret = flv_set_video_codec(s, st, codec_id, 1);
-if (ret < 0)
-return ret;
-size -= ret;
+int sret = flv_set_video_codec(s, st, codec_id, 1);
+if (sret < 0)
+return sret;
+size -= sret;
} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
st->codecpar->codec_id = AV_CODEC_ID_TEXT;
} else if (stream_type == FLV_STREAM_TYPE_DATA) {
@@ -1703,20 +1703,20 @@ retry_duration:
pkt->stream_index = st->index;
pkt->pos = pos;
if (!multitrack && flv->new_extradata[stream_type]) {
-int ret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
- flv->new_extradata[stream_type],
-
flv->new_extradata_size[stream_type]);
-if (ret >= 0) {
+int sret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+ flv->new_extradata[stream_type],
+
flv->new_extradata_size[stream_type]);
+if (sret >= 0) {
flv->new_extradata[stream_type] = NULL;
flv->new_extradata_size[stream_type] = 0;
}
} else if (multitrack
&& flv->mt_extradata_cnt > track_idx
&& flv->mt_extradata[track_idx]) {
-int ret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
- flv->mt_extradata[track_idx],
- flv->mt_extradata_sz[track_idx]);
-if (ret >= 0) {
+int sret = av_packet_add_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+ flv->mt_extradata[track_idx],
+ flv->mt_extradata_sz[track_idx]);
+if (sret >= 0) {
flv->mt_extradata[track_idx] = NULL;
flv->mt_extradata_sz[track_idx] = 0;
}
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 13/13] avformat/flvdec: support all multi-track modes
---
libavformat/flvdec.c | 570 +++
1 file changed, 306 insertions(+), 264 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4f98ff348c..ee22db2ce2 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1273,6 +1273,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
{
FLVContext *flv = s->priv_data;
int ret, i, size, flags;
+int res = 0;
enum FlvTagType type;
int stream_type=-1;
int64_t next, pos, meta_pos;
@@ -1287,6 +1288,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
int pkt_type = 0;
uint8_t track_idx = 0;
uint32_t codec_id = 0;
+int multitrack_type = MultitrackTypeOneTrack;
retry:
/* pkt size is repeated at end. skip it */
@@ -1337,14 +1339,9 @@ retry:
if (pkt_type == AudioPacketTypeMultitrack) {
uint8_t types = avio_r8(s->pb);
-int multitrack_type = types >> 4;
+multitrack_type = types & 0xF0;
pkt_type = types & 0xF;
-if (multitrack_type != MultitrackTypeOneTrack) {
-av_log(s, AV_LOG_ERROR, "Audio multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
-return AVERROR_PATCHWELCOME;
-}
-
multitrack = 1;
size--;
}
@@ -1371,14 +1368,9 @@ retry:
if (pkt_type == PacketTypeMultitrack) {
uint8_t types = avio_r8(s->pb);
-int multitrack_type = types >> 4;
+multitrack_type = types & 0xF0;
pkt_type = types & 0xF;
-if (multitrack_type != MultitrackTypeOneTrack) {
-av_log(s, AV_LOG_ERROR, "Multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
-return AVERROR_PATCHWELCOME;
-}
-
multitrack = 1;
size--;
}
@@ -1447,293 +1439,343 @@ skip:
goto leave;
}
-/* now find stream */
-for (i = 0; i < s->nb_streams; i++) {
-st = s->streams[i];
-if (stream_type == FLV_STREAM_TYPE_AUDIO) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
-(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
-st->id == track_idx)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
-(s->video_codec_id || flv_same_video_codec(st->codecpar,
codec_id)) &&
-st->id == track_idx)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_DATA) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
-break;
+for (;;) {
+int track_size = size;
+
+if (multitrack_type != MultitrackTypeOneTrack) {
+track_size = avio_rb24(s->pb);
+size -= 3;
}
-}
-if (i == s->nb_streams) {
-static const enum AVMediaType stream_types[] = {AVMEDIA_TYPE_VIDEO,
AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE, AVMEDIA_TYPE_DATA};
-st = create_stream(s, stream_types[stream_type], track_idx);
-if (!st)
-return AVERROR(ENOMEM);
-}
-av_log(s, AV_LOG_TRACE, "%d %X %d \n", stream_type, flags, st->discard);
-if (flv->time_pos <= pos) {
-dts += flv->time_offset;
-}
+/* now find stream */
+for (i = 0; i < s->nb_streams; i++) {
+st = s->streams[i];
+if (stream_type == FLV_STREAM_TYPE_AUDIO) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
+(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
+st->id == track_idx)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
+(s->video_codec_id || flv_same_video_codec(st->codecpar,
codec_id)) &&
+st->id == track_idx)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_DATA) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
+break;
+}
+}
+if (i == s->nb_streams) {
+static const enum AVMediaType stream_types[] =
{AVMEDIA_TYPE_VIDEO, AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE,
AVMEDIA_TYPE_DATA};
+st = create_stream(s, stream_types[stream_type], track_idx);
+if (!st)
+
[FFmpeg-devel] [PATCH 05/13] avformat/flvdec: add enhanced audio codecs
---
libavformat/flv.h| 8 +++
libavformat/flvdec.c | 119 +++
2 files changed, 116 insertions(+), 11 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index d030d576f3..8926db6388 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -132,6 +132,14 @@ enum {
enum {
AudioPacketTypeSequenceStart = 0,
AudioPacketTypeCodedFrames= 1,
+AudioPacketTypeMultichannelConfig = 4,
+AudioPacketTypeMultitrack = 5,
+};
+
+enum {
+AudioChannelOrderUnspecified = 0,
+AudioChannelOrderNative = 1,
+AudioChannelOrderCustom = 2,
};
enum {
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 2445d1fd5e..ee2a1931b2 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -224,12 +224,33 @@ static AVStream *create_stream(AVFormatContext *s, int
codec_type, int track_idx
return st;
}
-static int flv_same_audio_codec(AVCodecParameters *apar, int flags)
+static int flv_same_audio_codec(AVCodecParameters *apar, int flags, uint32_t
codec_fourcc)
{
int bits_per_coded_sample = (flags & FLV_AUDIO_SAMPLESIZE_MASK) ? 16 : 8;
int flv_codecid = flags & FLV_AUDIO_CODECID_MASK;
int codec_id;
+switch (codec_fourcc) {
+case MKBETAG('m', 'p', '4', 'a'):
+return apar->codec_id == AV_CODEC_ID_AAC;
+case MKBETAG('O', 'p', 'u', 's'):
+return apar->codec_id == AV_CODEC_ID_OPUS;
+case MKBETAG('.', 'm', 'p', '3'):
+return apar->codec_id == AV_CODEC_ID_MP3;
+case MKBETAG('f', 'L', 'a', 'C'):
+return apar->codec_id == AV_CODEC_ID_FLAC;
+case MKBETAG('a', 'c', '-', '3'):
+return apar->codec_id == AV_CODEC_ID_AC3;
+case MKBETAG('e', 'c', '-', '3'):
+return apar->codec_id == AV_CODEC_ID_EAC3;
+case 0:
+// Not enhanced flv, continue as normal.
+break;
+default:
+// Unknown FOURCC
+return 0;
+}
+
if (!apar->codec_id && !apar->codec_tag)
return 1;
@@ -328,6 +349,24 @@ static void flv_set_audio_codec(AVFormatContext *s,
AVStream *astream,
apar->sample_rate = 8000;
apar->codec_id= AV_CODEC_ID_PCM_ALAW;
break;
+case MKBETAG('m', 'p', '4', 'a'):
+apar->codec_id = AV_CODEC_ID_AAC;
+return;
+case MKBETAG('O', 'p', 'u', 's'):
+apar->codec_id = AV_CODEC_ID_OPUS;
+return;
+case MKBETAG('.', 'm', 'p', '3'):
+apar->codec_id = AV_CODEC_ID_MP3;
+return;
+case MKBETAG('f', 'L', 'a', 'C'):
+apar->codec_id = AV_CODEC_ID_FLAC;
+return;
+case MKBETAG('a', 'c', '-', '3'):
+apar->codec_id = AV_CODEC_ID_AC3;
+return;
+case MKBETAG('e', 'c', '-', '3'):
+apar->codec_id = AV_CODEC_ID_EAC3;
+return;
default:
avpriv_request_sample(s, "Audio codec (%x)",
flv_codecid >> FLV_AUDIO_CODECID_OFFSET);
@@ -1247,7 +1286,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
int multitrack = 0;
int pkt_type = 0;
uint8_t track_idx = 0;
-uint32_t video_codec_id = 0;
+uint32_t codec_id = 0;
retry:
/* pkt size is repeated at end. skip it */
@@ -1291,16 +1330,31 @@ retry:
stream_type = FLV_STREAM_TYPE_AUDIO;
flags= avio_r8(s->pb);
size--;
+
+if ((flags & FLV_AUDIO_CODECID_MASK) == FLV_CODECID_EX_HEADER) {
+enhanced_flv = 1;
+pkt_type = flags & ~FLV_AUDIO_CODECID_MASK;
+
+channels = 0;
+
+if (pkt_type == AudioPacketTypeMultitrack) {
+av_log(s, AV_LOG_ERROR, "Multitrack audio is unsupported!\n");
+return AVERROR_PATCHWELCOME;
+}
+
+codec_id = avio_rb32(s->pb);
+size -= 4;
+}
} else if (type == FLV_TAG_TYPE_VIDEO) {
stream_type = FLV_STREAM_TYPE_VIDEO;
flags= avio_r8(s->pb);
-video_codec_id = flags & FLV_VIDEO_CODECID_MASK;
+codec_id = flags & FLV_VIDEO_CODECID_MASK;
/*
* Reference Enhancing FLV 2023-03-v1.0.0-B.8
*
https://github.com/veovera/enhanced-rtmp/blob/main/enhanced-rtmp-v1.pdf
* */
enhanced_flv = (flags >> 7) & 1;
-pkt_type = enhanced_flv ? video_codec_id : 0;
+pkt_type = enhanced_flv ? codec_id : 0;
size--;
if (pkt_type == PacketTypeMultitrack) {
@@ -1318,7 +1372,7 @@ retry:
}
if (enhanced_flv) {
-video_codec_id = avio_rb32(s->pb);
+codec_id = avio_rb32(s->pb);
size -= 4;
}
if (multitrack) {
@@ -1386,11 +1440,11 @@ skip:
st = s->streams[i];
if (stream_type == FLV_STREAM_TYPE_AUDIO) {
if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
-(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags)))
+(s->audio_codec_id || flv_same_a
[FFmpeg-devel] [PATCH 06/13] avformat/flvenc: refactor fourcc writing
---
libavformat/flvenc.c | 96 ++--
1 file changed, 47 insertions(+), 49 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 13e06aedbb..94d633fbca 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -492,6 +492,45 @@ static void write_metadata(AVFormatContext *s, unsigned
int ts)
avio_wb32(pb, flv->metadata_totalsize + 11);
}
+static void write_codec_fourcc(AVIOContext *pb, enum AVCodecID codec_id)
+{
+switch (codec_id) {
+case AV_CODEC_ID_AAC:
+avio_write(pb, "mp4a", 4);
+return;
+case AV_CODEC_ID_OPUS:
+avio_write(pb, "Opus", 4);
+return;
+case AV_CODEC_ID_FLAC:
+avio_write(pb, "fLaC", 4);
+return;
+case AV_CODEC_ID_MP3:
+avio_write(pb, ".mp3", 4);
+return;
+case AV_CODEC_ID_AC3:
+avio_write(pb, "ac-3", 4);
+return;
+case AV_CODEC_ID_EAC3:
+avio_write(pb, "ec-3", 4);
+return;
+case AV_CODEC_ID_H264:
+avio_write(pb, "avc1", 4);
+return;
+case AV_CODEC_ID_HEVC:
+avio_write(pb, "hvc1", 4);
+return;
+case AV_CODEC_ID_AV1:
+avio_write(pb, "av01", 4);
+return;
+case AV_CODEC_ID_VP9:
+avio_write(pb, "vp09", 4);
+return;
+default:
+av_log(NULL, AV_LOG_ERROR, "Invalid codec FourCC write requested.\n");
+av_assert0(0);
+}
+}
+
static void flv_write_metadata_packet(AVFormatContext *s, AVCodecParameters
*par, unsigned int ts, int stream_idx)
{
AVIOContext *pb = s->pb;
@@ -528,13 +567,8 @@ static void flv_write_metadata_packet(AVFormatContext *s,
AVCodecParameters *par
put_timestamp(pb, ts); //ts = pkt->dts, gen
avio_wb24(pb, flv->reserved);
-if (par->codec_id == AV_CODEC_ID_HEVC) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata|
FLV_FRAME_VIDEO_INFO_CMD); // ExVideoTagHeader mode with PacketTypeMetadata
-avio_write(pb, "hvc1", 4);
-} else if (par->codec_id == AV_CODEC_ID_AV1 || par->codec_id ==
AV_CODEC_ID_VP9) {
-avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata|
FLV_FRAME_VIDEO_INFO_CMD);
-avio_write(pb, par->codec_id == AV_CODEC_ID_AV1 ? "av01" : "vp09",
4);
-}
+avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeMetadata |
FLV_FRAME_VIDEO_INFO_CMD); // ExVideoTagHeader mode with PacketTypeMetadata
+write_codec_fourcc(pb, par->codec_id);
avio_w8(pb, AMF_DATA_TYPE_STRING);
put_amf_string(pb, "colorInfo");
@@ -703,24 +737,14 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (extended_flv) {
avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
+write_codec_fourcc(pb, par->codec_id);
if (par->codec_id == AV_CODEC_ID_AAC) {
-avio_write(pb, "mp4a", 4);
flv_write_aac_header(s, par);
-} else if (par->codec_id == AV_CODEC_ID_OPUS) {
-avio_write(pb, "Opus", 4);
+} else if (par->codec_id == AV_CODEC_ID_OPUS || par->codec_id
== AV_CODEC_ID_FLAC) {
av_assert0(par->extradata_size);
avio_write(pb, par->extradata, par->extradata_size);
-} else if (par->codec_id == AV_CODEC_ID_FLAC) {
-avio_write(pb, "fLaC", 4);
-av_assert0(par->extradata_size);
-avio_write(pb, par->extradata, par->extradata_size);
-} else if (par->codec_id == AV_CODEC_ID_MP3)
-avio_write(pb, ".mp3", 4);
-else if (par->codec_id == AV_CODEC_ID_AC3)
-avio_write(pb, "ac-3", 4);
-else if (par->codec_id == AV_CODEC_ID_EAC3)
-avio_write(pb, "ec-3", 4);
+}
} else if (par->codec_id == AV_CODEC_ID_AAC) {
avio_w8(pb, get_audio_flags(s, par));
avio_w8(pb, 0); // AAC sequence header
@@ -743,14 +767,7 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
FLV_FRAME_KEY);
}
-if (par->codec_id == AV_CODEC_ID_H264)
-avio_write(pb, "avc1", 4);
-else if (par->codec_id == AV_CODEC_ID_HEVC)
-avio_write(pb, "hvc1", 4);
-else if (par->codec_id == AV_CODEC_ID_AV1)
-avio_write(pb, "av01", 4);
-else if (par->codec_id == AV_CODEC_ID_VP9)
-avio_write(pb, "vp09", 4);
+write_codec_fourcc(pb, par->codec_id);
if (track_idx)
avio_w8(pb, track_idx);
@@ -1240,14 +1257,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
[FFmpeg-devel] [PATCH 07/13] avformat/flvenc: write enhanced rtmp multichannel info for audio with more than two channels
---
libavformat/flvenc.c | 93
1 file changed, 85 insertions(+), 8 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 94d633fbca..056940afc5 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -711,10 +711,82 @@ static void flv_write_aac_header(AVFormatContext* s,
AVCodecParameters* par)
avio_write(pb, par->extradata, par->extradata_size);
}
+static void flv_write_multichannel_body(AVFormatContext* s, AVCodecParameters*
par)
+{
+AVIOContext *pb = s->pb;
+
+switch (par->ch_layout.order) {
+case AV_CHANNEL_ORDER_NATIVE:
+avio_w8(pb, AudioChannelOrderNative);
+break;
+case AV_CHANNEL_ORDER_CUSTOM:
+avio_w8(pb, AudioChannelOrderCustom);
+break;
+default:
+avio_w8(pb, AudioChannelOrderUnspecified);
+break;
+}
+
+avio_w8(pb, par->ch_layout.nb_channels);
+
+if (par->ch_layout.order == AV_CHANNEL_ORDER_NATIVE) {
+// The first 18 entries are identical between FFmpeg and flv
+uint32_t mask = par->ch_layout.u.mask & 0x03;
+// The remaining 6 flv entries are in the right order, but start at
AV_CHAN_LOW_FREQUENCY_2
+mask |= (par->ch_layout.u.mask >> (AV_CHAN_LOW_FREQUENCY_2 - 18)) &
0xFC;
+
+avio_wb32(pb, mask);
+} else if (par->ch_layout.order == AV_CHANNEL_ORDER_CUSTOM) {
+for (int i = 0; i < par->ch_layout.nb_channels; i++) {
+enum AVChannel id = par->ch_layout.u.map[i].id;
+if (id >= AV_CHAN_FRONT_LEFT && id <= AV_CHAN_TOP_BACK_RIGHT) {
+avio_w8(pb, id - AV_CHAN_FRONT_LEFT + 0);
+} else if (id >= AV_CHAN_LOW_FREQUENCY_2 && id <=
AV_CHAN_BOTTOM_FRONT_RIGHT) {
+avio_w8(pb, id - AV_CHAN_LOW_FREQUENCY_2 + 18);
+} else if (id == AV_CHAN_UNUSED) {
+avio_w8(pb, 0xFE);
+} else {
+avio_w8(pb, 0xFF); // unknown
+}
+}
+}
+}
+
+static int flv_get_multichannel_body_size(AVCodecParameters* par)
+{
+int res = 2;
+
+if (par->ch_layout.order == AV_CHANNEL_ORDER_NATIVE)
+res += 4;
+else if (par->ch_layout.order == AV_CHANNEL_ORDER_CUSTOM)
+res += par->ch_layout.nb_channels;
+
+return res;
+}
+
+static void flv_write_multichannel_header(AVFormatContext* s,
AVCodecParameters* par, int64_t ts)
+{
+AVIOContext *pb = s->pb;
+int data_size = flv_get_multichannel_body_size(par);
+
+avio_w8(pb, FLV_TAG_TYPE_AUDIO);
+avio_wb24(pb, data_size + 5); // size
+put_timestamp(pb, ts);
+avio_wb24(pb, 0); // streamid
+
+avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultichannelConfig);
+write_codec_fourcc(pb, par->codec_id);
+
+flv_write_multichannel_body(s, par);
+
+avio_wb32(pb, data_size + 5 + 11); // previous tag size
+}
+
static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par,
int64_t ts, int stream_index) {
int64_t data_size;
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
+int extended_flv = 0;
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
AV_CODEC_ID_HEVC
@@ -730,10 +802,10 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
avio_wb24(pb, 0); // streamid
pos = avio_tell(pb);
if (par->codec_type == AVMEDIA_TYPE_AUDIO) {
-int extended_flv = par->codec_id == AV_CODEC_ID_OPUS
-|| par->codec_id == AV_CODEC_ID_FLAC
-|| par->codec_id == AV_CODEC_ID_AC3
-|| par->codec_id == AV_CODEC_ID_EAC3;
+extended_flv = par->codec_id == AV_CODEC_ID_OPUS
+|| par->codec_id == AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3
+|| par->codec_id == AV_CODEC_ID_EAC3;
if (extended_flv) {
avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
@@ -754,10 +826,10 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
} else {
int track_idx = flv->video_track_idx_map[stream_index];
// If video stream has track_idx > 0 we need to send H.264 as
extended video packet
-int extended_flv = (par->codec_id == AV_CODEC_ID_H264 && track_idx)
-|| par->codec_id == AV_CODEC_ID_HEVC
-|| par->codec_id == AV_CODEC_ID_AV1
-|| par->codec_id == AV_CODEC_ID_VP9;
+extended_flv = (par->codec_id == AV_CODEC_ID_H264 && track_idx)
+|| par->codec_id == AV_CODEC_ID_HEVC
+|| par->codec_id == AV_CODEC_ID
[FFmpeg-devel] [PATCH 08/13] avformat/flvdec: parse enhanced rtmp multichannel info
---
libavformat/flvdec.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index ee2a1931b2..890958351a 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1335,8 +1335,6 @@ retry:
enhanced_flv = 1;
pkt_type = flags & ~FLV_AUDIO_CODECID_MASK;
-channels = 0;
-
if (pkt_type == AudioPacketTypeMultitrack) {
av_log(s, AV_LOG_ERROR, "Multitrack audio is unsupported!\n");
return AVERROR_PATCHWELCOME;
@@ -1546,12 +1544,9 @@ retry_duration:
avcodec_parameters_free(&par);
}
} else if (stream_type == FLV_STREAM_TYPE_AUDIO) {
-if (!st->codecpar->codec_id) {
+if (!st->codecpar->codec_id)
flv_set_audio_codec(s, st, st->codecpar,
codec_id ? codec_id : (flags &
FLV_AUDIO_CODECID_MASK));
-flv->last_sample_rate = 0;
-flv->last_channels = 0;
-}
// These are not signalled in the flags anymore
channels = 0;
@@ -1562,26 +1557,40 @@ retry_duration:
channels = avio_r8(s->pb);
size -= 2;
+av_channel_layout_uninit(&st->codecpar->ch_layout);
+
if (channel_order == AudioChannelOrderCustom) {
+ret = av_channel_layout_custom_init(&st->codecpar->ch_layout,
channels);
+if (ret < 0)
+return ret;
+
for (i = 0; i < channels; i++) {
-avio_r8(s->pb); // audio channel mapping
+uint8_t id = avio_r8(s->pb);
size--;
+
+if (id < 18)
+st->codecpar->ch_layout.u.map[i].id = id;
+else if (id >= 18 && id <= 23)
+st->codecpar->ch_layout.u.map[i].id = id - 18 +
AV_CHAN_LOW_FREQUENCY_2;
+else if (id == 0xFE)
+st->codecpar->ch_layout.u.map[i].id = AV_CHAN_UNUSED;
+else
+st->codecpar->ch_layout.u.map[i].id = AV_CHAN_UNKNOWN;
}
} else if (channel_order == AudioChannelOrderNative) {
-avio_rb32(s->pb); // audio channel flags
+uint64_t mask = avio_rb32(s->pb);
size -= 4;
-}
-if (!av_channel_layout_check(&st->codecpar->ch_layout)) {
-///TODO: This can be much more sophisticated with above info.
+// The first 18 entries in the mask match ours, but the
remaining 6 entries start at AV_CHAN_LOW_FREQUENCY_2
+mask = (mask & 0x3) | ((mask & 0xFC) <<
(AV_CHAN_LOW_FREQUENCY_2 - 18));
+ret = av_channel_layout_from_mask(&st->codecpar->ch_layout,
mask);
+if (ret < 0)
+return ret;
+} else {
av_channel_layout_default(&st->codecpar->ch_layout, channels);
-flv->last_channels = channels;
}
-if (channels != flv->last_channels) {
-flv->last_channels = channels;
-ff_add_param_change(pkt, channels, 0, 0, 0, 0);
-}
+av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel
info.\n");
goto leave;
}
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 09/13] avformat/flvenc: add support for writing multi track audio
---
libavformat/flvenc.c | 90 +---
1 file changed, 67 insertions(+), 23 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 056940afc5..ab729702a5 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -131,7 +131,7 @@ typedef struct FLVContext {
int flags;
int64_t *last_ts;
int *metadata_pkt_written;
-int *video_track_idx_map;
+int *track_idx_map;
} FLVContext;
static int get_audio_flags(AVFormatContext *s, AVCodecParameters *par)
@@ -764,19 +764,33 @@ static int
flv_get_multichannel_body_size(AVCodecParameters* par)
return res;
}
-static void flv_write_multichannel_header(AVFormatContext* s,
AVCodecParameters* par, int64_t ts)
+static void flv_write_multichannel_header(AVFormatContext* s,
AVCodecParameters* par, int64_t ts, int stream_index)
{
AVIOContext *pb = s->pb;
+FLVContext *flv = s->priv_data;
+
+int track_idx = flv->track_idx_map[stream_index];
int data_size = flv_get_multichannel_body_size(par);
+if (track_idx)
+data_size += 2;
avio_w8(pb, FLV_TAG_TYPE_AUDIO);
avio_wb24(pb, data_size + 5); // size
put_timestamp(pb, ts);
avio_wb24(pb, 0); // streamid
-avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultichannelConfig);
+if (track_idx) {
+avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultitrack);
+avio_w8(pb, MultitrackTypeOneTrack |
AudioPacketTypeMultichannelConfig);
+} else {
+avio_w8(pb, FLV_CODECID_EX_HEADER | AudioPacketTypeMultichannelConfig);
+}
+
write_codec_fourcc(pb, par->codec_id);
+if (track_idx)
+avio_w8(pb, track_idx);
+
flv_write_multichannel_body(s, par);
avio_wb32(pb, data_size + 5 + 11); // previous tag size
@@ -786,6 +800,7 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
int64_t data_size;
AVIOContext *pb = s->pb;
FLVContext *flv = s->priv_data;
+int track_idx = flv->track_idx_map[stream_index];
int extended_flv = 0;
if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
@@ -802,15 +817,26 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
avio_wb24(pb, 0); // streamid
pos = avio_tell(pb);
if (par->codec_type == AVMEDIA_TYPE_AUDIO) {
-extended_flv = par->codec_id == AV_CODEC_ID_OPUS
-|| par->codec_id == AV_CODEC_ID_FLAC
-|| par->codec_id == AV_CODEC_ID_AC3
-|| par->codec_id == AV_CODEC_ID_EAC3;
+extended_flv = (par->codec_id == AV_CODEC_ID_AAC && track_idx)
+|| (par->codec_id == AV_CODEC_ID_MP3 &&
track_idx)
+|| par->codec_id == AV_CODEC_ID_OPUS
+|| par->codec_id == AV_CODEC_ID_FLAC
+|| par->codec_id == AV_CODEC_ID_AC3
+|| par->codec_id == AV_CODEC_ID_EAC3;
if (extended_flv) {
-avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
+if (track_idx) {
+avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeMultitrack);
+avio_w8(pb, MultitrackTypeOneTrack |
AudioPacketTypeSequenceStart);
+} else {
+avio_w8(pb, FLV_CODECID_EX_HEADER |
AudioPacketTypeSequenceStart);
+}
+
write_codec_fourcc(pb, par->codec_id);
+if (track_idx)
+avio_w8(pb, track_idx);
+
if (par->codec_id == AV_CODEC_ID_AAC) {
flv_write_aac_header(s, par);
} else if (par->codec_id == AV_CODEC_ID_OPUS || par->codec_id
== AV_CODEC_ID_FLAC) {
@@ -824,7 +850,6 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
flv_write_aac_header(s, par);
}
} else {
-int track_idx = flv->video_track_idx_map[stream_index];
// If video stream has track_idx > 0 we need to send H.264 as
extended video packet
extended_flv = (par->codec_id == AV_CODEC_ID_H264 && track_idx)
|| par->codec_id == AV_CODEC_ID_HEVC
@@ -868,7 +893,7 @@ static void flv_write_codec_header(AVFormatContext* s,
AVCodecParameters* par, i
if (par->codec_type == AVMEDIA_TYPE_AUDIO && (extended_flv ||
(av_channel_layout_compare(&par->ch_layout,
&(AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO) == 1 &&
av_channel_layout_compare(&par->ch_layout,
&(AVChannelLayout)AV_CHANNEL_LAYOUT_MONO) == 1)))
-flv_write_multichannel_header(s, par, ts);
+flv_write_multichannel_header(s, par, ts, stream_index);
}
static int flv_append_keyframe_info(AVFormatContext *s, FLV
[FFmpeg-devel] [PATCH 10/13] avformat/flvdec: add support for reading multi track audio
---
libavformat/flvdec.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 890958351a..5877828c52 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1336,12 +1336,26 @@ retry:
pkt_type = flags & ~FLV_AUDIO_CODECID_MASK;
if (pkt_type == AudioPacketTypeMultitrack) {
-av_log(s, AV_LOG_ERROR, "Multitrack audio is unsupported!\n");
-return AVERROR_PATCHWELCOME;
+uint8_t types = avio_r8(s->pb);
+int multitrack_type = types >> 4;
+pkt_type = types & 0xF;
+
+if (multitrack_type != MultitrackTypeOneTrack) {
+av_log(s, AV_LOG_ERROR, "Audio multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
+return AVERROR_PATCHWELCOME;
+}
+
+multitrack = 1;
+size--;
}
codec_id = avio_rb32(s->pb);
size -= 4;
+
+if (multitrack) {
+track_idx = avio_r8(s->pb);
+size--;
+}
}
} else if (type == FLV_TAG_TYPE_VIDEO) {
stream_type = FLV_STREAM_TYPE_VIDEO;
@@ -1438,7 +1452,8 @@ skip:
st = s->streams[i];
if (stream_type == FLV_STREAM_TYPE_AUDIO) {
if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
-(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)))
+(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
+st->id == track_idx)
break;
} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/13] avformat/flvenc: Implement support for multi-track video
On 21.05.2024 20:48, Dennis Sädtler wrote: From: Dennis Sädtler via ffmpeg-devel I wonder what happened here, did I make a mistake when submitting the original patch to the ML so the actual commit author name/email got lost? That's just what happens if your mailserver has strict SPF/DMARC configured. Since no other server can send mails from its domain then, Mailing-Lists are forced to mangle it. Should be the same as the signed-off section based on the repo I submitted it from: https://github.com/derrod/ffmpeg/commit/25f1700cffa00fcd04bcc27efce077a93e7f5142 I'll fix it locally, hadn't noticed that yet. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 13/13] avformat/flvdec: support all multi-track modes
On 22.05.2024 02:02, Michael Niedermayer wrote: On Tue, May 21, 2024 at 11:02:22AM +0200, Timo Rothenpieler wrote: --- libavformat/flvdec.c | 570 +++ 1 file changed, 306 insertions(+), 264 deletions(-) infinite loops [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) [flv @ 0x555e803d2940] Video codec (0) is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [flv @ 0x555e803d2940] If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact
[FFmpeg-devel] [PATCH v2 13/13] avformat/flvdec: support all multi-track modes
---
libavformat/flvdec.c | 574 +++
1 file changed, 311 insertions(+), 263 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4f98ff348c..fe5a44a715 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1273,6 +1273,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
{
FLVContext *flv = s->priv_data;
int ret, i, size, flags;
+int res = 0;
enum FlvTagType type;
int stream_type=-1;
int64_t next, pos, meta_pos;
@@ -1287,6 +1288,7 @@ static int flv_read_packet(AVFormatContext *s, AVPacket
*pkt)
int pkt_type = 0;
uint8_t track_idx = 0;
uint32_t codec_id = 0;
+int multitrack_type = MultitrackTypeOneTrack;
retry:
/* pkt size is repeated at end. skip it */
@@ -1337,14 +1339,9 @@ retry:
if (pkt_type == AudioPacketTypeMultitrack) {
uint8_t types = avio_r8(s->pb);
-int multitrack_type = types >> 4;
+multitrack_type = types & 0xF0;
pkt_type = types & 0xF;
-if (multitrack_type != MultitrackTypeOneTrack) {
-av_log(s, AV_LOG_ERROR, "Audio multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
-return AVERROR_PATCHWELCOME;
-}
-
multitrack = 1;
size--;
}
@@ -1371,14 +1368,9 @@ retry:
if (pkt_type == PacketTypeMultitrack) {
uint8_t types = avio_r8(s->pb);
-int multitrack_type = types >> 4;
+multitrack_type = types & 0xF0;
pkt_type = types & 0xF;
-if (multitrack_type != MultitrackTypeOneTrack) {
-av_log(s, AV_LOG_ERROR, "Multitrack types other than
MultitrackTypeOneTrack are unsupported!\n");
-return AVERROR_PATCHWELCOME;
-}
-
multitrack = 1;
size--;
}
@@ -1447,293 +1439,349 @@ skip:
goto leave;
}
-/* now find stream */
-for (i = 0; i < s->nb_streams; i++) {
-st = s->streams[i];
-if (stream_type == FLV_STREAM_TYPE_AUDIO) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
-(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
-st->id == track_idx)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
-(s->video_codec_id || flv_same_video_codec(st->codecpar,
codec_id)) &&
-st->id == track_idx)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
-break;
-} else if (stream_type == FLV_STREAM_TYPE_DATA) {
-if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
-break;
+for (;;) {
+int track_size = size;
+
+if (multitrack_type != MultitrackTypeOneTrack) {
+track_size = avio_rb24(s->pb);
+size -= 3;
}
-}
-if (i == s->nb_streams) {
-static const enum AVMediaType stream_types[] = {AVMEDIA_TYPE_VIDEO,
AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE, AVMEDIA_TYPE_DATA};
-st = create_stream(s, stream_types[stream_type], track_idx);
-if (!st)
-return AVERROR(ENOMEM);
-}
-av_log(s, AV_LOG_TRACE, "%d %X %d \n", stream_type, flags, st->discard);
-if (flv->time_pos <= pos) {
-dts += flv->time_offset;
-}
+/* now find stream */
+for (i = 0; i < s->nb_streams; i++) {
+st = s->streams[i];
+if (stream_type == FLV_STREAM_TYPE_AUDIO) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
+(s->audio_codec_id || flv_same_audio_codec(st->codecpar,
flags, codec_id)) &&
+st->id == track_idx)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
+(s->video_codec_id || flv_same_video_codec(st->codecpar,
codec_id)) &&
+st->id == track_idx)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
+break;
+} else if (stream_type == FLV_STREAM_TYPE_DATA) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA)
+break;
+}
+}
+if (i == s->nb_streams) {
+static const enum AVMediaType stream_types[] =
{AVMEDIA_TYPE_VIDEO, AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_SUBTITLE,
AVMEDIA_TYPE_DATA};
+st = create_stream(s, stream_types[stream_type], track_idx);
+if (!st)
+
Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for FreeBSD
On 26.05.2024 07:22, Brad Smith wrote: On 2024-05-19 7:24 a.m., Timo Rothenpieler wrote: On 19.05.2024 02:00, Brad Smith wrote: configure: enable ffnvcodec, nvenc, nvdec for FreeBSD Signed-off-by: Brad Smith --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index b16722d83d..96b181fd21 100755 --- a/configure +++ b/configure @@ -7350,7 +7350,7 @@ fi if enabled x86; then case $target_os in - mingw32*|mingw64*|win32|win64|linux|cygwin*) + freebsd|mingw32*|mingw64*|win32|win64|linux|cygwin*) Does this actually work? Everything I find online indicates that the FreeBSD driver is lacking support for CUDA, nvenc and most of anything compute related. According to the commits and bug report requesting support it does appear to work. The CUDA bits are not native. They're using Linux emulation for that. The display driver is native. If it actually is confirmed to work, this change LGTM. I have no way to test or verify that though. ___ 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/nvenc_av1: Correct CQ range for AV1
applied, thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 00/13] flvdec/flvenc: add support for enhanced rtmp codecs and multitrack/multichannel
On 28.05.2024 17:14, Andrew Sayers wrote: On Tue, May 21, 2024 at 11:02:09AM +0200, Timo Rothenpieler wrote: This is based on the preliminary spec for enhanced rtmp v2: https://veovera.org/docs/enhanced/enhanced-rtmp-v2 The spec is not final, and can still undergo breaking changes, hence this set is purely for comments and review, and not ready to be merged until the final v2 spec is published. There are no samples out in the wild yet, so testing interoperability with other software has not happened yet either. Specially the two other multitrack modes, where multiple tracks are in the same packet, have not been tested at all, since no software can write such files. The set can also be found on GitHub, where ignoring whitespaces makes specially the last patch a lot more readable: https://github.com/BtbN/FFmpeg/tree/enhanced-flv I ran this against a little review bot I'm working on. Please do s/\* / \*/g on the following: The usage of that is already inconsistent throughout the flv codebase, so running that would make the patch touch a lot of unrelated things. Seems more sane to just do a general style-cleanup after the fact. ___ 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] movenc: Add an option for hiding fragments at the end
On 31/05/2024 10:53, Martin Storsjö wrote: This allows ending up with a normal, non-fragmented file when the file is finished, while keeping the file readable if writing is aborted abruptly at any point. (Normally when writing a mov/mp4 file, the unfinished file is completely useless unless it is finished properly.) This results in a file where the mdat atom contains (and hides) all the moof atoms that were part of the fragmented file structure initially. --- This is, incidentally, how Apple devices do (or at least did, at some point) their writing of files when recording, at least with some of their userspace APIs. --- doc/muxers.texi | 7 + libavformat/movenc.c | 59 --- libavformat/movenc.h | 4 ++- libavformat/version.h | 4 +-- tests/fate/lavf-container.mak | 3 +- tests/ref/lavf/mov_hide_frag | 3 ++ 6 files changed, 71 insertions(+), 9 deletions(-) create mode 100644 tests/ref/lavf/mov_hide_frag diff --git a/doc/muxers.texi b/doc/muxers.texi index 6340c8e54d..e313b5e631 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -569,6 +569,13 @@ experimental, may be renamed or changed, do not use from scripts. @item write_gama write deprecated gama atom + +@item hide_fragments +After writing a fragmented file, convert it to a regular, non-fragmented +file at the end. This keeps the file readable while it is being +written, and makes it recoverable if the process of writing the file +gets aborted uncleanly, while still producing an easily seekable +and widely compatible non-fragmented file in the end. @end table I somehow feel like calling the option like this would not help an "unsuspecting user" to find it, cause it's not immediately obvious that it solves the issue it does. Though I don't immediately have a better idea either. Something like "safe_recording"? "crash_resilience"? Can't say I'm a fan of those either. ___ 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 03/16] avutil: add ioctl definitions for tegra devices
On 31.05.2024 23:06, averne wrote: Le 30/05/2024 à 22:42, Rémi Denis-Courmont a écrit : Le torstaina 30. toukokuuta 2024, 22.43.05 EEST averne a écrit : These files are taken with minimal modifications from nvidia's Linux4Tegra (L4T) tree. nvmap enables management of memory-mapped buffers for hardware devices. nvhost enables interaction with different hardware modules (multimedia engines, display engine, ...), through a common block, host1x. Signed-off-by: averne --- libavutil/Makefile | 2 + libavutil/nvhost_ioctl.h | 511 +++ libavutil/nvmap_ioctl.h | 451 ++ 3 files changed, 964 insertions(+) create mode 100644 libavutil/nvhost_ioctl.h create mode 100644 libavutil/nvmap_ioctl.h diff --git a/libavutil/Makefile b/libavutil/Makefile index 6e6fa8d800..9c112bc58a 100644 --- a/libavutil/Makefile +++ b/libavutil/Makefile @@ -52,6 +52,8 @@ HEADERS = adler32.h \ hwcontext_videotoolbox.h \ hwcontext_vdpau.h \ hwcontext_vulkan.h\ + nvhost_ioctl.h\ + nvmap_ioctl.h \ iamf.h \ imgutils.h \ intfloat.h \ diff --git a/libavutil/nvhost_ioctl.h b/libavutil/nvhost_ioctl.h new file mode 100644 index 00..b0bf3e3ae6 --- /dev/null +++ b/libavutil/nvhost_ioctl.h @@ -0,0 +1,511 @@ +/* + * include/uapi/linux/nvhost_ioctl.h Well, then that should be provided by linux-libc-dev or equivalent. I don't think that this should be vendored into FFmpeg. Agreed. On L4T this is provided by nvidia-l4t-kernel-headers, but on the HOS side there is no such equivalent yet. If this patch series moves forward, I will integrate the relevant bits in libnx and get rid of those headers. As for the hardware definitions (in the following patch), I think they should be put in nv-codec-headers. I disagree there, the nv-codec-headers track the upstream codec SDK. Making it track two independent things would be a mess. This patchset is implementing parts of an entire video-driver into FFmpeg. Which really looks out of scope to me. Can't all that be moved into a library, which then also comes with the necessary headers for applications to use it? On that note, how stable are those headers? Given they're part of the nvidia driver, couldn't they randomly change at any time? ___ 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/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
From: BtbN
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0, NULL, 0,
&c->ctxt_handle,
&outbuf_desc, &c->context_flags,
&c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret == SEC_I_CONTEXT_EXPIRED) {
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t *buf, int len)
}
}
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+} else if (ret == AVERROR(EAGAIN)) {
+ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const uint8_t *buf,
int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer + outbuf[2].cbBuffer;
+
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
-if (ret < 0 || ret != len) {
+if (ret == AVERROR(EAGAIN)) {
+goto done;
+} else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to socket
failed\n");
goto done;
--
2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [WIP] False positives on Coverity
On 08.06.2024 21:49, Vittorio Giovara wrote: On Sat, Jun 8, 2024 at 6:02 PM Michael Niedermayer wrote: On Tue, May 14, 2024 at 01:38:16AM +0200, Michael Niedermayer wrote: Hi all To keep people updated (and as this is not vissible on the ML) heres my current list of issues marked as false positives / intentional in Mai & April 2024 (in case anyone wants to review, i presume noone wants but just in case) updated list as of today: [...] Given the insane amount of them, I'm not a fan of that. It produces more false positives than anything else. It also has its own internal tracker for them, so flooding any kind of other issue tracker with it seems just like point spam to me. ___ 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] [WIP] False positives on Coverity
On 10.06.2024 14:37, Vittorio Giovara wrote: On Mon, Jun 10, 2024 at 12:04 AM Michael Niedermayer wrote: On Sun, Jun 09, 2024 at 03:10:09PM +0200, Vittorio Giovara wrote: On Sun, Jun 9, 2024 at 12:50 AM Timo Rothenpieler On 08.06.2024 21:49, Vittorio Giovara wrote: On Sat, Jun 8, 2024 at 6:02 PM Michael Niedermayer < mich...@niedermayer.cc> wrote: On Tue, May 14, 2024 at 01:38:16AM +0200, Michael Niedermayer wrote: Hi all To keep people updated (and as this is not vissible on the ML) heres my current list of issues marked as false positives / intentional in Mai & April 2024 (in case anyone wants to review, i presume noone wants but just in case) updated list as of today: [...] Given the insane amount of them, I'm not a fan of that. It produces more false positives than anything else. It also has its own internal tracker for them, so flooding any kind of other issue tracker with it seems just like point spam to me. Not everyone has access to it. Also I'd rather have a trackable system than a mail with a list of issues. every FFmpeg developer or maintainer who wants to work on these issues can get access. and And last but not least coverity isnt intended to be public because it can find security issues. are contradictory. In either case, my point is that email is not a good system for these reports, because they cannot be tracked nor analyzed, and if they do pose a security risk they shouldn't be advertised so openly. Having a small bounty with STM funds would probably be a more efficient way at fixing them than asking people to take a look at them on the ML. I'm not sure what you mean. E-Mail is not the primary system for these reports. They're just notifications about new stuff, with a rough summary of each issue, if there aren't too many. The primary way to track and handle them is via their website. ___ 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/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0, NULL, 0,
&c->ctxt_handle,
&outbuf_desc, &c->context_flags,
&c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret == SEC_I_CONTEXT_EXPIRED) {
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t *buf, int len)
}
}
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+} else if (ret == AVERROR(EAGAIN)) {
+ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const uint8_t *buf,
int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer + outbuf[2].cbBuffer;
+
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
-if (ret < 0 || ret != len) {
+if (ret == AVERROR(EAGAIN)) {
+goto done;
+} else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to socket
failed\n");
goto done;
ping
I'm specifically unsure if implementing the sending-side like this is
valid and would appreciate review from someone familiar with the code
and schannel.
___
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] movenc: Add an option for hiding fragments at the end
On 13/06/2024 14:50, Martin Storsjö wrote: On Wed, 5 Jun 2024, Martin Storsjö wrote: This allows ending up with a normal, non-fragmented file when the file is finished, while keeping the file readable if writing is aborted abruptly at any point. (Normally when writing a mov/mp4 file, the unfinished file is completely useless unless it is finished properly.) This results in a file where the mdat atom contains (and hides) all the moof atoms that were part of the fragmented file structure initially. --- v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes no sense without it). Updated the description of the flag to "Write a fragmented file that is converted to non-fragmented at the end". Kept the flag named "hide_fragments", but I'm also pondering if we maybe should go for a name like "hybrid_fragmented" or so, as a better description of _what_ it produces, as opposed to _how_ it does things. (One could also consider "hybrid_mp4", but even if mp4 is the main thing, the same also goes for mov and a bunch of other related formats.) I'd otherwise want to push this, but I'm not entirely satisfied with the option name quite yet. I'm pondering if we should call it "hybrid_fragmented" - any opinions, Dennis or Timo? It's at least in line with what OBS dubbed the same feature, so would allow consistent Search-Results. So it seems like a good compromise to me. ___ 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] movenc: Add an option for hiding fragments at the end
On 14/06/2024 12:44, Martin Storsjö wrote: On Fri, 14 Jun 2024, Gyan Doshi wrote: On 2024-06-14 02:18 am, Martin Storsjö wrote: On Thu, 13 Jun 2024, Gyan Doshi wrote: On 2024-06-13 06:20 pm, Martin Storsjö wrote: I'd otherwise want to push this, but I'm not entirely satisfied with the option name quite yet. I'm pondering if we should call it "hybrid_fragmented" - any opinions, Dennis or Timo? How about `resilient_mode` or `recoverable`? I agree that the how is secondary. Those are good suggestions as well - but I think I prefer "hybrid_fragmented" still. In theory, I guess one could implement resilient writing in a number of different ways, whereas the hybrid fragmented/non-fragmented only is one. So with a couple other voices agreeing with the name "hybrid_fragmented", I'll post a new patch with the option in that form - hopefully you don't object to it. The term hybrid is not applicable here. The fragmented state is transient during writing and contingent in the finished artifact depending on how the writing process concluded. Hybrid implies both modes available e.g.. a hybrid vehicle can use both types of energy sources. The artifact here will be one _or_ the other. Sure, the file itself is either or, but the process of writing will have utilized both. TBH, I don't see it as such a black-or-white thing. What do the others who have chimed in on the thread think, compared to calling it "recoverable" or "resilient_mode"? I don't have a super strong opinion on it, but out of the options provided, I'd prefer the hybrid_ one, since there's a good chance it'll become an established term now that OBS presents it quite publicly visible. ___ 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/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 11.06.2024 15:10, Timo Rothenpieler wrote:
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
This is fixed locally
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0,
NULL, 0, &c->ctxt_handle,
&outbuf_desc,
&c->context_flags, &c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret ==
SEC_I_CONTEXT_EXPIRED) {
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer,
outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t *buf,
int len)
}
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+ } else if (ret == AVERROR(EAGAIN)) {
+ ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const uint8_t
*buf, int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer +
outbuf[2].cbBuffer;
+
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
- if (ret < 0 || ret != len) {
+ if (ret == AVERROR(EAGAIN)) {
+ goto done;
+ } else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to
socket failed\n");
goto done;
ping
I'm specifically unsure if implementing the sending-side like this is
valid and would appreciate review from someone familiar with the code
and schannel.
ping
___
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/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 18.06.2024 18:56, Gyan Doshi wrote: FWIW, I had to do the same for securetransport on a project a couple of years back to get rtmps working. Worked fine, and did not get any reports of ill-effects. You mean the FFmpeg implementation of rtmps? Cause if so, I think that only makes use of nonblocking mode for receiving, not sending. So it wouldn't run into this if it was wrong. Just making the reading side support non-blocking would definitely also be an option, it would at least fix rtmps. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] movenc: Add an option for resilient, hybrid fragmented/non-fragmented muxing
On 20/06/2024 15:46, Martin Storsjö wrote: On Wed, 19 Jun 2024, Martin Storsjö wrote: This allows ending up with a normal, non-fragmented file when the file is finished, while keeping the file readable if writing is aborted abruptly at any point. (Normally when writing a mov/mp4 file, the unfinished file is completely useless unless it is finished properly.) This results in a file where the mdat atom contains (and hides) all the moof atoms that were part of the fragmented file structure initially. --- v3: Renamed the option to hybrid_fragmented. --- doc/muxers.texi | 11 ++ libavformat/movenc.c | 62 +++--- libavformat/movenc.h | 4 ++- libavformat/version.h | 4 +-- tests/fate/lavf-container.mak | 3 +- tests/ref/lavf/mov_hybrid_frag | 3 ++ 6 files changed, 78 insertions(+), 9 deletions(-) create mode 100644 tests/ref/lavf/mov_hybrid_frag If there are no more comments on this one, I'll go ahead and push it soon. +1 from me ___ 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/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0, NULL, 0,
&c->ctxt_handle,
&outbuf_desc, &c->context_flags,
&c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret == SEC_I_CONTEXT_EXPIRED) {
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t *buf, int len)
}
}
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+} else if (ret == AVERROR(EAGAIN)) {
+ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const uint8_t *buf,
int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer + outbuf[2].cbBuffer;
+
+s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
-if (ret < 0 || ret != len) {
+if (ret == AVERROR(EAGAIN)) {
+goto done;
+} else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to socket
failed\n");
goto done;
will apply soon
___
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/tls_schannel: forward AVIO_FLAG_NONBLOCK to tcp stream
On 24/06/2024 00:07, Timo Rothenpieler wrote:
On 03.06.2024 22:28, Timo Rothenpieler wrote:
From: BtbN
Fixes for example rtmps streaming over schannel.
---
libavformat/tls_schannel.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index 214a47a218..7265a9794d 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -113,6 +113,7 @@ static int tls_shutdown_client(URLContext *h)
c->request_flags, 0, 0,
NULL, 0, &c->ctxt_handle,
&outbuf_desc,
&c->context_flags, &c->ctxt_timestamp);
if (sspi_ret == SEC_E_OK || sspi_ret ==
SEC_I_CONTEXT_EXPIRED) {
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer,
outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer)
@@ -316,6 +317,7 @@ static int tls_client_handshake(URLContext *h)
goto fail;
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
ret = ffurl_write(s->tcp, outbuf.pvBuffer, outbuf.cbBuffer);
FreeContextBuffer(outbuf.pvBuffer);
if (ret < 0 || ret != outbuf.cbBuffer) {
@@ -416,11 +418,16 @@ static int tls_read(URLContext *h, uint8_t *buf,
int len)
}
}
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_read(s->tcp, c->enc_buf + c->enc_buf_offset,
c->enc_buf_size - c->enc_buf_offset);
if (ret == AVERROR_EOF) {
c->connection_closed = 1;
ret = 0;
+ } else if (ret == AVERROR(EAGAIN)) {
+ ret = 0;
} else if (ret < 0) {
av_log(h, AV_LOG_ERROR, "Unable to read from socket\n");
return ret;
@@ -564,8 +571,14 @@ static int tls_write(URLContext *h, const uint8_t
*buf, int len)
sspi_ret = EncryptMessage(&c->ctxt_handle, 0, &outbuf_desc, 0);
if (sspi_ret == SEC_E_OK) {
len = outbuf[0].cbBuffer + outbuf[1].cbBuffer +
outbuf[2].cbBuffer;
+
+ s->tcp->flags &= ~AVIO_FLAG_NONBLOCK;
+ s->tcp->flags |= h->flags & AVIO_FLAG_NONBLOCK;
+
ret = ffurl_write(s->tcp, data, len);
- if (ret < 0 || ret != len) {
+ if (ret == AVERROR(EAGAIN)) {
+ goto done;
+ } else if (ret < 0 || ret != len) {
ret = AVERROR(EIO);
av_log(h, AV_LOG_ERROR, "Writing encrypted data to
socket failed\n");
goto done;
will apply soon
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffplay_renderer: use correct NULL value for Vulkan type
--- fftools/ffplay_renderer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fftools/ffplay_renderer.c b/fftools/ffplay_renderer.c index 80b700b3c5..f272cb46f1 100644 --- a/fftools/ffplay_renderer.c +++ b/fftools/ffplay_renderer.c @@ -766,7 +766,7 @@ static void destroy(VkRenderer *renderer) vkDestroySurfaceKHR = (PFN_vkDestroySurfaceKHR) ctx->get_proc_addr(ctx->inst, "vkDestroySurfaceKHR"); vkDestroySurfaceKHR(ctx->inst, ctx->vk_surface, NULL); -ctx->vk_surface = NULL; +ctx->vk_surface = VK_NULL_HANDLE; } av_buffer_unref(&ctx->hw_device_ref); -- 2.44.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Fix segfault with intra-only
On 01.07.2024 18:52, Josh Allmann wrote: On Thu, 20 Jun 2024 at 17:39, Josh Allmann wrote: In intra-only mode, frameIntervalP is 0, which means the frame data array is smaller than the number of surfaces. This causes a crash when closing the encoder. Fix this by making sure the frame data array is at least as big as the number of surfaces. --- libavcodec/nvenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index a9945355ba..93e87b21db 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -1021,7 +1021,7 @@ static av_cold int nvenc_recalc_surfaces(AVCodecContext *avctx) // Output in the worst case will only start when the surface buffer is completely full. // Hence we need to keep at least the max amount of surfaces plus the max reorder delay around. -ctx->frame_data_array_nb = ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1; +ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces, ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1); return 0; } -- 2.39.2 Hello, Ping for review. This patch fixes an easily triggered crash with nvenc in intra-only mode, eg ffmpeg -i -c:v h264_nvenc -g 0 Josh ___ 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". It's the wrong fix for the crash, but definitely a sensible change in itself. Will amend with the actual fix (using the right size when deallocating that array) but keep this change as well, since it makes sense. ___ 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] av_rescale() coverity
On 01.07.2024 15:39, Michael Niedermayer wrote: Hi all coverity seems to have started to do a new thing. Namely if theres a return statement it assumes it can independant of everything occurr an example would be av_rescale() which on overflow returns INT64_MIN also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX through from the input So coverity since a few days seems to treat every av_rescale() call as if it returns INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is reachable or if the flags even include the execution path. An example is this: AVRational time_base_q = AV_TIME_BASE_Q; int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)); ds->next_dts = av_rescale_q(next_dts + 1, av_inv_q(ist->framerate), time_base_q); Here coverity as a initial statement claims next_dts is INT64_MAX and next_dts + 1 would overflow 8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)) returns 9223372036854775807. 9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)), its value is now 9223372036854775807. 331int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)); CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW) 10. overflow_const: Expression next_dts + 1LL, which is equal to -9223372036854775808, where next_dts is known to be equal to 9223372036854775807, overflows the type that receives it, a signed integer 64 bits wide. another example is this: #define AV_TIME_BASE100 pts = av_rescale(ds->dts, 100, AV_TIME_BASE); coverity hallucinates pts as a tainted negative number here nothing says anything about the input ds->dts (and thats what would matter) In the past coverity provided a detailed list of steps on how a case is reached. One could then check these assumtions and mark things as false positive when one assumtion is wrong. (coverity was most of the time wrong) Now coverity just hallucinates claims out of the blue without any explanation how that can happen. Iam a bit at a loss how to deal with this and also why exactly this new behavior appeared. Has anyone changed any setting or anything in coverity ? The number of issues shot up to over 400 on the 22th june "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan." Do you mean May? Cause that's when I enabled also giving a Windows-Build to Coverity: https://github.com/FFmpeg/FFmpeg-Coverity/commit/3116e6960406f01f96d934516216bb3b402122fc Before that, only Linux was analyzed. before this i thought iam mostly done with my coverity work. now truth is, the STF text speaks about 673 issues at the time and not what appears after the work started, but it makes me a bit sad if i categorize ~700+ issues and then fix the ones that are bugs just to find coverity hallucinate 200 new issues a month that ill have to leave open for future efforts. I did not expect that years of ignoring coverity accumulate 673 issues and then suddenly the rate of new issues to shoot up like this. I kind of expected that i can fix all new issues appearing during the work with insignificant extra effort thx ___ 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] avcodec/nvenc: Fix segfault with intra-only
On 01.07.2024 20:05, Dennis Mungai wrote: On Mon, 1 Jul 2024 at 21:01, Timo Rothenpieler wrote: On 01.07.2024 18:52, Josh Allmann wrote: On Thu, 20 Jun 2024 at 17:39, Josh Allmann wrote: In intra-only mode, frameIntervalP is 0, which means the frame data array is smaller than the number of surfaces. This causes a crash when closing the encoder. Fix this by making sure the frame data array is at least as big as the number of surfaces. --- libavcodec/nvenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index a9945355ba..93e87b21db 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -1021,7 +1021,7 @@ static av_cold int nvenc_recalc_surfaces(AVCodecContext *avctx) // Output in the worst case will only start when the surface buffer is completely full. // Hence we need to keep at least the max amount of surfaces plus the max reorder delay around. -ctx->frame_data_array_nb = ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1; +ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces, ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1); return 0; } -- 2.39.2 Hello, Ping for review. This patch fixes an easily triggered crash with nvenc in intra-only mode, eg ffmpeg -i -c:v h264_nvenc -g 0 Josh Can this also be back-ported to FFmpeg 7.x upon merging? Already is, applies to 7.0 and 6.x ___ 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] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase
On 28.09.2021 18:22, Roman Arzumanyan wrote: Hello, This patch makes nvenc copy incoming hwaccel frames instead of ref count increase. It fixes the bug which may happen when on-GPU transcoding is done and encoder is set to use B frames. How to reproduce the bug: ./ffmpeg \ -hwaccel cuda -hwaccel_output_format cuda \ -i input.mkv \ -c:v h264_nvenc -preset p4 -tune hq -bf 3 \ -y output.mkv Expected output: [h264 @ 0x55b14da4b4c0] No decoder surfaces left [h264 @ 0x55b14da682c0] No decoder surfaces left [h264 @ 0x55b14da850c0] No decoder surfaces left [h264 @ 0x55b14daa1ec0] No decoder surfaces left Error while decoding stream #0:0: Invalid data found when processing input [h264 @ 0x55b14da2e6c0] No decoder surfaces left Error while decoding stream #0:0: Invalid data found when processing input Last message repeated 1 times Although fix adds extra CUDA DtoD memcopy, our internal testing results didn't show any noticeable difference in transcoding performance. Hmm, so far my approach to deal with this was to inject a scale_cuda=passthrough=0 into the filter chain, which pretty much does exactly this, but only controllable by the user. But I do agree that this is a bit of a clutch and not all that user friendly. My main concern with this approach is that it will inevitably increase VRAM usage, depending on bframe count and resolution even quite significantly. And it's surprisingly common that users show up that are highly pressed for memory. When bframes were switched on by default, several people showed up who where suddenly running out of VRAM. I do like this approach though, since it will for the average user make using a full hw chain a lot less bothersome. So what I'd propose is: - Add an option to retain the old behaviour of just holding a reference to the input frame no matter what. - Instead of explicitly copying the frame like you do right now, call av_frame_make_writable() on the frame, right after where you right now are replacing av_frame_ref with av_hwframe_transfer_data. That is for one very easy to disable conditionally, and does not require you to guard all the unref calls. Plus, it will only actually copy the frame if needed (i.e. it won't do anything if it comes out of a filterchain and has nothing else holding a ref) Timo smime.p7s Description: S/MIME Cryptographic 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] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase
On 28.09.2021 19:58, Timo Rothenpieler wrote: On 28.09.2021 18:22, Roman Arzumanyan wrote: Hello, This patch makes nvenc copy incoming hwaccel frames instead of ref count increase. It fixes the bug which may happen when on-GPU transcoding is done and encoder is set to use B frames. How to reproduce the bug: ./ffmpeg \ -hwaccel cuda -hwaccel_output_format cuda \ -i input.mkv \ -c:v h264_nvenc -preset p4 -tune hq -bf 3 \ -y output.mkv Expected output: [h264 @ 0x55b14da4b4c0] No decoder surfaces left [h264 @ 0x55b14da682c0] No decoder surfaces left [h264 @ 0x55b14da850c0] No decoder surfaces left [h264 @ 0x55b14daa1ec0] No decoder surfaces left Error while decoding stream #0:0: Invalid data found when processing input [h264 @ 0x55b14da2e6c0] No decoder surfaces left Error while decoding stream #0:0: Invalid data found when processing input Last message repeated 1 times Although fix adds extra CUDA DtoD memcopy, our internal testing results didn't show any noticeable difference in transcoding performance. Something else I just realized: The nvenc_frame->in_ref you are copying to is never actually used anywhere. It is purely held as a reference, so the frame is not freed before nvenc is done with it. So effectively what your patch is doing right now is making a copy of the frame, but then never do anything with that copy. nvEncRegisterResource() is still called on the original frame, and that registered resource is then used for nvenc. I'm surprised that actually works? Is that okay to do, and then let nvdec continue on? smime.p7s Description: S/MIME Cryptographic 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] libavcodec/nvenc.c: copy incoming hwaccel frames instead of ref count increase
On 28.09.2021 19:58, Timo Rothenpieler wrote:
Hmm, so far my approach to deal with this was to inject a
scale_cuda=passthrough=0 into the filter chain, which pretty much does
exactly this, but only controllable by the user.
But I do agree that this is a bit of a clutch and not all that user
friendly.
My main concern with this approach is that it will inevitably increase
VRAM usage, depending on bframe count and resolution even quite
significantly.
And it's surprisingly common that users show up that are highly pressed
for memory. When bframes were switched on by default, several people
showed up who where suddenly running out of VRAM.
I do like this approach though, since it will for the average user make
using a full hw chain a lot less bothersome.
So what I'd propose is:
- Add an option to retain the old behaviour of just holding a reference
to the input frame no matter what.
- Instead of explicitly copying the frame like you do right now, call
av_frame_make_writable() on the frame, right after where you right now
are replacing av_frame_ref with av_hwframe_transfer_data.
That is for one very easy to disable conditionally, and does not require
you to guard all the unref calls.
Plus, it will only actually copy the frame if needed (i.e. it won't do
anything if it comes out of a filterchain and has nothing else holding a
ref)
Timo
See attached patch for that approach.
I just encoded a 5 minute sample using it, and I do see a marginal
decrease in performance (it drops by literally x0.01 speed, so pretty
much within margin of error, but it did show that consistently) and
increase in VRAM usage as expected.
However, given that your patch does seem to work just fine, somehow, it
would be interesting to know if re-using a frame/CUDA buffer after
registering it with nvenc is safe?
Given that the logic right now never unregisters buffers unless it runs
out of free slots, it would seem weird to me if that was the case. What
if a buffer actually does get re-used, as is common with
non-nvdec-frames allocated from a hwframes ctx?From e8e099dac72b1962aba7c8a4ba87f4035eb0a29d Mon Sep 17 00:00:00 2001
From: Timo Rothenpieler
Date: Tue, 28 Sep 2021 20:45:26 +0200
Subject: [PATCH] avcodec/nvenc: copy incoming hwframes when applicable
---
libavcodec/nvenc.c | 21 +++--
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_h264.c | 2 ++
libavcodec/nvenc_hevc.c | 2 ++
4 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index edc46ed33a..e3cd67fbc1 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1910,20 +1910,29 @@ static int nvenc_upload_frame(AVCodecContext *avctx,
const AVFrame *frame,
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
NV_ENCODE_API_FUNCTION_LIST *p_nvenc = &dl_fn->nvenc_funcs;
-int res;
+int res, reg_idx;
NVENCSTATUS nv_status;
if (avctx->pix_fmt == AV_PIX_FMT_CUDA || avctx->pix_fmt ==
AV_PIX_FMT_D3D11) {
-int reg_idx = nvenc_register_frame(avctx, frame);
+res = av_frame_ref(nvenc_frame->in_ref, frame);
+if (res < 0)
+return res;
+
+if (avctx->pix_fmt == AV_PIX_FMT_CUDA && !ctx->lowmem) {
+res = av_frame_make_writable(nvenc_frame->in_ref);
+if (res < 0) {
+av_frame_unref(nvenc_frame->in_ref);
+return res;
+}
+}
+
+reg_idx = nvenc_register_frame(avctx, nvenc_frame->in_ref);
if (reg_idx < 0) {
av_log(avctx, AV_LOG_ERROR, "Could not register an input HW
frame\n");
+av_frame_unref(nvenc_frame->in_ref);
return reg_idx;
}
-res = av_frame_ref(nvenc_frame->in_ref, frame);
-if (res < 0)
-return res;
-
if (!ctx->registered_frames[reg_idx].mapped) {
ctx->registered_frames[reg_idx].in_map.version =
NV_ENC_MAP_INPUT_RESOURCE_VER;
ctx->registered_frames[reg_idx].in_map.registeredResource =
ctx->registered_frames[reg_idx].regptr;
diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
index 08531e1be3..927f7aa8f3 100644
--- a/libavcodec/nvenc.h
+++ b/libavcodec/nvenc.h
@@ -235,6 +235,7 @@ typedef struct NvencContext
int intra_refresh;
int single_slice_intra_refresh;
int constrained_encoding;
+int lowmem;
} NvencContext;
int ff_nvenc_encode_init(AVCodecContext *avctx);
diff --git a/libavcodec/nvenc_h264.c b/libavcodec/nvenc_h264.c
index 7d78aa0d87..c96a26902a 100644
--- a/libavcodec/nvenc_h264.c
+++ b/libavcodec/nvenc_h264.c
@@ -194,6 +194,8 @@ static const AVOption options[] = {
OFFSET(single_slice_intra_refresh), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
{ "constrained-encoding"
Re: [FFmpeg-devel] [PATCH] avfilter: add scale2ref_npp video filter
On 13.09.2021 11:07, Roman Arzumanyan wrote: This patch adds scale2ref_npp video filter which is similar to scale2ref, but accelerated by NPP. CLI sample: ./ffmpeg \ -hwaccel cuda -hwaccel_output_format cuda \ -i ./bbb_sunflower_1080p_30fps_normal.mp4 \ -i ./920px-Wilber-huge-alpha.png \ -filter_complex "[0:v]scale_npp=format=yuv420p[v0];[1:v]hwupload_cuda[v1];[v1][v0]scale2ref_npp=w=oh*mdar:h=ih/4[foreg][backg];[backg][foreg]overlay_cuda=x=(main_w-overlay_w),scale_npp=w=1280:720[out]" \ -map "[out]" -c:v h264_nvenc -y ./output_overlay.mp4 Some nits first: Please configure your editor to get rid of trailing white spaces. The commit message of the actual patch does not follow the usual schema, even though the subject of the mail does. Missing a libavfilter minor version bump. Missing docs. Can just be a simple docstring header referring to software scale2ref and normal scale_npp for identical options. configure bits are missing. Just a second line otherwise identical to the scale_npp_filter_deps one. Then, why is there a bunch of swscale stuff in the filter, which is then never used? I'd guess those are leftovers from software scale2ref? For example the swscale.h include, and calls to sws_freeContext in nppscale_uninit, and likewise the variables they refer to, of type SwsContext. They don't seem to be used anywhere. The interlaced variable also seems to be never actually used, outside of logging it once. Generally, the filter logic looks sound to me, which isn't surprising, given it's the same logic software-scale2ref uses, just some missing cleanup. Would also love to see the same done to scale_cuda. On that subject: I do wonder if there is some better way to implement the pretty much identical logic in multiple filters. Duplicating all that code is rather ugly and creates quite some maintenance burden if it gets enhanced/fixed in one of the filters but not the others. smime.p7s Description: S/MIME Cryptographic 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] avfilter: add sharpen_npp video filter
From 0df6297bd3664beb05c813c5fc62852e61616fa9 Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Mon, 6 Sep 2021 14:26:27 +0300
Subject: [PATCH] sharpen_npp video filter added
Same as the other patch, should be as the mail subject.
---
configure| 5 +-
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_sharpen_npp.c | 530 +++
Missing entry in filter docs.
Missing avfilter minor version bump.
4 files changed, 535 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/vf_sharpen_npp.c
diff --git a/configure b/configure
index af410a9d11..e092cc8c67 100755
--- a/configure
+++ b/configure
@@ -3094,6 +3094,7 @@ thumbnail_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
transpose_npp_filter_deps="ffnvcodec libnpp"
overlay_cuda_filter_deps="ffnvcodec"
overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
+sharpen_npp_filter_deps="ffnvcodec libnpp"
amf_deps_any="libdl LoadLibrary"
nvenc_deps="ffnvcodec"
@@ -6443,8 +6444,8 @@ enabled libmodplug&& require_pkg_config
libmodplug libmodplug libmodplug
enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h
lame_set_VBR_quality -lmp3lame $libm_extralibs
enabled libmysofa && { check_pkg_config libmysofa libmysofa mysofa.h
mysofa_neighborhood_init_withstepdefine ||
require libmysofa mysofa.h
mysofa_neighborhood_init_withstepdefine -lmysofa $zlib_extralibs; }
-enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig
-lnppicc -lnppc -lnppidei ||
- check_lib libnpp npp.h nppGetLibVersion -lnppi
-lnppc -lnppidei ||
+enabled libnpp&& { check_lib libnpp npp.h nppGetLibVersion -lnppig
-lnppicc -lnppc -lnppidei -lnppif ||
+ check_lib libnpp npp.h nppGetLibVersion -lnppi
-lnppif -lnppc -lnppidei ||
die "ERROR: libnpp not found"; }
Was wondering if it's worth it to split the new dep out into a separate
check, but it's probably not and just fine to pull along, even if
sharpen_npp were to be disabled.
enabled libopencore_amrnb && require libopencore_amrnb
opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
enabled libopencore_amrwb && require libopencore_amrwb opencore-amrwb/dec_if.h
D_IF_init -lopencore-amrwb
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index af957a5ac0..330ddfe5d5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -423,6 +423,7 @@ OBJS-$(CONFIG_SETRANGE_FILTER) +=
vf_setparams.o
OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
OBJS-$(CONFIG_SETTB_FILTER) += settb.o
OBJS-$(CONFIG_SHARPNESS_VAAPI_FILTER)+= vf_misc_vaapi.o vaapi_vpp.o
+OBJS-$(CONFIG_SHARPEN_NPP_FILTER)+= vf_sharpen_npp.o
Should be above SHARPNESS_VAAPI if strictly following alphabetic ordering.
OBJS-$(CONFIG_SHEAR_FILTER) += vf_shear.o
OBJS-$(CONFIG_SHOWINFO_FILTER) += vf_showinfo.o
OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0c6b2347c8..e50e5f3b6a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -404,6 +404,7 @@ extern const AVFilter ff_vf_setrange;
extern const AVFilter ff_vf_setsar;
extern const AVFilter ff_vf_settb;
extern const AVFilter ff_vf_sharpness_vaapi;
+extern const AVFilter ff_vf_sharpen_npp;
Same here about the order.
extern const AVFilter ff_vf_shear;
extern const AVFilter ff_vf_showinfo;
extern const AVFilter ff_vf_showpalette;
diff --git a/libavfilter/vf_sharpen_npp.c b/libavfilter/vf_sharpen_npp.c
new file mode 100644
index 00..85549c36d0
--- /dev/null
+++ b/libavfilter/vf_sharpen_npp.c
@@ -0,0 +1,530 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * NPP sharpen video filter
+ */
+
+#include
+#include
+#include
+#include
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/internal.h"
+#include "lib
[FFmpeg-devel] [RFC] ffmpeg: default to single thread when hwaccel is active
---
fftools/ffmpeg.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
Not sure if there is any downside to this.
Threading for hwaccel does not make a whole lot of sense, and at least
in case of nvdec wastes a lot of VRAM for no performance gain, and
specially on high core count systems by default can even exhaust the
maximum frame pool size.
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 98c2421938..d007d55173 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2995,12 +2995,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
* audio, and video decoders such as cuvid or mediacodec */
ist->dec_ctx->pkt_timebase = ist->st->time_base;
-if (!av_dict_get(ist->decoder_opts, "threads", NULL, 0))
-av_dict_set(&ist->decoder_opts, "threads", "auto", 0);
-/* Attached pics are sparse, therefore we would not want to delay
their decoding till EOF. */
-if (ist->st->disposition & AV_DISPOSITION_ATTACHED_PIC)
-av_dict_set(&ist->decoder_opts, "threads", "1", 0);
-
ret = hw_device_setup_for_decode(ist);
if (ret < 0) {
snprintf(error, error_len, "Device setup failed for "
@@ -3009,6 +3003,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
return ret;
}
+if (!av_dict_get(ist->decoder_opts, "threads", NULL, 0)) {
+if (ist->dec_ctx->hw_device_ctx)
+av_dict_set(&ist->decoder_opts, "threads", "1", 0);
+else
+av_dict_set(&ist->decoder_opts, "threads", "auto", 0);
+}
+/* Attached pics are sparse, therefore we would not want to delay
their decoding till EOF. */
+if (ist->st->disposition & AV_DISPOSITION_ATTACHED_PIC)
+av_dict_set(&ist->decoder_opts, "threads", "1", 0);
+
if ((ret = avcodec_open2(ist->dec_ctx, codec, &ist->decoder_opts)) <
0) {
if (ret == AVERROR_EXPERIMENTAL)
abort_codec_experimental(codec, 0);
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] ffmpeg: default to single thread when hwaccel is active
On 29.09.2021 19:17, Dennis Mungai wrote: A potential downside to this would be on QSV's side, which needs at least 2 threads to prevent dead-locking, see https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/scheduler/linux/src/mfx_scheduler_core_ischeduler.cpp#L90-L93 Is that even controlled by the avcodec threads parameter? I can't find any occurrence of "numberOfThreads" anywhere in the entire codebase. smime.p7s Description: S/MIME Cryptographic 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] [RFC] ffmpeg: default to single thread when hwaccel is active
On 29.09.2021 19:31, Dennis Mungai wrote: On Wed, 29 Sept 2021 at 20:22, Timo Rothenpieler wrote: On 29.09.2021 19:17, Dennis Mungai wrote: A potential downside to this would be on QSV's side, which needs at least 2 threads to prevent dead-locking, see https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/scheduler/linux/src/mfx_scheduler_core_ischeduler.cpp#L90-L93 Is that even controlled by the avcodec threads parameter? I can't find any occurrence of "numberOfThreads" anywhere in the entire codebase. See this patchwork: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210408070929.860244-1-haihao.xi...@intel.com/ Submitted by Haihao Xiang, CC'ed herein. That almost makes me think we'd need a per-hwaccel default of the thread count. Preferably not hacked as hard coded list into ffmpeg.c smime.p7s Description: S/MIME Cryptographic 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] [RFC] ffmpeg: default to single thread when hwaccel is active
On 30.09.2021 02:02, Andreas Rheinhardt wrote: Timo Rothenpieler: On 29.09.2021 19:31, Dennis Mungai wrote: On Wed, 29 Sept 2021 at 20:22, Timo Rothenpieler wrote: On 29.09.2021 19:17, Dennis Mungai wrote: A potential downside to this would be on QSV's side, which needs at least 2 threads to prevent dead-locking, see https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/scheduler/linux/src/mfx_scheduler_core_ischeduler.cpp#L90-L93 Is that even controlled by the avcodec threads parameter? I can't find any occurrence of "numberOfThreads" anywhere in the entire codebase. See this patchwork: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210408070929.860244-1-haihao.xi...@intel.com/ Submitted by Haihao Xiang, CC'ed herein. That almost makes me think we'd need a per-hwaccel default of the thread count. Preferably not hacked as hard coded list into ffmpeg.c This can be done via AVCodecDefaults: The qsv codecs should use a thread default of "auto" and ffmpeg.c should check whether the threads parameter has been overridden by an AVCodecDefault (by checking whether it is set to its default value) before overriding it in case the user did not explicitly set something. Does that also work for hwaccels though? For the most part, the codec is always the native hevc/h264/... decoder. - Andreas PS: The qsv patch also needs to check the AV_CODEC_CAP_OTHER_THREADS cap (so that user know that setting the threads option makes sense). smime.p7s Description: S/MIME Cryptographic 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] avfilter: add sharpen_npp video filter
On 30.09.2021 20:51, Roman Arzumanyan wrote: Thanks for review, Timo. Please find revised patch attached. (de)interlacing is now removed, doc entry was added as well. applied with a few minor amendments, thanks! While testing this via "-vf scale_npp=format=yuv420p,sharpen_npp" I discovered a weird issue where the last line of pixels was pink/purple, apparently missing the luma plane. This turned out to be a bug in scale_npp, which returned frames with a height of 1088 instead of 1080 for a 1080p source. It was fairly simple to fix, and I also pushed that fix: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=37745b49049d4dbb5aa4ea84bcc289ed511971f9 I'm just very surprised that nobody noticed this issue in such a long time. Timo smime.p7s Description: S/MIME Cryptographic 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: export pkg-config includedir variable
On 08.10.2021 15:32, James Almer wrote: Some packages may not define custom cflags, in which case a simple "pkg-config --cflags" call will return an empty string. This change will be useful to get a valid include path that can be used in library checks. Is that at all a standard thing with pkgconfig? From how I understand it, a .pc file could also call that variable incdir, or whatever it likes? Never seen that done before anywhere. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/scale_npp: add scale2ref_npp filter
From: Roman Arzumanyan
Signed-off-by: Timo Rothenpieler
---
Here's my revised version of the patch.
It brings its order of operation much more in line with normal scale/scale2ref.
Also gets rid of differences in option parsing between the 2ref and non-2ref
version of the filters.
I also added some more options, like the eval option or size, size it was used
anyway, just not exposed.
If no further issues or comments arise, I will apply this patch in a few days.
I also plan to come up with a similar patch for scale_cuda.
doc/filters.texi | 111
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_scale_npp.c | 544 ++---
4 files changed, 618 insertions(+), 40 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 177f0774fc..8eae567f01 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18494,6 +18494,7 @@ scale_cuda=passthrough=0
@end example
@end itemize
+@anchor{scale_npp}
@section scale_npp
Use the NVIDIA Performance Primitives (libnpp) to perform scaling and/or pixel
@@ -18570,6 +18571,61 @@ This option can be handy if you need to have a video
fit within or exceed
a defined resolution using @option{force_original_aspect_ratio} but also have
encoder restrictions on width or height divisibility.
+@item eval
+Specify when to evaluate @var{width} and @var{height} expression. It accepts
the following values:
+
+@table @samp
+@item init
+Only evaluate expressions once during the filter initialization or when a
command is processed.
+
+@item frame
+Evaluate expressions for each incoming frame.
+
+@end table
+
+@end table
+
+The values of the @option{w} and @option{h} options are expressions
+containing the following constants:
+
+@table @var
+@item in_w
+@item in_h
+The input width and height
+
+@item iw
+@item ih
+These are the same as @var{in_w} and @var{in_h}.
+
+@item out_w
+@item out_h
+The output (scaled) width and height
+
+@item ow
+@item oh
+These are the same as @var{out_w} and @var{out_h}
+
+@item a
+The same as @var{iw} / @var{ih}
+
+@item sar
+input sample aspect ratio
+
+@item dar
+The input display aspect ratio. Calculated from @code{(iw / ih) * sar}.
+
+@item n
+The (sequential) number of the input frame, starting from 0.
+Only available with @code{eval=frame}.
+
+@item t
+The presentation timestamp of the input frame, expressed as a number of
+seconds. Only available with @code{eval=frame}.
+
+@item pos
+The position (byte offset) of the frame in the input stream, or NaN if
+this information is unavailable and/or meaningless (for example in case of
synthetic video).
+Only available with @code{eval=frame}.
@end table
@section scale2ref
@@ -18645,6 +18701,61 @@ If the specified expression is not valid, it is kept
at its current
value.
@end table
+@section scale2ref_npp
+
+Use the NVIDIA Performance Primitives (libnpp) to scale (resize) the input
+video, based on a reference video.
+
+See the @ref{scale_npp} filter for available options, scale2ref_npp supports
the same
+but uses the reference video instead of the main input as basis. scale2ref_npp
+also supports the following additional constants for the @option{w} and
+@option{h} options:
+
+@table @var
+@item main_w
+@item main_h
+The main input video's width and height
+
+@item main_a
+The same as @var{main_w} / @var{main_h}
+
+@item main_sar
+The main input video's sample aspect ratio
+
+@item main_dar, mdar
+The main input video's display aspect ratio. Calculated from
+@code{(main_w / main_h) * main_sar}.
+
+@item main_n
+The (sequential) number of the main input frame, starting from 0.
+Only available with @code{eval=frame}.
+
+@item main_t
+The presentation timestamp of the main input frame, expressed as a number of
+seconds. Only available with @code{eval=frame}.
+
+@item main_pos
+The position (byte offset) of the frame in the main input stream, or NaN if
+this information is unavailable and/or meaningless (for example in case of
synthetic video).
+Only available with @code{eval=frame}.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Scale a subtitle stream (b) to match the main video (a) in size before
overlaying
+@example
+'scale2ref_npp[b][a];[a][b]overlay_cuda'
+@end example
+
+@item
+Scale a logo to 1/10th the height of a video, while preserving its display
aspect ratio.
+@example
+[logo-in][video-in]scale2ref_npp=w=oh*mdar:h=ih/10[logo-out][video-out]
+@end example
+@end itemize
+
@section scharr
Apply scharr operator to input video stream.
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 409ab5d3c4..667b6fc246 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -396,6 +396,7 @@ extern const AVFilter ff_vf_scale_qsv;
extern const AVFilter ff_vf_scale_vaapi;
extern const AVFilter ff_vf_scale_vulkan;
extern const AVFilter ff_vf_scale2ref;
+extern const AVFilter ff_vf_scale2ref_npp;
extern const AVFil
Re: [FFmpeg-devel] [PATCH] avfilter/scale_npp: add scale2ref_npp filter
On 31.10.2021 14:35, Timo Rothenpieler wrote: From: Roman Arzumanyan Signed-off-by: Timo Rothenpieler --- Here's my revised version of the patch. It brings its order of operation much more in line with normal scale/scale2ref. Also gets rid of differences in option parsing between the 2ref and non-2ref version of the filters. I also added some more options, like the eval option or size, size it was used anyway, just not exposed. If no further issues or comments arise, I will apply this patch in a few days. I also plan to come up with a similar patch for scale_cuda. doc/filters.texi | 111 libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vf_scale_npp.c | 544 ++--- 4 files changed, 618 insertions(+), 40 deletions(-) The configure/Makefile line for this got somehow lost in rebase. Added locally. smime.p7s Description: S/MIME Cryptographic 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] avfilter/scale_npp: add scale2ref_npp filter
On 31.10.2021 14:54, Timo Rothenpieler wrote: On 31.10.2021 14:35, Timo Rothenpieler wrote: From: Roman Arzumanyan Signed-off-by: Timo Rothenpieler --- Here's my revised version of the patch. It brings its order of operation much more in line with normal scale/scale2ref. Also gets rid of differences in option parsing between the 2ref and non-2ref version of the filters. I also added some more options, like the eval option or size, size it was used anyway, just not exposed. If no further issues or comments arise, I will apply this patch in a few days. I also plan to come up with a similar patch for scale_cuda. doc/filters.texi | 111 libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vf_scale_npp.c | 544 ++--- 4 files changed, 618 insertions(+), 40 deletions(-) The configure/Makefile line for this got somehow lost in rebase. Added locally. applied smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavfi: add a libplacebo filter
On 15.11.2021 19:21, Dennis Mungai wrote: Hello. Were you able to build FFmpeg with this filter enabled? So far, building this package does not generate any pkgconfig file in the configured prefix, and FFmpeg's ./configure cannot detect it. I filed the issue on libplacebo's project page, with more details: https://github.com/haasn/libplacebo/issues/110 Yes, I had no issues with that. Had to slightly patch the .pc file for static linking for my needs, but other than that, it just works: https://github.com/BtbN/FFmpeg-Builds/blob/master/scripts.d/50-vulkan/60-libplacebo.sh smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavfi: add nlmeans CUDA filter
+for (i = 0; i < nb_pixel / 4; i++) {
+
+int *dx_cur = dxdy + 8 * i;
+int *dy_cur = dxdy + 8 * i + 4;
+
+call_horiz(ctx, 1, src_dptr, src_width, src_height, src_pitch,
+ integ_img, dx_cur, dy_cur, pixel_size);
+
+call_vert(ctx, 1, src_width, src_height, integ_img, pixel_size);
+
+call_weight(ctx, 1, src_dptr, src_width, src_height, src_pitch, integ_img,
(float*)s->sum, (float*)s->weight, p, dx_cur, dy_cur, pixel_size);
+}
+
+call_average(ctx, 1, src_dptr, src_width, src_height, src_pitch,
(float*)s->sum, (float*)s->weight,
+ dst_dptr, dst_width, dst_height, dst_pitch, pixel_size);
My immediate thought when seeing that block is "move this all to the
CUDA side", but you're calling all those with different block layouts?
I don't understand the algorithm well enough, so I guess this is necessary.
How well does it perform? All those jumps between C and CUDA code come
at an overhead.
Some other nits:
I'm not a fan of a functions just called "init", "uninit" and so on.
It's not wrong, given it's static, but it's usually nicer to give all
functions a common prefix. "cunlmeans_" or something like that.
What's up with that if(!s->initialised) block in filter_frame? I would
have thought it's logically impossible that it gets that far without
init being called?
Otherwise, the filter looks fine to me.
smime.p7s
Description: S/MIME Cryptographic 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] avutil/hwcontext_cuda: check that the SDK defines cuCtxGetCurrent()
On 06.10.2023 18:43, Hendrik Leppkes wrote: On Fri, Oct 6, 2023 at 3:47 PM Timo Rothenpieler wrote: I'm quite confused why this specific instance suddenly causes so much upset. Because its bad form to break compilation of master, if all it took to avoid that is change the order of pushing a tag to one repo and a patch to another. I think you are misunderstanding the versioning of the headers? They were already on the right version, all you needed to do was update them. There was never a time where it was impossible to build ffmpeg. ___ 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] ffprobe: fix XML rendering, review XML layout
On 14.10.2023 19:24, Stefano Sabatini wrote: Fix rendering of int values within a side data element, which was broken since commit d2d3a83ad93, where the side data element was correctly marked as a variable fields element. Logic to render a string variable was implemented already, but it was not implemented for the int fields path, which was enabled by that commit. Also, code and schema is changed in order to account for multiple variable-fields elements - such as side data, contained within the same parent. Previously it was assumed that a single variable-fields element was contained within the parent, which was the case for tags, but is not the case for side-data. Previously data was rendered as: Now as: Isn't a change like that practically an ABI break, and thus would need to happen on a major bump? Alternatively, just leave the old fields as they were, they looks like they can coexist with the new ones. At least XML wise. ___ 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] avfilter/vidstab: add option for file format specification
On 22.10.2023 13:24, Gyan Doshi wrote:
The vidstab library added support in Nov 2020 for writing/reading
the transforms data in binary in addition to ASCII. The library default
was changed to binary format but no changes were made to the AVfilters
resulting in data file for writing or reading being always opened as text.
This effectively broke the filters.
Options added to vidstab{detect,transform} to specify file format
and open files with the correct attributes.
---
doc/filters.texi | 26 ++
libavfilter/vf_vidstabdetect.c| 15 ++-
libavfilter/vf_vidstabtransform.c | 15 ++-
3 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f5032ddf74..806448f063 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -24618,6 +24618,19 @@ If set to 0, it is disabled. The frames are counted
starting from 1.
Show fields and transforms in the resulting frames. It accepts an
integer in the range 0-2. Default value is 0, which disables any
visualization.
+
+@item fileformat
+Format for the transforms data file to be written.
+Acceptable values are
+
+@table @samp
+@item ascii
+Human-readable plain text
+
+@item binary
+Binary format, roughly 40% smaller than @code{ascii}. (@emph{default})
+@end table
+
@end table
@subsection Examples
@@ -24772,6 +24785,19 @@ Use also @code{tripod} option of @ref{vidstabdetect}.
Increase log verbosity if set to 1. Also the detected global motions
are written to the temporary file @file{global_motions.trf}. Default
value is 0.
+
+@item fileformat
+Format of the transforms data file to be read.
+Acceptable values are
+
+@table @samp
+@item ascii
+Human-readable plain text
+
+@item binary
+Binary format (@emph{default})
+@end table
+
@end table
@subsection Examples
diff --git a/libavfilter/vf_vidstabdetect.c b/libavfilter/vf_vidstabdetect.c
index a2c6d89503..aa050afab9 100644
--- a/libavfilter/vf_vidstabdetect.c
+++ b/libavfilter/vf_vidstabdetect.c
@@ -40,6 +40,7 @@ typedef struct StabData {
VSMotionDetectConfig conf;
char *result;
+int fileformat;
FILE *f;
} StabData;
@@ -58,6 +59,11 @@ static const AVOption vidstabdetect_options[] = {
{"show","0: draw nothing; 1,2: show fields and transforms",
OFFSETC(show), AV_OPT_TYPE_INT,{.i64 = 0}, 0, 2, FLAGS},
{"tripod", "virtual tripod mode (if >0): motion is compared to a
reference"
" reference frame (frame # is the value)",
OFFSETC(virtualTripod), AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, FLAGS},
+#ifdef LIBVIDSTAB_FILE_FORMAT_VERSION
+{ "fileformat", "transforms data file format", OFFSET(fileformat),
AV_OPT_TYPE_INT, {.i64 = BINARY_SERIALIZATION_MODE}, ASCII_SERIALIZATION_MODE, BINARY_SERIALIZATION_MODE,
FLAGS, "file_format"},
+{ "ascii","ASCII text", 0, AV_OPT_TYPE_CONST, {.i64 =
ASCII_SERIALIZATION_MODE }, 0, 0, FLAGS, "file_format"},
+{ "binary", "binary", 0, AV_OPT_TYPE_CONST, {.i64 =
BINARY_SERIALIZATION_MODE}, 0, 0, FLAGS, "file_format"},
+#endif
{NULL}
};
@@ -94,6 +100,13 @@ static int config_input(AVFilterLink *inlink)
VSFrameInfo fi;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
int is_planar = desc->flags & AV_PIX_FMT_FLAG_PLANAR;
+const char *file_mode = "w";
+
+#ifdef LIBVIDSTAB_FILE_FORMAT_VERSION
+md->serializationMode = s->fileformat;
+if (s->fileformat == BINARY_SERIALIZATION_MODE)
+file_mode = "wb";
+#endif
vsFrameInfoInit(&fi, inlink->w, inlink->h,
ff_av2vs_pixfmt(ctx, inlink->format));
@@ -129,7 +142,7 @@ static int config_input(AVFilterLink *inlink)
av_log(ctx, AV_LOG_INFO, " show = %d\n", s->conf.show);
av_log(ctx, AV_LOG_INFO, "result = %s\n", s->result);
-s->f = avpriv_fopen_utf8(s->result, "w");
+s->f = avpriv_fopen_utf8(s->result, file_mode);
if (s->f == NULL) {
av_log(ctx, AV_LOG_ERROR, "cannot open transform file %s\n",
s->result);
return AVERROR(EINVAL);
diff --git a/libavfilter/vf_vidstabtransform.c
b/libavfilter/vf_vidstabtransform.c
index 8a66a463b4..780bf1064d 100644
--- a/libavfilter/vf_vidstabtransform.c
+++ b/libavfilter/vf_vidstabtransform.c
@@ -42,6 +42,7 @@ typedef struct TransformContext {
char *input;// name of transform file
int tripod;
int debug;
+int fileformat;
} TransformContext;
#define OFFSET(x) offsetof(TransformContext, x)
@@ -101,6 +102,12 @@ static const AVOption vidstabtransform_options[] = {
AV_OPT_TYPE_BOOL, {.i64 = 0},0, 1,FLAGS},
{"debug", "enable debug mode and writer global motions information to
file", OFFSET(debug),
AV_OPT_TYPE_BOOL, {.i64 = 0},
Re: [FFmpeg-devel] [PATCH] avfilter/vidstab: add option for file format specification
On 22.10.2023 13:57, Gyan Doshi wrote:
On 2023-10-22 05:04 pm, Timo Rothenpieler wrote:
On 22.10.2023 13:24, Gyan Doshi wrote:
The vidstab library added support in Nov 2020 for writing/reading
the transforms data in binary in addition to ASCII. The library default
was changed to binary format but no changes were made to the AVfilters
resulting in data file for writing or reading being always opened as
text.
This effectively broke the filters.
Options added to vidstab{detect,transform} to specify file format
and open files with the correct attributes.
---
doc/filters.texi | 26 ++
libavfilter/vf_vidstabdetect.c | 15 ++-
libavfilter/vf_vidstabtransform.c | 15 ++-
3 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f5032ddf74..806448f063 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -24618,6 +24618,19 @@ If set to 0, it is disabled. The frames are
counted starting from 1.
Show fields and transforms in the resulting frames. It accepts an
integer in the range 0-2. Default value is 0, which disables any
visualization.
+
+@item fileformat
+Format for the transforms data file to be written.
+Acceptable values are
+
+@table @samp
+@item ascii
+Human-readable plain text
+
+@item binary
+Binary format, roughly 40% smaller than @code{ascii}. (@emph{default})
+@end table
+
@end table
@subsection Examples
@@ -24772,6 +24785,19 @@ Use also @code{tripod} option of
@ref{vidstabdetect}.
Increase log verbosity if set to 1. Also the detected global motions
are written to the temporary file @file{global_motions.trf}. Default
value is 0.
+
+@item fileformat
+Format of the transforms data file to be read.
+Acceptable values are
+
+@table @samp
+@item ascii
+Human-readable plain text
+
+@item binary
+Binary format (@emph{default})
+@end table
+
@end table
@subsection Examples
diff --git a/libavfilter/vf_vidstabdetect.c
b/libavfilter/vf_vidstabdetect.c
index a2c6d89503..aa050afab9 100644
--- a/libavfilter/vf_vidstabdetect.c
+++ b/libavfilter/vf_vidstabdetect.c
@@ -40,6 +40,7 @@ typedef struct StabData {
VSMotionDetectConfig conf;
char *result;
+ int fileformat;
FILE *f;
} StabData;
@@ -58,6 +59,11 @@ static const AVOption vidstabdetect_options[] = {
{"show", "0: draw nothing; 1,2: show fields and
transforms", OFFSETC(show), AV_OPT_TYPE_INT, {.i64 =
0}, 0, 2, FLAGS},
{"tripod", "virtual tripod mode (if >0): motion is
compared to a reference"
" reference frame (frame # is the
value)", OFFSETC(virtualTripod),
AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS},
+#ifdef LIBVIDSTAB_FILE_FORMAT_VERSION
+ { "fileformat", "transforms data file format",
OFFSET(fileformat), AV_OPT_TYPE_INT, {.i64 =
BINARY_SERIALIZATION_MODE}, ASCII_SERIALIZATION_MODE,
BINARY_SERIALIZATION_MODE, FLAGS, "file_format"},
+ { "ascii", "ASCII text", 0, AV_OPT_TYPE_CONST, {.i64 =
ASCII_SERIALIZATION_MODE }, 0, 0, FLAGS, "file_format"},
+ { "binary", "binary", 0, AV_OPT_TYPE_CONST, {.i64 =
BINARY_SERIALIZATION_MODE}, 0, 0, FLAGS, "file_format"},
+#endif
{NULL}
};
@@ -94,6 +100,13 @@ static int config_input(AVFilterLink *inlink)
VSFrameInfo fi;
const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(inlink->format);
int is_planar = desc->flags & AV_PIX_FMT_FLAG_PLANAR;
+ const char *file_mode = "w";
+
+#ifdef LIBVIDSTAB_FILE_FORMAT_VERSION
+ md->serializationMode = s->fileformat;
+ if (s->fileformat == BINARY_SERIALIZATION_MODE)
+ file_mode = "wb";
+#endif
vsFrameInfoInit(&fi, inlink->w, inlink->h,
ff_av2vs_pixfmt(ctx, inlink->format));
@@ -129,7 +142,7 @@ static int config_input(AVFilterLink *inlink)
av_log(ctx, AV_LOG_INFO, " show = %d\n", s->conf.show);
av_log(ctx, AV_LOG_INFO, " result = %s\n", s->result);
- s->f = avpriv_fopen_utf8(s->result, "w");
+ s->f = avpriv_fopen_utf8(s->result, file_mode);
if (s->f == NULL) {
av_log(ctx, AV_LOG_ERROR, "cannot open transform file
%s\n", s->result);
return AVERROR(EINVAL);
diff --git a/libavfilter/vf_vidstabtransform.c
b/libavfilter/vf_vidstabtransform.c
index 8a66a463b4..780bf1064d 100644
--- a/libavfilter/vf_vidstabtransform.c
+++ b/libavfilter/vf_vidstabtransform.c
@@ -42,6 +42,7 @@ typedef struct TransformContext {
char *input; // name of transform file
int tripod;
int debug;
+ int fileformat;
} TransformContext;
#define OFFSET(x) offset
Re: [FFmpeg-devel] [PATCH 4/6] libavformat/webrtc: add common code for WebRTC streaming
On 06.11.2023 16:19, Michael Riedl wrote:
Signed-off-by: Michael Riedl
---
libavformat/webrtc.c | 398 +++
libavformat/webrtc.h | 70
2 files changed, 468 insertions(+)
create mode 100644 libavformat/webrtc.c
create mode 100644 libavformat/webrtc.h
diff --git a/libavformat/webrtc.c b/libavformat/webrtc.c
new file mode 100644
index 000..75884eac46f
--- /dev/null
+++ b/libavformat/webrtc.c
@@ -0,0 +1,398 @@
+/*
+ * WebRTC-HTTP ingestion/egress protocol (WHIP/WHEP) common code
+ *
+ * Copyright (C) 2023 NativeWaves GmbH
+ * This work is supported by FFG project 47168763.
+ *
+ * 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/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/uuid.h"
+#include "libavutil/random_seed.h"
+#include "rtpenc_chain.h"
+#include "rtsp.h"
+#include "webrtc.h"
+
+static const char* webrtc_get_state_name(const rtcState state)
+{
+switch (state)
+{
+case RTC_NEW:
+return "RTC_NEW";
+case RTC_CONNECTING:
+return "RTC_CONNECTING";
+case RTC_CONNECTED:
+return "RTC_CONNECTED";
+case RTC_DISCONNECTED:
+return "RTC_DISCONNECTED";
+case RTC_FAILED:
+return "RTC_FAILED";
+case RTC_CLOSED:
+return "RTC_CLOSED";
+default:
+return "UNKNOWN";
+}
+}
+
+static void webrtc_log(const rtcLogLevel rtcLevel, const char *const message)
+{
+int level = AV_LOG_VERBOSE;
+switch (rtcLevel)
+{
+case RTC_LOG_NONE:
+level = AV_LOG_QUIET;
+break;
+case RTC_LOG_DEBUG:
+case RTC_LOG_VERBOSE:
+level = AV_LOG_DEBUG;
+break;
+case RTC_LOG_INFO:
+level = AV_LOG_VERBOSE;
+break;
+case RTC_LOG_WARNING:
+level = AV_LOG_WARNING;
+break;
+case RTC_LOG_ERROR:
+level = AV_LOG_ERROR;
+break;
+case RTC_LOG_FATAL:
+level = AV_LOG_FATAL;
+break;
+}
+
+av_log(NULL, level, "[libdatachannel] %s\n", message);
+}
+
+void webrtc_init_logger(void)
+{
+rtcLogLevel level = RTC_LOG_VERBOSE;
+switch (av_log_get_level())
+{
+case AV_LOG_QUIET:
+level = RTC_LOG_NONE;
+break;
+case AV_LOG_DEBUG:
+level = RTC_LOG_DEBUG;
+break;
+case AV_LOG_VERBOSE:
+level = RTC_LOG_VERBOSE;
+break;
+case AV_LOG_WARNING:
+level = RTC_LOG_WARNING;
+break;
+case AV_LOG_ERROR:
+level = RTC_LOG_ERROR;
+break;
+case AV_LOG_FATAL:
+level = RTC_LOG_FATAL;
+break;
+}
+
+rtcInitLogger(level, webrtc_log);
+}
+
+int webrtc_generate_media_stream_id(char media_stream_id[37])
+{
+int ret;
+AVUUID uuid;
+
+ret = av_random_bytes(uuid, sizeof(uuid));
+if (ret < 0) {
+goto fail;
+}
+av_uuid_unparse(uuid, media_stream_id);
+return 0;
+
+fail:
+return ret;
+}
+
+int webrtc_create_resource(DataChannelContext*const ctx)
+{
+int ret;
+URLContext* h = NULL;
+char* headers;
+char offer_sdp[SDP_MAX_SIZE] = { 0 };
+char response_sdp[SDP_MAX_SIZE] = { 0 };
+
+/* set local description */
+if (rtcSetLocalDescription(ctx->peer_connection, "offer") !=
RTC_ERR_SUCCESS) {
+av_log(ctx->avctx, AV_LOG_ERROR, "Failed to set local description\n");
+ret = AVERROR_EXTERNAL;
+goto fail;
+}
+
+/* create offer */
+ret = rtcGetLocalDescription(ctx->peer_connection, offer_sdp,
sizeof(offer_sdp));
+if (ret < 0) {
+av_log(ctx->avctx, AV_LOG_ERROR, "Failed to get local description\n");
+ret = AVERROR_EXTERNAL;
+goto fail;
+}
+av_log(ctx->avctx, AV_LOG_VERBOSE, "offer_sdp: %s\n", offer_sdp);
+
+/* alloc the http context */
+if ((ret = ffurl_alloc(&h, ctx->avctx->url, AVIO_FLAG_READ_WRITE, NULL)) <
0) {
+av_log(ctx->avctx, AV_LOG_ERROR, "ffurl_alloc failed\n");
+goto fail;
+}
+
+/* set options */
+headers = av_asprintf("Content-type: application/sdp\r
Re: [FFmpeg-devel] [IMPORTANT] banned on irc
On 24/11/2023 10:38, Paul B Mahol wrote: Can not access irc anymore. Does it tell you which specific ban affects you? A bunch of likely way too broad bans were installed yesterday. ___ 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] Fixed nvenc release dump
I don't quite understand the commit message.
It should start with "avcodec/nvenc:" and then state what it's changing
and why.
On 24/11/2023 08:04, GOOR, Jean-Noel wrote:
Signed-off-by: GOOR, Jean-Noël
---
libavcodec/nvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 3c68ed3930..1f8c7e8c0e 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1860,7 +1860,7 @@ av_cold int ff_nvenc_encode_close(AVCodecContext *avctx)
av_fifo_freep2(&ctx->unused_surface_queue);
if (ctx->frame_data_array) {
-for (i = 0; i < ctx->nb_surfaces; i++)
+ for (i = 0; i < ctx->frame_data_array_nb; i++)
Wrong indentation.
The change itself looks correct to me on first glance.
Did you find this via a leak checker?
av_buffer_unref(&ctx->frame_data_array[i].frame_opaque_ref);
av_freep(&ctx->frame_data_array);
}
___
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] avutil/mem: always align by at least 32 bytes
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. Instead of now going through all instances of variables in structs being declared as 32 byte aligned, this patch bumps the minimum alignment to 32 bytes. --- libavutil/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/mem.c b/libavutil/mem.c index 36b8940a0c..26a9b9753b 100644 --- a/libavutil/mem.c +++ b/libavutil/mem.c @@ -62,7 +62,7 @@ void free(void *ptr); #endif /* MALLOC_PREFIX */ -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) +#define ALIGN (HAVE_AVX512 ? 64 : 32) /* NOTE: if you want to override these functions with your own * implementations (not recommended) you have to link libav* as -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: Set default bitrate to 2M
On 05.12.2023 09:15, Xiang, Haihao wrote:
From: Haihao Xiang
2M is suitable for more cases, e.g. 4K video.
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc_av1.c | 2 +-
libavcodec/qsvenc_h264.c | 2 +-
libavcodec/qsvenc_hevc.c | 2 +-
libavcodec/qsvenc_mpeg2.c | 2 +-
libavcodec/qsvenc_vp9.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/qsvenc_av1.c b/libavcodec/qsvenc_av1.c
index c697845d7b..78c92c1844 100644
--- a/libavcodec/qsvenc_av1.c
+++ b/libavcodec/qsvenc_av1.c
@@ -129,7 +129,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M" },
+{ "b", "2M" },
Wouldn't it be better to use a constant quality option as default,
rather than a fixed bitrate?
2M still seems incredibly low for 1080p, let alone for 4K content.
{ "g", "-1" },
{ "bf","-1" },
{ "refs", "0"},
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 071a9a79e9..37b39cb441 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -178,7 +178,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
{ "g", "-1"},
{ "bf","-1"},
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index c5b7ac7cc4..181d06cb00 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -374,7 +374,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
{ "g", "248" },
{ "bf","-1"},
diff --git a/libavcodec/qsvenc_mpeg2.c b/libavcodec/qsvenc_mpeg2.c
index 22f1ff7c0d..012cec3a58 100644
--- a/libavcodec/qsvenc_mpeg2.c
+++ b/libavcodec/qsvenc_mpeg2.c
@@ -82,7 +82,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
// same as the x264 default
{ "g", "250" },
diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
index d0340ef94b..8658b8ec2d 100644
--- a/libavcodec/qsvenc_vp9.c
+++ b/libavcodec/qsvenc_vp9.c
@@ -93,7 +93,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
{ "g", "250" },
{ "trellis", "-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/qsvenc: Set default bitrate to 2M
On 06/12/2023 07:51, Xiang, Haihao wrote:
On Di, 2023-12-05 at 12:47 +0100, Timo Rothenpieler wrote:
On 05.12.2023 09:15, Xiang, Haihao wrote:
From: Haihao Xiang
2M is suitable for more cases, e.g. 4K video.
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc_av1.c | 2 +-
libavcodec/qsvenc_h264.c | 2 +-
libavcodec/qsvenc_hevc.c | 2 +-
libavcodec/qsvenc_mpeg2.c | 2 +-
libavcodec/qsvenc_vp9.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/qsvenc_av1.c b/libavcodec/qsvenc_av1.c
index c697845d7b..78c92c1844 100644
--- a/libavcodec/qsvenc_av1.c
+++ b/libavcodec/qsvenc_av1.c
@@ -129,7 +129,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
Wouldn't it be better to use a constant quality option as default,
rather than a fixed bitrate?
Did you mean change the default bitrate control mode to CQP ? I was concerned
about the impact to current users.
Yeah, it's technically a breaking change.
Though at least libx264 also at some point changed its default to a
reasonable medium quality crf mode, away from a fixed, rather low, bitrate.
Not sure if that was done on a major bump, or if it was considered low
impact enough to just push out.
2M still seems incredibly low for 1080p, let alone for 4K content.
Some other HW encoders also use 2M, I'd like to use the same default value.
It's probably worth considering switching those to a crf equivalent as
well, where possible.
It matches much more what a typical user would expect if they input a
commandline with no further options.
Thanks
Haihao
{ "g", "-1" },
{ "bf", "-1" },
{ "refs", "0" },
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 071a9a79e9..37b39cb441 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -178,7 +178,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
{ "g", "-1" },
{ "bf", "-1" },
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index c5b7ac7cc4..181d06cb00 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -374,7 +374,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
{ "g", "248" },
{ "bf", "-1" },
diff --git a/libavcodec/qsvenc_mpeg2.c b/libavcodec/qsvenc_mpeg2.c
index 22f1ff7c0d..012cec3a58 100644
--- a/libavcodec/qsvenc_mpeg2.c
+++ b/libavcodec/qsvenc_mpeg2.c
@@ -82,7 +82,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
// same as the x264 default
{ "g", "250" },
diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
index d0340ef94b..8658b8ec2d 100644
--- a/libavcodec/qsvenc_vp9.c
+++ b/libavcodec/qsvenc_vp9.c
@@ -93,7 +93,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
{ "g", "250" },
{ "trellis", "-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 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] avutil/mem: always align by at least 32 bytes
On 03/12/2023 21:10, Timo Rothenpieler wrote: FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. Instead of now going through all instances of variables in structs being declared as 32 byte aligned, this patch bumps the minimum alignment to 32 bytes. --- libavutil/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/mem.c b/libavutil/mem.c index 36b8940a0c..26a9b9753b 100644 --- a/libavutil/mem.c +++ b/libavutil/mem.c @@ -62,7 +62,7 @@ void free(void *ptr); #endif /* MALLOC_PREFIX */ -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) +#define ALIGN (HAVE_AVX512 ? 64 : 32) /* NOTE: if you want to override these functions with your own * implementations (not recommended) you have to link libav* as ping ___ 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] avutil/mem: always align by at least 32 bytes
On 06/12/2023 13:31, James Almer wrote: On 12/3/2023 5:10 PM, Timo Rothenpieler wrote: FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Wont we run into similar issues with avx512 eventually? It's only indirectly related to AVX. The core issue is that we have structs with elements that declare an alignment of 32 bytes all over the codebase. I checked all instances, and we do not have any struct members that declare a higher alignment requirement than 32. (There's two instances of 64 byte alignment, but those are not on struct members, but on stack variables.) This promises the compiler that the memory of the whole struct is aligned accordingly. So no matter if it breaks because of AVX or something else, the compiler could generate broken code if we heap allocate those structs with too small of an alignment. It could generate other, non-AVX code, that depends on that alignment. So we will only run into this again if someone decides to add a struct member with bigger alignment to a heap allocated struct somewhere. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. Instead of now going through all instances of variables in structs being declared as 32 byte aligned, this patch bumps the minimum alignment to 32 bytes. --- libavutil/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/mem.c b/libavutil/mem.c index 36b8940a0c..26a9b9753b 100644 --- a/libavutil/mem.c +++ b/libavutil/mem.c @@ -62,7 +62,7 @@ void free(void *ptr); #endif /* MALLOC_PREFIX */ -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) +#define ALIGN (HAVE_AVX512 ? 64 : 32) /* NOTE: if you want to override these functions with your own * implementations (not recommended) you have to link libav* as ___ 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] avutil/mem: always align by at least 32 bytes
On 06/12/2023 14:25, Martin Storsjö wrote:
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
Instead of now going through all instances of variables in structs
being declared as 32 byte aligned, this patch bumps the minimum alignment
to 32 bytes.
---
libavutil/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..26a9b9753b 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,7 @@ void free(void *ptr);
#endif /* MALLOC_PREFIX */
-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
+#define ALIGN (HAVE_AVX512 ? 64 : 32)
LGTM
It could be good to add a comment here, to indicate how this value
relates to the alignemnts used in structs.
For others who commented in this thread, it all boils down to something
like this:
struct MyData {
uint8_t __attribute__((aligned(32))) aligned_data[1024];
};
It's even a bit more complex than that.
The case that's crashing right now is a member that has no alignment
declared on itself at all.
But another member of the same struct does, and so the compiler assumes
the whole struct to be aligned.
void func(void) {
struct MyData *obj = malloc(sizeof(*obj)); // Uusally only aligned
to 8 bytes
// operate on obj->aligned_data[]
}
Due to how aligned_data is declared, we promise to the compiler that it
is aligned to 32 bytes, and that the compiler can assume this wherever.
Depending on -march or whatever, this can be to access it with
instructions that assume 32 byte alignment.
// 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 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] avutil/mem: always align by at least 32 bytes
On 06.12.2023 14:25, Martin Storsjö wrote:
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
Instead of now going through all instances of variables in structs
being declared as 32 byte aligned, this patch bumps the minimum alignment
to 32 bytes.
---
libavutil/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..26a9b9753b 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,7 @@ void free(void *ptr);
#endif /* MALLOC_PREFIX */
-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
+#define ALIGN (HAVE_AVX512 ? 64 : 32)
LGTM
It could be good to add a comment here, to indicate how this value
relates to the alignemnts used in structs.
Thinking about this, I don't think a comment _here_ is a good idea.
I'd be more inclined to add it to the DECLARE_ALIGNED macro.
People defining a new aligned member variable are at least a little more
likely to read that, compared to something next to this random define
that's not even in a header.
Will add that and push soon.
I'll also check how far this will need backported. Likely to almost all
versions ever.
For others who commented in this thread, it all boils down to something
like this:
struct MyData {
uint8_t __attribute__((aligned(32))) aligned_data[1024];
};
void func(void) {
struct MyData *obj = malloc(sizeof(*obj)); // Uusally only aligned
to 8 bytes
// operate on obj->aligned_data[]
}
Due to how aligned_data is declared, we promise to the compiler that it
is aligned to 32 bytes, and that the compiler can assume this wherever.
Depending on -march or whatever, this can be to access it with
instructions that assume 32 byte alignment.
// 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 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] avutil/mem: always align by at least 32 bytes
On 08.12.2023 11:01, Andreas Rheinhardt wrote: Timo Rothenpieler: FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. Instead of now going through all instances of variables in structs being declared as 32 byte aligned, this patch bumps the minimum alignment to 32 bytes. --- libavutil/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/mem.c b/libavutil/mem.c index 36b8940a0c..26a9b9753b 100644 --- a/libavutil/mem.c +++ b/libavutil/mem.c @@ -62,7 +62,7 @@ void free(void *ptr); #endif /* MALLOC_PREFIX */ -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) +#define ALIGN (HAVE_AVX512 ? 64 : 32) /* NOTE: if you want to override these functions with your own * implementations (not recommended) you have to link libav* as 1. There is another way in which this can be triggered: Namely if one uses a build with AVX, but combines it with a lavu built without it; it is also triggerable on non-x86 (having an insufficiently aligned pointer is always UB even if the CPU does not have instructions that would benefit from the additional alignment). You should mention this in the commit message. Is mixing the libraries really a scenario we need to care about/support? And yeah, this is only marginally related to AVX, in that it's what triggers a crash in this scenario. But as stated in the commit message, it's not a valid thing to do in any case, on any arch. It just happens not to crash. 2. This topic gave me headaches when creating RefStruct. I "solved" it by (ab)using STRIDE_ALIGN which mimicks the alignment of av_malloc(), thereby ensuring that RefStruct does not break lavc builds built with the avx dsp functions enabled (but it does not guard against using a lavu whose av_malloc() only provides less alignment). 3. There is a downside to your patch: It bumps alignment for non-x86 arches which wastes memory (and may make allocators slower). We could fix this by modifying the 32-byte-alignment macros to only provide 16 byte alignment if the ARCH_ (and potentially the HAVE_) defines indicate that no alignment bigger than 16 is needed. But it's invalid on any other arch as well, just hasn't bitten us yet. I'm not sure if I'd want to start maintaining a growingly complex list of CPU extensions and make the DECLARE_ALIGNED macro lie if we think it doesn't need 32 byte alignment. We don't really know why someone wants a variable aligned after all. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] scaling option
On 26/03/2019 13:47, Yufei He wrote: Hi Is there option for scaling on transcoding ? e.g. transcoding from a quadhd file to 640 * 480. Thanks. Yufei. Yes there is, but this is ffmpeg-devel, so not the place to ask user questions. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavfi: add colorkey_opencl filter
More a general question regarding OpenCL filters than related to this specific one. We are not integrating OpenCL acceleration into the relevant native filter anymore, like the very old original OpenCL infra worked, are we? So that vf_colorkey would just use OpenCL acceleration on its own whenever available and fallback to the software path otherwise. Timo smime.p7s Description: S/MIME Cryptographic 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] Patchwork attribution
On 18/04/2019 09:49, Gyan wrote: Patchwork can incorrectly assign ownership. See https://patchwork.ffmpeg.org/patch/12680/ The author is Sam John as identified by Message ID as well as the From field in the headers, yet Patchwork attributes this patch to "Oliver Collyer via ffmpeg-devel", a name which appears nowhere in the headers or in the submitted patch. The downloaded mbox patch shows the same wrong attribution. Does anyone know what's going on? Gyan ___ 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". This happens due to Mailman having to rewrite peoples E-Mail addresses if they have strong DKIM/DMARC configured on their sending Domain. If that is the case, only the server of the actual Domain who owns the right private key can send E-Mails under the name of that Domain. So for mailing lists to be able to send on the messages, they are forced to change the sender address. In the case of this list: Sam John gets translated to. Sam John via ffmpeg-devel Nothing can be sensibly done about this, cause the alternative would be the message getting rejected by the majority of Mailservers. It's unfortunate that this also messes with the patches. People who are affected should probably attach patches instead of using send-email. smime.p7s Description: S/MIME Cryptographic 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] Patchwork attribution
Ok. Then shouldn't it assign 'Sam John via ffmpeg-devel' as the author? It did do that for 'Oliver Collyer via ffmpeg-devel', the string wrongly substituted here. This looks like a parser failure in Patchwork. Gyan If the patch is sent with git send-email, the From: header of the E-Mail is where git puts the Author. So patchwork has no chance to correct this. smime.p7s Description: S/MIME Cryptographic 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] cuviddec: improved way of finding out if a frame is interlaced or progressive
applied, thanks. smime.p7s Description: S/MIME Cryptographic 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] [MSVC toolchain] Patch to allow building FFmpeg with Linux bash on Windows (WSL)
On 24/04/2019 01:38, Carl Eugen Hoyos wrote: 2017-12-29 13:16 GMT+01:00, Cyber Sinh : Sorry for the diff instead of regular git patch. Here is the patch. Only saw this today after wondering why nobody tried using wsl before... I'm using WSL since a while, but never bothered trying to setup MSVC with it. smime.p7s Description: S/MIME Cryptographic 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] [DECISION] Project policy on closed source components
On 28/04/2019 22:02, Marton Balint wrote: Hi All, There has been discussion on the mailing list several times about the inclusion of support for closed source components (codecs, formats, filters, etc) in the main ffmpeg codebase. Also the removal of libNDI happened without general consensus, so a vote is necessary to justify the removal. So here is a call to the voting committee [1] to decide on the following two questions: 1) Should libNDI support be removed from the ffmpeg codebase? No 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? They should have a very good reason to be included, but not generally be rejected just on that basis. On the example of NDI, its widespread use in video equipment and lack of alternatives gives it plenty of reason to be part of FFmpeg. So if this was still for vote in the current form, I'd say "No" here as well. smime.p7s Description: S/MIME Cryptographic 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: enable ffnvcodec, nvenc, nvdec for ppc64
applied smime.p7s Description: S/MIME Cryptographic 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/1] cuviddec: Add capability check for maximum macroblock count
applied smime.p7s Description: S/MIME Cryptographic 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] avfilter: add colorhold filter
On 04.05.2019 16:13, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 18 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_colorkey.c | 102 +-
4 files changed, 121 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index cd82869849..1ac37a32b8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6723,6 +6723,24 @@ ffmpeg -i background.png -i video.mp4 -filter_complex
"[1:v]colorkey=0x3BBD1E:0.
@end example
@end itemize
+@section colorhold
+Remove all color information for all RGB colors except for certain one.
+
+The filter accepts the following options:
+
+@table @option
+@item color
+The color which will not be replaced with neutral gray.
+
+@item similarity
+Similarity percentage with the above color.
+0.01 matches only the exact key color, while 1.0 matches everything.
+
+@item blend
+Blend percentage. 0.0 makes pixels fully gray.
+Higher values result in more preserved color.
+@end table
+
@section colorlevels
Adjust video input frames using levels.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 59d12ce069..b41304d480 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -179,6 +179,7 @@ OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER) +=
vf_colorchannelmixer.o
OBJS-$(CONFIG_COLORKEY_FILTER) += vf_colorkey.o
OBJS-$(CONFIG_COLORKEY_OPENCL_FILTER)+= vf_colorkey_opencl.o opencl.o
\
opencl/colorkey.o
+OBJS-$(CONFIG_COLORHOLD_FILTER) += vf_colorkey.o
OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o
OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspace.o
colorspacedsp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ae725cb0e0..9bdfa7d1bc 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -167,6 +167,7 @@ extern AVFilter ff_vf_colorbalance;
extern AVFilter ff_vf_colorchannelmixer;
extern AVFilter ff_vf_colorkey;
extern AVFilter ff_vf_colorkey_opencl;
+extern AVFilter ff_vf_colorhold;
extern AVFilter ff_vf_colorlevels;
extern AVFilter ff_vf_colormatrix;
extern AVFilter ff_vf_colorspace;
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 3d65e59d42..b546cd4122 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -34,6 +34,9 @@ typedef struct ColorkeyContext {
uint8_t colorkey_rgba[4];
float similarity;
float blend;
+
+int (*do_slice)(AVFilterContext *ctx, void *arg,
+int jobnr, int nb_jobs);
} ColorkeyContext;
static uint8_t do_colorkey_pixel(ColorkeyContext *ctx, uint8_t r, uint8_t g, uint8_t b)
@@ -77,15 +80,65 @@ static int do_colorkey_slice(AVFilterContext *avctx, void
*arg, int jobnr, int n
return 0;
}
+static int do_colorhold_slice(AVFilterContext *avctx, void *arg, int jobnr, int nb_jobs)
+{
+AVFrame *frame = arg;
+
+const int slice_start = (frame->height * jobnr) / nb_jobs;
+const int slice_end = (frame->height * (jobnr + 1)) / nb_jobs;
+
+ColorkeyContext *ctx = avctx->priv;
+
+int o, x, y;
+
+for (y = slice_start; y < slice_end; ++y) {
+for (x = 0; x < frame->width; ++x) {
+int t, r, g, b;
Nit, but I'd prefer to not mix "declaration at top" with intermittent
declaration of vars.
In this case, I'd just put o down here as well.
+o = frame->linesize[0] * y + x * 4;
+r = frame->data[0][o + ctx->co[0]];
+g = frame->data[0][o + ctx->co[1]];
+b = frame->data[0][o + ctx->co[2]];
+
+t = do_colorkey_pixel(ctx, r, g, b);
+
+if (t > 0) {
+int a = (r + g + b) / 3;
+int rt = 255 - t;
+
+frame->data[0][o + ctx->co[0]] = (a * t + r * rt + 127) >> 8;
+frame->data[0][o + ctx->co[1]] = (a * t + g * rt + 127) >> 8;
+frame->data[0][o + ctx->co[2]] = (a * t + b * rt + 127) >> 8;
+}
+}
+}
+
+return 0;
+}
+
+static av_cold int init_filter(AVFilterContext *avctx)
+{
+ColorkeyContext *ctx = avctx->priv;
+
+if (!strcmp(avctx->filter->name, "colorkey")) {
+ctx->do_slice = do_colorkey_slice;
+} else {
+ctx->do_slice = do_colorhold_slice;
+}
+
+return 0;
+}
+
static int filter_frame(AVFilterLink *link, AVFrame *frame)
{
AVFilterContext *avctx = link->dst;
+ColorkeyContext *ctx = avctx->priv;
int res;
if (res = av_frame_make_writable(frame))
return res;
-if (res = avctx->internal->execute(avctx, do_colorkey_slice, frame, NULL, FFMIN(frame->height, ff_filter_get_nb_threads(avctx
+if (res = avctx->internal->execute(avctx, ctx->do_slice, frame, NULL,
FFMIN(frame->height,
Re: [FFmpeg-devel] [PATCH] avfilter/drawtext: make command processing error-resilient
On 10/05/2019 15:55, Gyan wrote: At present, if the command args passed to drawtext contain any invalid values, ffmpeg may crash or, at best, stop drawing any text. Attached patch gets the filter to continue with existing parameters, if not all of the changes can be parsed or applied. This allows users in live processing to correct and resubmit. Gyan This patch has at least two mis-uses of av_freep(), which potentially lead to a crash. +av_freep(old); + +ctx->priv = new; Should probably be av_freep(&old); +fail: +av_log(ctx, AV_LOG_ERROR, "Failed to process command. Continuing with existing parameters.\n"); +av_freep(new); +return ret; Should probably be av_freep(&new); I did not do a full review of the patch, just pointing out those issues Coverity found. See coverity CID 1445099. Timo smime.p7s Description: S/MIME Cryptographic 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 0/3] avfilter/vf_scale_cuda: Various improvements
On 14.05.2019 05:12, Philip Langdale wrote: After Sergey's bug report, I went and fixed a couple of other things I noticed while I was looking at the filter. Philip Langdale (3): avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content avfilter/vf_scale_cuda: Add support for YUV444P16 avfilter/vf_scale_cuda: Simplify output plane addressing libavfilter/vf_scale_cuda.c | 41 + 1 file changed, 28 insertions(+), 13 deletions(-) Series LGTM smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On 22.05.2019 08:59, lance.lmw...@gmail.com wrote: From: Limin Wang The testing command for the HDR10 output with nvenc: $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020 -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \ -master_display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts Please notice it is preferable to use the frame sei side data than master_display and max_cll paramters config --- libavcodec/nvenc.c | 129 libavcodec/nvenc.h | 18 ++ libavcodec/nvenc_hevc.c | 11 3 files changed, 158 insertions(+) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 75dda6d689..3fd0eca4a5 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -22,6 +22,9 @@ #include "config.h" #include "nvenc.h" +#include "cbs_h265.h" +#include "hevc_sei.h" +#include "put_bits.h" #include "libavutil/hwcontext_cuda.h" #include "libavutil/hwcontext.h" @@ -30,6 +33,7 @@ #include "libavutil/avassert.h" #include "libavutil/mem.h" #include "libavutil/pixdesc.h" +#include "libavutil/mastering_display_metadata.h" #include "internal.h" #define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, dl_fn->cuda_dl, x) @@ -1491,6 +1495,46 @@ av_cold int ff_nvenc_encode_init(AVCodecContext *avctx) ctx->data_pix_fmt = avctx->pix_fmt; } +ctx->display_primaries_x[0] = 13250; +ctx->display_primaries_y[0] = 34500; +ctx->display_primaries_x[1] = 7500; +ctx->display_primaries_y[1] = 3000; +ctx->display_primaries_x[2] = 34000; +ctx->display_primaries_y[2] = 16000; +ctx->white_point_x = 15635; +ctx->white_point_y = 16450; +ctx->max_display_mastering_luminance = 1000; +ctx->min_display_mastering_luminance = 500; +ctx->max_content_light_level = 0; +ctx->max_pic_average_light_level = 0; Does all this really belong into an encoder? The command line parameter also looks very arcane. To me, this looks more like a filter or something should add this as extra data, and then multiple encoders can pick it up from there. Same goes for patch 3/3. Patch 1/3 is looks OK to me. Timo smime.p7s Description: S/MIME Cryptographic 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] Hardware acceleration decoding question
On 23.05.2019 10:06, Asaf Kave wrote: Hello all, I am using FFmpeg libarary in my software to do HW decoding for video (H.264\H.265) on windows machine. My decoding is based on 'hw_decode.c' example, and after i call decode a frame i am using AVFrame::data[3] to get the pointer to the IDirect3DSurface9 and use it in my video player. i didn't find any direction\example how to handle this pointer after i done with it, do i need to release it? or the library is responsible for that ? Thanks, Asaf This list is about development of FFmpeg itself, not for developing against its libraries. You are probably looking for libav-users. Regarding your question, the Hardware Buffers are wrapped in the internal buffers of the frame. So whenever you unref the frame, you should consider them as freed. In reality they just going to be re-used though. smime.p7s Description: S/MIME Cryptographic 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] lavfi/vf_scale_cuda: Add format option
On 24/05/2019 01:49, Josh Allmann wrote:
Makes certain usages of the lavfi API easier.
---
libavfilter/vf_scale_cuda.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index b7cdb81081..6b1ef2bb6f 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -81,6 +81,7 @@ typedef struct CUDAScaleContext {
char *w_expr; ///< width expression string
char *h_expr; ///< height expression string
+char *format_str;
CUcontext cu_ctx;
CUmodulecu_module;
@@ -101,7 +102,15 @@ static av_cold int cudascale_init(AVFilterContext *ctx)
{
CUDAScaleContext *s = ctx->priv;
-s->format = AV_PIX_FMT_NONE;
+if (!strcmp(s->format_str, "same")) {
+s->format = AV_PIX_FMT_NONE;
+} else {
+s->format = av_get_pix_fmt(s->format_str);
+if (s->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n",
s->format_str);
+return AVERROR(EINVAL);
+}
+}
s->frame = av_frame_alloc();
if (!s->frame)
return AVERROR(ENOMEM);
@@ -533,6 +542,7 @@ fail:
static const AVOption options[] = {
{ "w", "Output video width", OFFSET(w_expr), AV_OPT_TYPE_STRING, { .str =
"iw" }, .flags = FLAGS },
{ "h", "Output video height", OFFSET(h_expr), AV_OPT_TYPE_STRING, { .str =
"ih" }, .flags = FLAGS },
+{ "format", "Output pixel format", OFFSET(format_str), AV_OPT_TYPE_STRING, { .str =
"same" }, .flags = FLAGS },
{ NULL },
};
I'm not sure what to think about a dummy option like this. It might be
very confusing for users to see a format option, which only accepts a
single value, "same", and effectively does nothing.
Not strictly against it, since I can see the convenience it adds when
building command lines, but I'd like some second opinions on this.
smime.p7s
Description: S/MIME Cryptographic 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] lavfi/vf_scale_cuda: Add format option
On 24.05.2019 18:27, Josh Allmann wrote:
On Fri, 24 May 2019 at 06:00, Timo Rothenpieler wrote:
On 24/05/2019 01:49, Josh Allmann wrote:
Makes certain usages of the lavfi API easier.
---
libavfilter/vf_scale_cuda.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index b7cdb81081..6b1ef2bb6f 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -81,6 +81,7 @@ typedef struct CUDAScaleContext {
char *w_expr; ///< width expression string
char *h_expr; ///< height expression string
+char *format_str;
CUcontext cu_ctx;
CUmodulecu_module;
@@ -101,7 +102,15 @@ static av_cold int cudascale_init(AVFilterContext *ctx)
{
CUDAScaleContext *s = ctx->priv;
-s->format = AV_PIX_FMT_NONE;
+if (!strcmp(s->format_str, "same")) {
+s->format = AV_PIX_FMT_NONE;
+} else {
+s->format = av_get_pix_fmt(s->format_str);
+if (s->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n",
s->format_str);
+return AVERROR(EINVAL);
+}
+}
s->frame = av_frame_alloc();
if (!s->frame)
return AVERROR(ENOMEM);
@@ -533,6 +542,7 @@ fail:
static const AVOption options[] = {
{ "w", "Output video width", OFFSET(w_expr), AV_OPT_TYPE_STRING, { .str
= "iw" }, .flags = FLAGS },
{ "h", "Output video height", OFFSET(h_expr), AV_OPT_TYPE_STRING, { .str
= "ih" }, .flags = FLAGS },
+{ "format", "Output pixel format", OFFSET(format_str), AV_OPT_TYPE_STRING, { .str =
"same" }, .flags = FLAGS },
{ NULL },
};
I'm not sure what to think about a dummy option like this. It might be
very confusing for users to see a format option, which only accepts a
single value, "same", and effectively does nothing.
Not sure I understand the issue. "same" is the default (terminology
borrowed from the scale_npp filter), and it'll assign the format to
whatever is passed in (eg, format=yuv420p assigns that).
Oh, I misread that code as just always throwing an error if it's != "same".
Unfortunately, that option is omitted for a reason.
If you look at scalecuda_resize:
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_scale_cuda.c;h=b7cdb81081ff4a34e7b641c533fc23a5714fed61;hb=HEAD#l380
It has the assumption built into it that the output frame has the same
format as the input frame. So if you were to set format=nv12 and then
input a yuv420p frame, this will most likely crash or at least severely
misbehave.
I would not be opposed to scale_cuda gaining the ability to also change
frame pix_fmts, we are lacking such a filter at the moment if one
ignores scale_npp.
But in its current state, it can't do that.
Not strictly against it, since I can see the convenience it adds when
building command lines, but I'd like some second opinions on this.
Actually I'm using the API, albeit with some of lavfi conveniences to
parse filter strings. This avoids "wiring in" the output format
manually when crossing the lavfi boundary.
Here's a example that demonstrates the issue via CLI (this may
actually be a bug elsewhere?):
Broken:
ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
-an -lavfi scale_cuda=w=426:h=240,hwdownload,format=yuv420p -c:v
libx264 out.ts
Working:
ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
-an -lavfi scale_cuda=w=426:h=240:format=yuv420p,hwdownload,format=yuv420p
-c:v libx264 out.ts
Is this actually working in a sense where the result looks sensible?
Cause with how the code currently is, scale_cuda with format set to
yuv420p and getting nv12 as input from h264_cuvid will produce a frame
labeled as yuv420p but containing nv12 data.
smime.p7s
Description: S/MIME Cryptographic 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] lavfi/vf_scale_cuda: Reset frame size after acquiring from hwframe.
On 24.05.2019 18:39, Josh Allmann wrote: The first frame is scaled correctly, and subsequent frames are over-scaled / cropped since the frame data is reset with the hwframe after each invocation of the scaler. The hwframe-allocated frame has a width/height that is 32-bit aligned. The scaler uses this aligned width / height as its target, leading to "over-scaling" and then cropping of the result. To generate a broken test sample: ffmpeg -hwaccel cuvid -c:v h264_cuvid -i -an \ -lavfi scale_cuda=w=426:h=240 -c:v h264_nvenc --- Tested with NV12 and 420P inputs. Noting that YUV444P seems generally broken - both before/after this patch. libavfilter/vf_scale_cuda.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c index 6b1ef2bb6f..13eb3ad24c 100644 --- a/libavfilter/vf_scale_cuda.c +++ b/libavfilter/vf_scale_cuda.c @@ -489,6 +489,8 @@ static int cudascale_scale(AVFilterContext *ctx, AVFrame *out, AVFrame *in) av_frame_move_ref(out, s->frame); av_frame_move_ref(s->frame, s->tmp_frame); +s->frame->width = s->planes_out[0].width; +s->frame->height= s->planes_out[0].height; ret = av_frame_copy_props(out, in); if (ret < 0) This is certainly correct. The original author of this must have wrongly assumed that av_frame_copy_props takes care of it. Wonder how this was never noticed before. Applied, thanks. smime.p7s Description: S/MIME Cryptographic 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] lavfi/vf_scale_cuda: Reset frame size after acquiring from hwframe.
On 24.05.2019 21:32, Сергей Свечников wrote: Actually, I've submitted the fix a while ago and got ignored. I then wrote to Timo directly to his email and got ignored again. https://github.com/Svechnikov/ffmpeg-scale-cuda-problem I simply missed the original mail to the list, sorry about that. The mail you sent to me directly got caught by Spamassassin due to "Excess base64 in From: field", which it also tagged this mail with, but it coming via this list saved it. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On 27.05.2019 23:49, Lance Wang wrote: On Saturday, May 25, 2019, James Almer wrote: On 5/22/2019 3:59 AM, lance.lmw...@gmail.com wrote: From: Limin Wang The testing command for the HDR10 output with nvenc: $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020 -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \ -master_display "G(13250,34500)B(7500,3000)R( 34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts Please notice it is preferable to use the frame sei side data than master_display and max_cll paramters config --- libavcodec/nvenc.c | 129 libavcodec/nvenc.h | 18 ++ libavcodec/nvenc_hevc.c | 11 3 files changed, 158 insertions(+) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 75dda6d689..3fd0eca4a5 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -22,6 +22,9 @@ #include "config.h" #include "nvenc.h" +#include "cbs_h265.h" This doesn't seem right. The encoder isn't using this framework at all. You're apparently including this only to get the H265RawSEIMasteringDisplayColourVolume and H265RawSEIContentLightLevelInfo structs, which you don't really need to fill sei_data[i].payload OK, I'll remove the dependent for the two structure and update the patch. I'm still not convinced that all this belong in an encoder. Can it really not be made into a filter that adds it as extra data to frames? There got to be other frame consumers that use this kind of data. smime.p7s Description: S/MIME Cryptographic 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/2] lavfi/vf_thumbnail_cuda: fix operator precedence bug
applied smime.p7s Description: S/MIME Cryptographic 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] build: add support for building CUDA files with clang
On 30.07.2019 09:51, Rodger Combs wrote:
This avoids using the CUDA SDK at all; instead, we provide a minimal
reimplementation of the basic functionality that lavfi actually uses.
It generates very similar code to what NVCC produces.
The header contains no implementation code derived from the SDK.
The function and type declarations are derived from the SDK only to the
extent required to build a compatible implementation. This is generally
accepted to qualify as fair use.
Because this option does not require the proprietary SDK, it does not require
the "--enable-nonfree" flag in configure.
---
compat/cuda/cuda_runtime.h | 131 +
configure | 49 +-
ffbuild/common.mak | 3 +-
3 files changed, 166 insertions(+), 17 deletions(-)
create mode 100644 compat/cuda/cuda_runtime.h
diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h
new file mode 100644
index 00..dbe50f8711
--- /dev/null
+++ b/compat/cuda/cuda_runtime.h
@@ -0,0 +1,131 @@
+/*
+ * Minimum CUDA compatibility definitions header
+ *
+ * Copyright (c) 2019 Rodger Combs
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AV_COMPAT_CUDA_CUDA_RUNTIME_H
+#define AV_COMPAT_CUDA_CUDA_RUNTIME_H
+
+// Common macros
+#define __global__ __attribute__((global))
+#define __device__ __attribute__((device))
+#define __device_builtin__ __attribute__((device_builtin))
+#define __align__(N) __attribute__((aligned(N)))
+#define __inline__ __inline__ __attribute__((always_inline))
+
+#define max(a, b) ((a) > (b) ? (a) : (b))
+#define min(a, b) ((a) < (b) ? (a) : (b))
+#define abs(x) ((x) < 0 ? -(x) : (x))
+
+#define atomicAdd(a, b) (__atomic_fetch_add(a, b, __ATOMIC_SEQ_CST))
+
+// Basic typedefs
+typedef __device_builtin__ unsigned long long cudaTextureObject_t;
+
+typedef struct __device_builtin__ __align__(2) uchar2
+{
+unsigned char x, y;
+} uchar2;
+
+typedef struct __device_builtin__ __align__(4) ushort2
+{
+unsigned short x, y;
+} ushort2;
+
+typedef struct __device_builtin__ uint3
+{
+unsigned int x, y, z;
+} uint3;
+
+typedef struct uint3 dim3;
+
+typedef struct __device_builtin__ __align__(8) int2
+{
+int x, y;
+} int2;
+
+typedef struct __device_builtin__ __align__(4) uchar4
+{
+unsigned char x, y, z, w;
+} uchar4;
+
+typedef struct __device_builtin__ __align__(8) ushort4
+{
+unsigned char x, y, z, w;
+} ushort4;
+
+typedef struct __device_builtin__ __align__(16) int4
+{
+int x, y, z, w;
+} int4;
+
+// Accessors for special registers
+#define GETCOMP(reg, comp) \
+asm("mov.u32 %0, %%" #reg "." #comp ";" : "=r"(tmp)); \
+ret.comp = tmp;
+
+#define GET(name, reg) static inline __device__ uint3 name() {\
+uint3 ret; \
+unsigned tmp; \
+GETCOMP(reg, x) \
+GETCOMP(reg, y) \
+GETCOMP(reg, z) \
+return ret; \
+}
+
+GET(getBlockIdx, ctaid)
+GET(getBlockDim, ntid)
+GET(getThreadIdx, tid)
+
+// Instead of externs for these registers, we turn access to them into calls
into trivial ASM
+#define blockIdx (getBlockIdx())
+#define blockDim (getBlockDim())
+#define threadIdx (getThreadIdx())
+
+// Basic initializers (simple macros rather than inline functions)
+#define make_uchar2(a, b) ((uchar2){.x = a, .y = b})
+#define make_ushort2(a, b) ((ushort2){.x = a, .y = b})
+#define make_uchar4(a, b, c, d) ((uchar4){.x = a, .y = b, .z = c, .w = d})
+#define make_ushort4(a, b, c, d) ((ushort4){.x = a, .y = b, .z = c, .w = d})
+
+// Conversions from the tex instruction's 4-register output to various types
+#define TEX2D(type, ret) static inline __device__ void conv(type* out,
unsigned a, unsigned b, unsigned c, unsigned d) {*out = (ret);}
+
+TEX2D(unsigned char, a & 0xFF)
+TEX2D(unsigned short, a & 0x)
+TEX2D(uchar2, make_uchar2(a & 0xFF, b & 0xFF))
+TEX2D(ushort2, make_ushort2(a & 0x, b & 0x))
+TEX2D(uchar4, make_uchar4(a & 0xFF, b & 0xFF, c & 0xFF, d & 0xFF))
+TEX2D(ushort4, make_ushort4(a & 0x, b & 0x, c & 0x, d & 0x))
+
+// Template calling tex instruction and converting the output to the selected
type
+template
+static inline __device__ T tex2D(cudaTextureObject_t texObject, float x, float
y)
+{
+ T ret;
+ unsigned ret1, ret2, ret3, ret4;
+ asm("tex.2d.v4
Re: [FFmpeg-devel] [PATCH] Fixing HW accelerated decoders hanging or throwing error in h263dec
On 02.08.2019 11:18, Stefan Schoenefeld wrote:
Hi all,
Recently we encountered an issue when decoding a h.263 file:
FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out this is not
directly related to NVDEC but is a problem that shows with several other HW
decoders like VDPAU, though the exact kind of error is different (either error
messages or freezing[1]). The root cause is that ff_thread_finish_setup() is
called twice per frame from ff_h263_decode_frame(). This is not supported by
ff_thread_finish_setup() and specifically checked for and warned against in the
functions code. The issue is also specific to hw accelerated decoding only as
the second call to ff_thread_finish_setup() is only issued when hw acceleration
is on. The fix is simple: add a check that the first call is only send when hw
acceleration is off, and the second call only when hw acceleration is on (see
attached patch). This works fine as far as I was able to test with vdpau and
nvdec/nvcuvid hw decoding. The patch also adds NVDEC to the hw config list if
available.
I also noticed a secondary issue when browsing through the code which is that,
according to documentation, ff_thread_finish_setup() should only be called if
the codec implements update_thread_context(), which h263dec does not. The patch
does not address this and I'm not sure any action needs to be taken here at all.
Thanks,
Stefan
[1] This is depending on whether or not the hw decoder sets the
HWACCEL_CAPS_ASYNC_SAFE flag
From 0620ee777a8ba98145bb4781e30a77687c97dbf8 Mon Sep 17 00:00:00 2001
From: Stefan Schoenefeld
Date: Fri, 2 Aug 2019 10:52:22 +0200
Subject: [PATCH] Fixing HW accelerated decoders hanging or throwing error
messages in h263dec
---
libavcodec/h263dec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 6f001f6..8ee844e 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -614,7 +614,7 @@ retry:
if ((ret = ff_mpv_frame_start(s, avctx)) < 0)
return ret;
-if (!s->divx_packed)
+if (!s->divx_packed && !avctx->hwaccel)
ff_thread_finish_setup(avctx);
This seems correct to me, but I'd like another pair of eyes to look over it.
if (avctx->hwaccel) {
@@ -747,6 +747,9 @@ const AVCodecHWConfigInternal *ff_h263_hw_config_list[] = {
#if CONFIG_H263_VAAPI_HWACCEL
HWACCEL_VAAPI(h263),
#endif
+#if CONFIG_MPEG4_NVDEC_HWACCEL
+HWACCEL_NVDEC(mpeg4),
+#endif
Probably cleaner to split this into its own patch, but otherwise OK.
#if CONFIG_MPEG4_VDPAU_HWACCEL
HWACCEL_VDPAU(mpeg4),
#endif
--
2.7.4
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 4.2
On 04.08.2019 07:56, Michael Niedermayer wrote: On Sun, Jul 21, 2019 at 07:11:40PM +0200, Michael Niedermayer wrote: On Mon, May 20, 2019 at 08:39:45PM +0200, Michael Niedermayer wrote: Hi Its quite some time since 4.1 so its probably getting time to branch 4.2. If there are any bugs you want fixed in 4.2 its probably a good idea to fix them soon. Are there any suggestions for a name ? If not ill pick something from unused past suggestions. If there are no objections i will likely make that release in the next weeks 4.2 branch made i intend to make the 4.2 release from HEAD of release/4.2 in the next 1-2 weeks please backport any relevant bugfixes to it. Status update: There are a few remaining crashes / security issues which i think we should fix and include before the release. Iam working on that currently. When thats done depends on 1. any delays (bikesheds, distractions, headaches, good weather that makes me ignore this and go for a walk or maybe going for a walk occasionally actually helps my efficiency who knows, ...) 2. influx of more security reports (fuzzer and any human reports), there where several new reports in the last 2 weeks which fall in the "I think that should be fixed before the release" category 3. murphies law and anything else unexpected Thanks I would kinda like to have the h263 hwaccel fix in for 4.2. It's a one line patch that unbreaks it for all hwaccel backends. smime.p7s Description: S/MIME Cryptographic 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] Fixing HW accelerated decoders hanging or throwing error in h263dec
On 02.08.2019 11:18, Stefan Schoenefeld wrote: Hi all, Recently we encountered an issue when decoding a h.263 file: FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out this is not directly related to NVDEC but is a problem that shows with several other HW decoders like VDPAU, though the exact kind of error is different (either error messages or freezing[1]). The root cause is that ff_thread_finish_setup() is called twice per frame from ff_h263_decode_frame(). This is not supported by ff_thread_finish_setup() and specifically checked for and warned against in the functions code. The issue is also specific to hw accelerated decoding only as the second call to ff_thread_finish_setup() is only issued when hw acceleration is on. The fix is simple: add a check that the first call is only send when hw acceleration is off, and the second call only when hw acceleration is on (see attached patch). This works fine as far as I was able to test with vdpau and nvdec/nvcuvid hw decoding. The patch also adds NVDEC to the hw config list if available. I also noticed a secondary issue when browsing through the code which is that, according to documentation, ff_thread_finish_setup() should only be called if the codec implements update_thread_context(), which h263dec does not. The patch does not address this and I'm not sure any action needs to be taken here at all. Thanks, Stefan [1] This is depending on whether or not the hw decoder sets the HWACCEL_CAPS_ASYNC_SAFE flag Split in two, applied and backported to relevant branches. smime.p7s Description: S/MIME Cryptographic 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] build: add support for building CUDA files with clang
On 30.07.2019 09:51, Rodger Combs wrote: This avoids using the CUDA SDK at all; instead, we provide a minimal reimplementation of the basic functionality that lavfi actually uses. It generates very similar code to what NVCC produces. The header contains no implementation code derived from the SDK. The function and type declarations are derived from the SDK only to the extent required to build a compatible implementation. This is generally accepted to qualify as fair use. Because this option does not require the proprietary SDK, it does not require the "--enable-nonfree" flag in configure. Changed configure logic to autodetect cuda-llvm and applied. smime.p7s Description: S/MIME Cryptographic 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] fate: Add cuda_runtime.h to FATE source test ref file
On 04.08.2019 23:52, Andreas Rheinhardt wrote: It uses a nonstandard inclusion guard. Is there any problem with just fixing the inclusion guard instead? I forgot that this exists, but the inclusion guard in it looked fairly standard to me. Feel free to just fix it. smime.p7s Description: S/MIME Cryptographic 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] compat/cuda: Change inclusion guards
On 05/08/2019 03:09, Andreas Rheinhardt wrote: cuda_runtime.h as well as dynlink_loader.h used nonstandard inclusion guards with an AV_ prefix, although these files are not in an libav*/ path. So change the inclusion guards and adapt the ref file of the source fate test accordingly. Signed-off-by: Andreas Rheinhardt applied. Thanks! smime.p7s Description: S/MIME Cryptographic 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: cuda_llvm: fix include path for MSYS2
On 05.08.2019 21:47, Ricardo Constantino wrote:
MSYS2 converts paths to MinGW-based applications from unix to
pseudo-windows paths on execution time.
Since there was no space between '-include' and the path, MSYS2 doesn't
detect the path properly.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index bddc05b850..34c2adb4a4 100755
--- a/configure
+++ b/configure
@@ -6094,7 +6094,7 @@ fi
if enabled cuda_nvcc; then
nvccflags="$nvccflags -ptx"
else
-nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only
-include${source_link}/compat/cuda/cuda_runtime.h"
+nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only -include
${source_link}/compat/cuda/cuda_runtime.h"
check_nvcc cuda_llvm
fi
Are you sure this is necessary? source_link only ever points to either .
or src, and I don't see why msys2 would need to fix that, since it's a
relative path.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavcodec/amfenc: Vulkan initialization support for encoder.
On 08/08/2019 20:33, OvchinnikovDmitrii wrote: Added linux support for amf encoder through vulkan. To use h.264(AMD VCE) encoder on linux amdgru-pro version 19.20+ and amf-amdgpu-pro package(amdgru-pro contains, but does not install automatically) are required. This driver can be installed using amdgpu-pro-install script in official amd driver archive. Initialization of amf encoder occurs in this order: 1) trying to initialize through dx11(only windows) 2) trying to initialize through dx9(only windows) 3) trying to initialize through vulkan Only Vulkan initialization available on linux. Is it possible to use Vulkan on Windows? For Interop with OpenCL and the like that could come very handy. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavcodec/amfenc: Vulkan initialization support for encoder.
On 12/08/2019 12:35, Дмитрий Овчинников wrote: Yes, it is possible, but it is required to implement separate patch with selector dx9, dx11, vulkan. We could do it when this one is committed. I will double check with opencl interop and will comeback. There is no standardized OpenCL/Vulkan Interop as of now, but there are working group for it and it's probably gonna happen sooner or later, so it'd be nice to be prepared. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/utils: document allocation requirement of extradata
---
libavcodec/avcodec.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 31e50d5a94..5ec7a2430b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1616,6 +1616,7 @@ typedef struct AVCodecContext {
* The allocated memory should be AV_INPUT_BUFFER_PADDING_SIZE bytes larger
* than extradata_size to avoid problems if it is read with the bitstream
reader.
* The bytewise contents of extradata must not depend on the architecture
or CPU endianness.
+ * Must be allocated with av_malloc() in any case.
* - encoding: Set/allocated/freed by libavcodec.
* - decoding: Set/allocated/freed by user.
*/
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
