[FFmpeg-devel] [PATCH v1] fate/imfdec: add audio test
From: Pierre-Anthony Lemieux Adds an audio test for the IMF demuxer. FATE content at https://www.sandflow.com/public/countdown-audio.zip --- tests/fate/imf.mak| 3 + tests/ref/fate/imf-cpl-with-audio | 207 ++ 2 files changed, 210 insertions(+) create mode 100644 tests/ref/fate/imf-cpl-with-audio diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak index feb54d1361..49ab35e7d9 100644 --- a/tests/fate/imf.mak +++ b/tests/fate/imf.mak @@ -1,6 +1,9 @@ FATE_IMF += fate-imf-cpl-with-repeat fate-imf-cpl-with-repeat: CMD = framecrc -f imf -i $(TARGET_SAMPLES)/imf/countdown/CPL_bb2ce11c-1bb6-4781-8e69-967183d02b9b.xml -c:v copy +FATE_IMF += fate-imf-cpl-with-audio +fate-imf-cpl-with-audio: CMD = framecrc -f imf -i $(TARGET_SAMPLES)/imf/countdown-audio/CPL_688f4f63-a317-4271-99bf-51444ff39c5b.xml -c:a copy + FATE_SAMPLES_FFMPEG-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF) fate-imfdec: $(FATE_IMF) diff --git a/tests/ref/fate/imf-cpl-with-audio b/tests/ref/fate/imf-cpl-with-audio new file mode 100644 index 00..0a1d87631a --- /dev/null +++ b/tests/ref/fate/imf-cpl-with-audio @@ -0,0 +1,207 @@ +#tb 0: 1/24 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 640x360 +#sar 0: 0/1 +#tb 1: 1/48000 +#media_type 1: audio +#codec_id 1: pcm_s24le +#sample_rate 1: 48000 +#channel_layout_name 1: stereo +0, 0, 0,1, 1382400, 0x6a2c410c +1, 0, 0, 1920,11520, 0x974f4bab +1, 1920, 1920, 1920,11520, 0xdf793f69 +0, 1, 1,1, 1382400, 0x5f0c67d2 +1, 3840, 3840, 1920,11520, 0xfd69559a +0, 2, 2,1, 1382400, 0x408e1262 +1, 5760, 5760, 1920,11520, 0x28fa469b +0, 3, 3,1, 1382400, 0x3567d455 +1, 7680, 7680, 1920,11520, 0xe49161cf +0, 4, 4,1, 1382400, 0x2312e68b +1, 9600, 9600, 1920,11520, 0xb92c49ae +0, 5, 5,1, 1382400, 0xe3d84ec2 +1, 11520, 11520, 1920,11520, 0xd2b75d46 +0, 6, 6,1, 1382400, 0xdbb3ab8c +1, 13440, 13440, 1920,11520, 0xa13b5a9b +0, 7, 7,1, 1382400, 0xeb250513 +1, 15360, 15360, 1920,11520, 0xfe804299 +0, 8, 8,1, 1382400, 0x26c3c8c0 +1, 17280, 17280, 1920,11520, 0x7a8654d4 +0, 9, 9,1, 1382400, 0xbc41a23e +1, 19200, 19200, 1920,11520, 0x1a2e48a4 +0, 10, 10,1, 1382400, 0x49d6a8de +1, 21120, 21120, 1920,11520, 0x20504669 +0, 11, 11,1, 1382400, 0x5e05cfa4 +1, 23040, 23040, 960, 5760, 0x74bf38f6 +0, 12, 12,1, 1382400, 0x01327a34 +1, 24000, 24000, 1920,11520, 0x974f4bab +1, 25920, 25920, 1920,11520, 0xdf793f69 +0, 13, 13,1, 1382400, 0x06ce3c36 +1, 27840, 27840, 1920,11520, 0xfd69559a +0, 14, 14,1, 1382400, 0x6aa24e6c +1, 29760, 29760, 1920,11520, 0x28fa469b +0, 15, 15,1, 1382400, 0x55d8b694 +1, 31680, 31680, 1920,11520, 0xe49161cf +0, 16, 16,1, 1382400, 0xcc6f136d +1, 33600, 33600, 1920,11520, 0xb92c49ae +0, 17, 17,1, 1382400, 0xe92b6ce5 +1, 35520, 35520, 1920,11520, 0xd2b75d46 +0, 18, 18,1, 1382400, 0x664d30a1 +1, 37440, 37440, 1920,11520, 0xa13b5a9b +0, 19, 19,1, 1382400, 0x09d80a1f +1, 39360, 39360, 1920,11520, 0xfe804299 +0, 20, 20,1, 1382400, 0x2b58536e +1, 41280, 41280, 1920,11520, 0x7a8654d4 +0, 21, 21,1, 1382400, 0xf24b7a34 +1, 43200, 43200, 1920,11520, 0x1a2e48a4 +0, 22, 22,1, 1382400, 0xe2a524c4 +1, 45120, 45120, 1920,11520, 0x20504669 +0, 23, 23,1, 1382400, 0xe841e6b7 +1, 47040, 47040, 1920,11520, 0x7ad44ba6 +0, 24, 24,1, 1382400, 0x6a2c410c +1, 48960, 48960, 1920,11520, 0xc8934994 +0, 25, 25,1, 1382400, 0x5f0c67d2 +1, 50880, 50880, 1920,11520, 0x07ad70bb +0, 26, 26,1, 1382400, 0x408e1262 +1, 52800, 52800, 1920,11520, 0x1ba75d9a +0, 27, 27,1, 1382400, 0x3567d455 +1, 54720, 54720, 1920,11520, 0x0d4a435f +0, 28, 28,1, 1382400, 0x2312e68b +1, 56640, 56640, 1920,11520, 0x288b6c85 +0, 29, 29,1, 1382400, 0xe3d84ec2 +1, 58560,
Re: [FFmpeg-devel] Would a crypto file be acceptable?
On Thu, Dec 29, 2022 at 03:51:24PM +0100, Mark Gaiser wrote: > On Wed, Dec 28, 2022 at 10:02 PM Michael Niedermayer > wrote: > > > Hi > > > > On Tue, Dec 27, 2022 at 11:46:38PM +0100, Mark Gaiser wrote: > > > On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer < > > mich...@niedermayer.cc> > > > wrote: > > > > > > > On Wed, Dec 21, 2022 at 04:44:59PM +0100, Mark Gaiser wrote: > > > > > Hi, > > > > > > > > > > The ffmpeg crypto protocol handler [1] allows one to play encrypted > > > > media. > > > > > > > > > > The great thing here is that it allows playback of any media format > > that > > > > > ffmpeg supports! > > > > > Have a container format like mkv as an encrypted blob, no problem > > for the > > > > > crypto plugin! > > > > > > > > > > I'm explicitly mentioning mkv (though there's many more) here because > > > > that > > > > > isn't possible in HLS/MPD. While those streaming formats handle > > > > encryption > > > > > too, they are very limited in terms of supported codecs and > > containers. > > > > > > > > > > Playback of encrypted data works like this: > > > > > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV > > > > > > > > > > While this works just fine, it's limited in use because the > > cryptography > > > > > details have to be passed on the command line. Applications that > > might > > > > well > > > > > support much of ffmpeg functionality can't easily hook into the > > crypto > > > > > functionality. Take KODI for example, it allows playback of many of > > the > > > > > formats ffmpeg supports but anything with crypto just isn't > > possible. In > > > > > fact, anything that requires custom command line arguments isn't > > > > possible. > > > > > [2] > > > > > > > > > > My idea is to make a new file format that would be implemented and > > > > specced > > > > > within [1]. My proposed format would be: > > > > > > > > > > --- > > > > > CRYPTO-VERSION:1 > > > > > CRYPTO-KEY:URI:. > > > > > CRYPTO-IV:URI:. > > > > > encrypted_file > > > > > --- > > > > > > > > > > The URI would be a format type identifier where you can choose > > between > > > > URI > > > > > (to pass a URL to a key blob), BASE64URL (key encoded as base64url) > > or > > > > HEX. > > > > > > > > > > The above proposed format should be stored in a file with ".crypto" > > as > > > > > extension. The crypto plugin [1] would then handle that file. The > > > > arguments > > > > > would be filled based on the "properties" in the file. So for > > example the > > > > > `decryption_key` argument would be populated with the blob returned > > from > > > > > CRYPTO-KEY:URI:. Or with one of the other types. > > > > > > > > > > The "encrypted_file" would just be passed through ffmpeg's > > > > > "ffurl_open_whitelist" like the crypto plugin currently does. Meaning > > > > that > > > > > the file could be anything ffmpeg supports. > > > > > > > > > > Playing encrypted media would be as simple as: > > > > > ffplay file.crypto > > > > > > > > > > With this mail I'm looking for a confirmation if the above concept > > would > > > > be > > > > > allowed as a patch for ffmpeg? And if not, how can I achieve the same > > > > > results in a way that would be acceptable? [3] > > > > > > > > I understand what you are trying to do but not what the use case for > > this > > > > is ? > > > > > > > > Encryption has the goal to let one party access data and not another. > > > > Who are these 2 parties and where does the encrypted media come from? > > > > > > > > You mention decentralization, I see nothing related to decentralization > > > > in this. Or do you suggest that, everytime someone succeeds decrypting > > a > > > > file its key would be automatically be published in a decentralized > > > > public database, so teh next user can safe herself teh troubble from > > > > finding the key? > > > > > > > > If not iam confused why you store keys plainly in files, because this > > is > > > > not very secure, so maybe the goal never is to keep the key safe ? > > > > Or it doesnt matter that someone with physical access in the future > > would > > > > also possibly have access to the key. Again you didnt explain the use > > case > > > > and who the intended user and adversery is ... > > > > > > > > > > How do you privately want to share a video with someone else? Say A (you) > > > and B (the other) > > > Currently you probably use one of the following options or something > > > similar: > > > - A uploads it you youtube as unlisted and share that link with B > > > - A adds it to google photos/drive and share that link B > > > - A adds it to cloud storage and shares that link with B > > > etc.. > > > > I would encrypt it with gpg with Bs public key then send it to B by a > > secure way, the way depends on what i know of from B > > * physically give him a usb stick or send that by snail mail > > * upload it somewhere through tor browser, B then could download it too > > using tor browser. > > > > If the material is of value to
[FFmpeg-devel] [PATCH] vaapi_encode_h264: Only set pic_order_cnt_type to 0 with B-frames
--- libavcodec/vaapi_encode_h264.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c index dd17be2..d6926c4 100644 --- a/libavcodec/vaapi_encode_h264.c +++ b/libavcodec/vaapi_encode_h264.c @@ -350,7 +350,7 @@ static int vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx) sps->chroma_format_idc= 1; sps->log2_max_frame_num_minus4 = 4; -sps->pic_order_cnt_type= 0; +sps->pic_order_cnt_type= ctx->max_b_depth ? 0 : 2; sps->log2_max_pic_order_cnt_lsb_minus4 = 4; sps->max_num_ref_frames = priv->dpb_frames; -- 2.39.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat: Add support for embedding cover art in Ogg files
It's done similarly to how the flac muxer does it, so I reused most of the code
and adapted it.
Signed-off-by: Zsolt Vadasz
---
libavformat/oggenc.c | 293 +--
1 file changed, 254 insertions(+), 39 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index 5003314adb..bfc51628f2 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -23,14 +23,22 @@
#include
+#include "libavcodec/codec_id.h"
+#include "libavutil/avutil.h"
#include "libavutil/crc.h"
+#include "libavutil/log.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
#include "libavutil/random_seed.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/avstring.h"
+#include "libavutil/base64.h"
+#include "libavutil/bswap.h"
#include "libavcodec/xiph.h"
#include "libavcodec/bytestream.h"
#include "libavcodec/flac.h"
#include "avformat.h"
+#include "id3v2.h"
#include "avio_internal.h"
#include "internal.h"
#include "version.h"
@@ -77,6 +85,10 @@ typedef struct OGGContext {
int pref_size; ///< preferred page size (0 => fill all segments)
int64_t pref_duration; ///< preferred page duration (0 => fill all
segments)
int serial_offset;
+
+PacketList queue;
+int audio_stream_idx;
+int attached_pics;
} OGGContext;
#define OFFSET(x) offsetof(OGGContext, x)
@@ -468,12 +480,107 @@ static void ogg_write_pages(AVFormatContext *s, int
flush)
ogg->page_list = p;
}
-static int ogg_init(AVFormatContext *s)
+static int ogg_attach_pic_to_metadata(AVFormatContext *s, AVPacket *pkt)
+{
+OGGContext *c = s->priv_data;
+const AVPixFmtDescriptor *pixdesc;
+const CodecMime *mime = ff_id3v2_mime_tags;
+AVDictionaryEntry *e;
+const char *mimetype = NULL, *desc = "";
+const AVStream *st = s->streams[pkt->stream_index];
+AVStream *audio_stream = s->streams[c->audio_stream_idx];
+unsigned int i, mimelen, desclen, type = 0, blocklen;
+uint8_t *ptr, *metadata_block_picture = NULL;
+int encoded_len, ret;
+char *encoded;
+
+if (!pkt->data)
+return 0;
+
+while (mime->id != AV_CODEC_ID_NONE) {
+if (mime->id == st->codecpar->codec_id) {
+mimetype = mime->str;
+break;
+}
+mime++;
+}
+if (!mimetype) {
+av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d, cannot "
+ "write an attached picture.\n", st->index);
+return AVERROR(EINVAL);
+}
+mimelen = strlen(mimetype);
+
+/* get the picture type */
+e = av_dict_get(st->metadata, "comment", NULL, 0);
+for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
+if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
+type = i;
+break;
+}
+}
+
+if (type == 1 && (st->codecpar->codec_id != AV_CODEC_ID_PNG ||
+ st->codecpar->width != 32 ||
+ st->codecpar->height != 32)) {
+av_log(s, AV_LOG_ERROR, "File icon attachment must be a 32x32 PNG");
+return AVERROR(EINVAL);
+}
+
+/* get the description */
+if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
+desc = e->value;
+desclen = strlen(desc);
+
+blocklen = 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 + pkt->size;
+if (blocklen >= 1<<24) {
+av_log(s, AV_LOG_ERROR, "Picture block too big %d >= %d\n", blocklen,
1<<24);
+return AVERROR(EINVAL);
+}
+
+metadata_block_picture = av_mallocz(blocklen);
+ptr = metadata_block_picture;
+bytestream_put_be32(, type);
+
+bytestream_put_be32(, mimelen);
+bytestream_put_buffer(, mimetype, mimelen);
+
+bytestream_put_be32(, desclen);
+bytestream_put_buffer(, desc, desclen);
+
+bytestream_put_be32(, st->codecpar->width);
+bytestream_put_be32(, st->codecpar->height);
+if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
+bytestream_put_be32(, av_get_bits_per_pixel(pixdesc));
+else
+bytestream_put_be32(, 0);
+bytestream_put_be32(, 0);
+
+bytestream_put_be32(, pkt->size);
+bytestream_put_buffer(, pkt->data, pkt->size);
+
+encoded_len = AV_BASE64_SIZE(blocklen);
+encoded = av_mallocz(encoded_len);
+av_base64_encode(encoded, encoded_len, metadata_block_picture, blocklen);
+av_free(metadata_block_picture);
+
+ret = av_dict_set(_stream->metadata, "METADATA_BLOCK_PICTURE",
encoded, 0);
+av_free(encoded);
+av_packet_unref(pkt);
+
+if (ret < 0)
+return ret;
+return 0;
+}
+
+static int ogg_finish_init(AVFormatContext *s)
{
OGGContext *ogg = s->priv_data;
OGGStreamContext *oggstream = NULL;
int i, j;
+ogg->attached_pics = 0;
+
if (ogg->pref_size)
av_log(s, AV_LOG_WARNING, "The pagesize option is deprecated\n");
@@ -481,29 +588,6 @@ static int ogg_init(AVFormatContext *s)
AVStream *st = s->streams[i];
unsigned
[FFmpeg-devel] Late SEI is not implemented (providing a sample)
Dear all, While updating Kodi to use the ffmpeg provided A53 side data for closed captions instead of our custom (old) demuxer (c.f. https://github.com/xbmc/xbmc/pull/22333) and running it against a battery of test samples I've found the following messages in the log for one particular sample: [ffmpeg/video] h264: Late SEI 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. [ffmpeg/video] h264: 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) This happens with ffmpeg version 5.1.2 and current master. To reproduce the problem you can simply open it with ffplay: ffplay https://livesim.dashif.org/dash/vod/testpic_2s/cea608.mpd The sample in question has two closed caption streams, although in ffmpeg none is detected/demuxed (a53 side data is empty). You can validate the proper behavior using dash.js for example: https://players.akamai.com/players/dashjs?streamUrl=https%3A%2F%2Flivesim.dashif.org%2Fdash%2Fvod%2Ftestpic_2s%2Fcea608.mpd Hope you find this helpful, Best regards, Miguel ___ 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] Would a crypto file be acceptable?
On Wed, Dec 28, 2022 at 10:02 PM Michael Niedermayer wrote: > Hi > > On Tue, Dec 27, 2022 at 11:46:38PM +0100, Mark Gaiser wrote: > > On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Wed, Dec 21, 2022 at 04:44:59PM +0100, Mark Gaiser wrote: > > > > Hi, > > > > > > > > The ffmpeg crypto protocol handler [1] allows one to play encrypted > > > media. > > > > > > > > The great thing here is that it allows playback of any media format > that > > > > ffmpeg supports! > > > > Have a container format like mkv as an encrypted blob, no problem > for the > > > > crypto plugin! > > > > > > > > I'm explicitly mentioning mkv (though there's many more) here because > > > that > > > > isn't possible in HLS/MPD. While those streaming formats handle > > > encryption > > > > too, they are very limited in terms of supported codecs and > containers. > > > > > > > > Playback of encrypted data works like this: > > > > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV > > > > > > > > While this works just fine, it's limited in use because the > cryptography > > > > details have to be passed on the command line. Applications that > might > > > well > > > > support much of ffmpeg functionality can't easily hook into the > crypto > > > > functionality. Take KODI for example, it allows playback of many of > the > > > > formats ffmpeg supports but anything with crypto just isn't > possible. In > > > > fact, anything that requires custom command line arguments isn't > > > possible. > > > > [2] > > > > > > > > My idea is to make a new file format that would be implemented and > > > specced > > > > within [1]. My proposed format would be: > > > > > > > > --- > > > > CRYPTO-VERSION:1 > > > > CRYPTO-KEY:URI:. > > > > CRYPTO-IV:URI:. > > > > encrypted_file > > > > --- > > > > > > > > The URI would be a format type identifier where you can choose > between > > > URI > > > > (to pass a URL to a key blob), BASE64URL (key encoded as base64url) > or > > > HEX. > > > > > > > > The above proposed format should be stored in a file with ".crypto" > as > > > > extension. The crypto plugin [1] would then handle that file. The > > > arguments > > > > would be filled based on the "properties" in the file. So for > example the > > > > `decryption_key` argument would be populated with the blob returned > from > > > > CRYPTO-KEY:URI:. Or with one of the other types. > > > > > > > > The "encrypted_file" would just be passed through ffmpeg's > > > > "ffurl_open_whitelist" like the crypto plugin currently does. Meaning > > > that > > > > the file could be anything ffmpeg supports. > > > > > > > > Playing encrypted media would be as simple as: > > > > ffplay file.crypto > > > > > > > > With this mail I'm looking for a confirmation if the above concept > would > > > be > > > > allowed as a patch for ffmpeg? And if not, how can I achieve the same > > > > results in a way that would be acceptable? [3] > > > > > > I understand what you are trying to do but not what the use case for > this > > > is ? > > > > > > Encryption has the goal to let one party access data and not another. > > > Who are these 2 parties and where does the encrypted media come from? > > > > > > You mention decentralization, I see nothing related to decentralization > > > in this. Or do you suggest that, everytime someone succeeds decrypting > a > > > file its key would be automatically be published in a decentralized > > > public database, so teh next user can safe herself teh troubble from > > > finding the key? > > > > > > If not iam confused why you store keys plainly in files, because this > is > > > not very secure, so maybe the goal never is to keep the key safe ? > > > Or it doesnt matter that someone with physical access in the future > would > > > also possibly have access to the key. Again you didnt explain the use > case > > > and who the intended user and adversery is ... > > > > > > > How do you privately want to share a video with someone else? Say A (you) > > and B (the other) > > Currently you probably use one of the following options or something > > similar: > > - A uploads it you youtube as unlisted and share that link with B > > - A adds it to google photos/drive and share that link B > > - A adds it to cloud storage and shares that link with B > > etc.. > > I would encrypt it with gpg with Bs public key then send it to B by a > secure way, the way depends on what i know of from B > * physically give him a usb stick or send that by snail mail > * upload it somewhere through tor browser, B then could download it too > using tor browser. > > If the material is of value to some state actor (hello CIA/NSA/FSB/Mosad) > then additional precautions are probably a good idea. (seperate computers, > use of > internet connections not associated with either A or B and so forth) ive > not yet > had the need to do this so i have not really thought about it > > I somewhat avoid all these "paid by
Re: [FFmpeg-devel] Would a crypto file be acceptable?
Hi, On Wed, Dec 28, 2022 at 11:14 AM Mark Gaiser wrote: > On Wed, Dec 28, 2022 at 3:27 PM Ronald S. Bultje > wrote: > > > Hi Mark, > > > > On Tue, Dec 27, 2022 at 5:47 PM Mark Gaiser wrote: > > > > > The tricky part here is for anyone using this scheme to play this file. > > > Right now i'm doing this with a command line like: > > > ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv > > > $AES_IV > > > > > > For brevity's sake, consider the "metadata" file named above to be the > > > _encrypted_ version of the ".crypto" file i'm proposing. > > > [..] > > > > > There's many ways to do this key part. My intention for now was to keep > it > > > "simple" and have the key in the file itself. > > > > > > > There's multiple things going on here, and you're sort of putting them > all > > together to solve all problems at once: > > - a mechanism for crypto-data exchange in your application or > server/client > > protocol > > - a way for your application to pass the crypto-data to the underlying > > library > > > > I think once you split these out as separate entities, you'll see that > you > > don't necessarily need the same solution for it. The second one, in > > particular, is already solved in FFmpeg, and this is called an AVOption. > > (And the first question is really out of FFmpeg scope anyway.) Have you > > considered simply using AVOption, and/or is there a reason AVOption > isn't a > > suitable solution for your use case? > > > > Hi Roland, > > There's definitely multiple things going on but it's not what you > summarize. > > 1. DEV (me) goes to the mailing list to propose a new feature. Dev tries to > be concise and to the point to not litter the request with irrelevant side > details. > 2. MU (mailing list user) is skeptical and needs more context - which is > great! > 3. DEV gives more context > 4. MU now discusses irrelevant side-details that DEV tried to prevent in > the initial post - this is where things go wrong > 5. Topic is now derailed with side suggestions that have nothing todo with > the initial proposal. Feature potentially never gets built. > > Point 5 is where we're roughly at right now. I will make this feature > because I need to have it for my own project. > > I'm fine discussing the proposed format further. > I know _exactly_ what i want to do. > But why? This is not a format. It's not a container, or a playlist. It's an artificial key/value exchange protocol created just for you. That's even the specific purpose of this format: it has no other purpose than to circumvent AVOption because it's ... complicated? I really don't understand why this is preferable over AVOption. Yet, you refuse to discuss this. And aside: the "DEV" and "MU" people in your story are much more than a fabulous white hat hacker vs. internet troll which you make it out to be (in what order?). Don't forget "MU" carries the long-term maintenance burden. This is not derailing; this is called design review. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/segment: add option min_seg_duration
On 2022-12-28 09:26 am, Gyan Doshi wrote:
Plan to push tomorrow.
Pushed as d39b34123daadce3c7db2851120cf10b4c3511db with a small change
to ensure this is limited to segment_time.
On 2022-12-25 11:54 pm, Gyan Doshi wrote:
On 2022-12-21 09:08 pm, Gyan Doshi wrote:
New option can be used to avoid creating very short segments with
inputs
whose GOP size is variable or unharmonic with segment_time.
Only effective with segment_time.
Comments?
---
doc/muxers.texi | 5 +
libavformat/segment.c | 12 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 4edbb22b00..ed5341be39 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2369,6 +2369,11 @@ Note that splitting may not be accurate,
unless you force the
reference stream key-frames at the given time. See the introductory
notice and the examples below.
+@item min_seg_duration @var{time}
+Set minimum segment duration to @var{time}, the value must be a
duration
+specification. This prevents the muxer ending segments at a
duration below
+this value. Only effective with @code{segment_time}. Default value
is "0".
+
@item segment_atclocktime @var{1|0}
If set to "1" split at regular clock time intervals starting from
00:00
o'clock. The @var{time} value specified in @option{segment_time} is
diff --git a/libavformat/segment.c b/libavformat/segment.c
index c904e20708..c19c2a94ae 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -93,6 +93,7 @@ typedef struct SegmentContext {
int list_type; ///< set the list type
AVIOContext *list_pb; ///< list file put-byte context
int64_t time; ///< segment duration
+ int64_t min_seg_duration; ///< minimum segment duration
int use_strftime; ///< flag to expand filename with strftime
int increment_tc; ///< flag to increment timecode if found
@@ -710,6 +711,10 @@ static int seg_init(AVFormatContext *s)
}
seg->clocktime_offset = seg->time -
(seg->clocktime_offset % seg->time);
}
+ if (seg->min_seg_duration > seg->time) {
+ av_log(s, AV_LOG_ERROR, "min_seg_duration cannot be
greater than segment_time\n");
+ return AVERROR(EINVAL);
+ }
}
if (seg->list) {
@@ -839,7 +844,7 @@ static int seg_write_packet(AVFormatContext *s,
AVPacket *pkt)
{
SegmentContext *seg = s->priv_data;
AVStream *st = s->streams[pkt->stream_index];
- int64_t end_pts = INT64_MAX, offset;
+ int64_t end_pts = INT64_MAX, offset, pkt_pts_avtb;
int start_frame = INT_MAX;
int ret;
struct tm ti;
@@ -890,11 +895,15 @@ calc_times:
pkt->flags & AV_PKT_FLAG_KEY,
pkt->stream_index == seg->reference_stream_index ?
seg->frame_count : -1);
+ if (pkt->pts != AV_NOPTS_VALUE)
+ pkt_pts_avtb = av_rescale_q(pkt->pts, st->time_base,
AV_TIME_BASE_Q);
+
if (pkt->stream_index == seg->reference_stream_index &&
(pkt->flags & AV_PKT_FLAG_KEY || seg->break_non_keyframes) &&
(seg->segment_frame_count > 0 || seg->write_empty) &&
(seg->cut_pending || seg->frame_count >= start_frame ||
(pkt->pts != AV_NOPTS_VALUE &&
+ pkt_pts_avtb - seg->cur_entry.start_pts >=
seg->min_seg_duration &&
av_compare_ts(pkt->pts, st->time_base,
end_pts - seg->time_delta, AV_TIME_BASE_Q)
>= 0))) {
/* sanitize end time in case last packet didn't have a
defined duration */
@@ -1031,6 +1040,7 @@ static const AVOption options[] = {
{ "segment_clocktime_wrap_duration", "set segment clocktime
wrapping duration", OFFSET(clocktime_wrap_duration),
AV_OPT_TYPE_DURATION, {.i64 = INT64_MAX}, 0, INT64_MAX, E},
{ "segment_time", "set segment duration",
OFFSET(time),AV_OPT_TYPE_DURATION, {.i64 = 200}, INT64_MIN,
INT64_MAX, E },
{ "segment_time_delta","set approximation value used for the
segment times", OFFSET(time_delta), AV_OPT_TYPE_DURATION, {.i64 =
0}, 0, INT64_MAX, E },
+ { "min_seg_duration", "set minimum segment
duration", OFFSET(min_seg_duration),
AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX, E },
{ "segment_times", "set segment split time points",
OFFSET(times_str),AV_OPT_TYPE_STRING,{.str = NULL}, 0, 0, E },
{ "segment_frames", "set segment split frame numbers",
OFFSET(frames_str),AV_OPT_TYPE_STRING,{.str = NULL}, 0, 0, E },
{ "segment_wrap", "set number after which the index
wraps", OFFSET(segment_idx_wrap), AV_OPT_TYPE_INT, {.i64 = 0},
0, INT_MAX, E },
___
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] libavformat/rtspdec.c: flush pes buffer while rtsp seek
>> On Dec 29, 2022, at 11:43, tanwei (D) wrote:
>>
+if (rt->cur_transport_priv && rt->transport ==
+ RTSP_TRANSPORT_RTP) {
+ff_rtp_seek_flush(rt->cur_transport_priv);
+} else if (CONFIG_RTPDEC && rt->ts) {
+av_freep(>recvbuf);
>>
>>> Is it necessary to free rt->recvbuf?
>> The recvbuf must be released. Otherwise, data before seek may be read in the
>> RTSP+TS scenario.
>
>Read from recvbuf with recvbuf_len = 0 ? How is it possible?
I checked the code again, and you're right. The recvbuf does not need to be
free.
The new modification is to set cur_transport_priv to NULL. I have fixed the
previous review comments.
Please review the attached patch again. Thank you.
+rt->recvbuf_pos = 0;
+rt->recvbuf_len = 0;
+ff_mpegts_seek_flush(rt->ts);
+}>
>
> -邮件原件-
> 发件人: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] 代表 "zhilizhao(赵志立)"
> 发送时间: 2022年12月23日 10:34
> 收件人: FFmpeg development discussions and patches
>
> 抄送: Wujian(Chin) ; Lingzezhi
>
> 主题: Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec.c: flush pes buffer
> while rtsp seek
>
>
>
>> On Dec 22, 2022, at 11:32, tanwei (D) wrote:
>>
>> Fixes ticket #9949.
>>
>>
>> Signed-off-by: t00660896
>>
>> ---
>>
>> libavformat/mpegts.c| 20
>>
>> libavformat/mpegts.h| 1 +
>>
>> libavformat/rtpdec.c| 7 +++
>>
>> libavformat/rtpdec.h| 2 ++
>>
>> libavformat/rtpdec_mpegts.c | 11 +++
>>
>> libavformat/rtspdec.c | 11 +++
>>
>> 6 files changed, 52 insertions(+)
>>
>>
>
> Please check the patch format (a lot of empty lines).
>
>> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>>
>> index d97702fcd7..c82971af87 100644
>>
>> --- a/libavformat/mpegts.c
>>
>> +++ b/libavformat/mpegts.c
>>
>> @@ -3419,6 +3419,26 @@ int avpriv_mpegts_parse_packet(MpegTSContext
>> *ts, AVPacket *pkt,
>>
>>return len1 - len;
>>
>> }
>>
>> +void ff_mpegts_seek_flush(MpegTSContext *ts)
>>
>> +{
>>
>> +int i;
>>
>> +/* flush pes buffer */
>>
>> +for (i = 0; i < NB_PID_MAX; i++) {
>>
>> +if (ts->pids[i]) {
>>
>> +if (ts->pids[i]->type == MPEGTS_PES) {
>>
>> +PESContext *pes = ts->pids[i]->u.pes_filter.opaque;
>>
>> +av_buffer_unref(>buffer);
>>
>> +pes->data_index = 0;
>>
>> +pes->state = MPEGTS_SKIP; /* skip until pes header
>> + */
>>
>> +} else if (ts->pids[i]->type == MPEGTS_SECTION) {
>>
>> +ts->pids[i]->u.section_filter.last_ver = -1;
>>
>> +}
>>
>> +ts->pids[i]->last_cc = -1;
>>
>> +ts->pids[i]->last_pcr = -1;
>>
>> +}
>>
>> +}
>>
>> +}
>>
>> +
>
> Please don’t just duplicate the source code.
>
>>
>> void avpriv_mpegts_parse_close(MpegTSContext *ts)
>>
>> {
>>
>>mpegts_free(ts);
>>
>> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
>>
>> index a48f14e768..ea6b5106a4 100644
>>
>> --- a/libavformat/mpegts.h
>>
>> +++ b/libavformat/mpegts.h
>>
>> @@ -170,6 +170,7 @@ MpegTSContext
>> *avpriv_mpegts_parse_open(AVFormatContext *s);
>>
>> int avpriv_mpegts_parse_packet(MpegTSContext *ts, AVPacket *pkt,
>>
>> const uint8_t *buf, int len);
>>
>> void avpriv_mpegts_parse_close(MpegTSContext *ts);
>>
>> +void ff_mpegts_seek_flush(MpegTSContext *ts);
>>
>> typedef struct SLConfigDescr {
>>
>>int use_au_start;
>>
>> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
>>
>> index fa7544cc07..d688afd1c1 100644
>>
>> --- a/libavformat/rtpdec.c
>>
>> +++ b/libavformat/rtpdec.c
>>
>> @@ -954,6 +954,13 @@ int ff_rtp_parse_packet(RTPDemuxContext *s,
>> AVPacket *pkt,
>>
>>return rv ? rv : has_next_packet(s);
>>
>> }
>>
>> +void ff_rtp_seek_flush(RTPDemuxContext *s)
>>
>> +{
>>
>> +ff_rtp_reset_packet_queue(s);
>>
>> +if (s->handler && s->handler->seek_flush)
>>
>> +s->handler->seek_flush(s->dynamic_protocol_context);
>>
>> +}
>>
>> +
>>
>> void ff_rtp_parse_close(RTPDemuxContext *s)
>>
>> {
>>
>>ff_rtp_reset_packet_queue(s);
>>
>> diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
>>
>> index 5a02e72dc2..8d6d857e28 100644
>>
>> --- a/libavformat/rtpdec.h
>>
>> +++ b/libavformat/rtpdec.h
>>
>> @@ -52,6 +52,7 @@ int ff_rtp_parse_packet(RTPDemuxContext *s,
>> AVPacket *pkt,
>>
>> void ff_rtp_parse_close(RTPDemuxContext *s);
>>
>> int64_t ff_rtp_queued_packet_time(RTPDemuxContext *s);
>>
>> void ff_rtp_reset_packet_queue(RTPDemuxContext *s);
>>
>> +void ff_rtp_seek_flush(RTPDemuxContext *s);
>>
>> /**
>>
>> * Send a dummy packet on both port pairs to set up the connection
>>
>> @@ -135,6 +136,7 @@ struct RTPDynamicProtocolHandler {
>>
>>/** Parse handler for this dynamic packet */
>>
>>
