Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Tomas Härdin" <git@haerdin.se>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Moving edit list handling out of demuxers
Date: Fri, 13 Jun 2025 16:34:15 +0200
Message-ID: <e8d181769cf2af13f7e1c1fe67419374148136f6.camel@haerdin.se> (raw)
In-Reply-To: <mailman.3176.1749819125.1384.ffmpeg-devel@ffmpeg.org>

> Derek did this in 2018:
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227437.html

Interesting. I didn't think to use side data for it. Putting the edit
lists in AVStream seems wrong. They belong to AVFormatContext. Else we
can't support ganged or alternate packages in MXF (OP1b, OP1c, OP2b,
OP2c, OP3b, OP3c), nor could we support IMF. Yes, I know imfdec.c
exists. It too is cursed.

The point about ABI stability is a good one, but can be dealt with by
an extra level of indirection. A bit annoying but probably a good idea
in the long run.

Also this point by Rostislav is a good one:
https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227446.html

> It wouldn't be breaking anything - technically making this part of
> lavf in the first place and enabling it by default broke behaviour.

In other words, by default ffmpeg currently *throws away essence*. This
is very bad.

---

Here's what I came up with so far for reference. The idea is to just
stick a pointer to AVEditLists in AVFormatContext. This was written
before I saw the ABI point and the indirection solution to it.

Some of the fields can probably be removed since they're intended
mostly for MXF, and adding fields later is easier than removing them.

Anyway, here are some structs:

// the terminology here is mostly lifted from ISOBMFF and the MXF spec
#define AV_EDIT_ITEM_FILLER 1       ///< Filler. Only duration is of relevance.

/**
 * Edit item.
 * Corresponds to elst entries in MOV, SourceClips in MXF.
 */
typedef struct AVEditItem {
    int stream;                     ///< Source stream for this item. TODO: other files? Could maybe be handled by assigning some kind of global stream ID to streams
    int64_t start;                  ///< Offset in terms of the source's presentation time base, for example sample rate for audio
    int64_t duration;               ///< Duration in terms of edit rate for this track. Must be non-negative. Zero means duration of the rest of the stream (see section 8.6.6.1 of ISO/IEC 14496-12:2015(E))
    AVRational rate;                ///< Relative playback rate. Zero = dwell, repeat pointed-to frame for the duration. 1 = normal. 2 = play twice as fast. TODO: let rate = -1 mean filler like in mov?
    int flags;                      ///< Flags. See AV_EDIT_ITEM_*
    AVDictionary *metadata;         ///< Metadata such as SourcePackageID, SourceTrackID, StartTimecode and so on.
} AVEditItem;

/**
 * Edit track.
 * A collection of edit items in temporal order.
 */
typedef struct AVEditTrack {
    enum AVMediaType type;          ///< Media type of this track.
    AVRational edit_rate;           ///< Edit rate. May be different from the frame rates of the streams pointed to by the edit items.
    int64_t origin;                 ///< Start of this track. Necessary for compatibility with MXF.
    AVEditItem *items;              ///< Edit items.
    int nb_items;                   ///< Number of edit items.
    unsigned items_allocated_size;  ///< Number of bytes allocated for edit items.
    AVDictionary *metadata;         ///< Metadata such as TrackNumber, TrackName and so on.
};

/**
 * Edit list.
 * Multiple edit tracks of different types, all collected as a unit.
 * Constituent tracks may have different origin and duration.
 */
typedef struct AVEditList {
    AVEditTrack *tracks;            ///< Tracks.
    int nb_tracks;                  ///< Number of tracks.
    unsigned tracks_allocated_size; ///< Number of bytes allocated for tracks.
    int loop_count;                 ///< Number of loops. 0 = infinite, >0 = that number of times. Used for HEIF/AVIF. TODO: put in metadata?
    AVDictionary *metadata;         ///< Metadata such as PackageUID, Name and so on.
} AVEditList;

/**
 * Collection of edit lists.
 * This is used for formats like MXF and IMF that support multiple "variants" of the same file,
 * for example different language variants of one movie.
 * In MXF parlance these are called "material packages".
 */
typedef struct AVEditLists {
    AVEditList *edit_lists;             ///< Edit lists.
    int nb_edit_lists;                  ///< Number of edit lists.
    unsigned edit_lists_allocated_size; ///< Number of bytes allocated for edit lists.
    AVDictionary *metadata;             ///< Metadata specific to this collection of edit lists.
} AVEditLists;

---

More fine points to consider that are touched on above:

* how do we express a timeline that points to multiple files, including external files?
* when should playback start?
* should we add an AVMediaType for timecodes?

/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  parent reply	other threads:[~2025-06-13 14:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-13 10:55 Tomas Härdin
2025-06-13 12:51 ` Kieran Kunhya via ffmpeg-devel
2025-06-13 13:28   ` Derek Buitenhuis
2025-06-13 14:34   ` Tomas Härdin [this message]
2025-06-13 14:41     ` Derek Buitenhuis
2025-06-13 14:21 ` Michael Niedermayer
2025-06-13 14:53   ` Tomas Härdin
2025-06-13 14:57     ` Gyan Doshi
2025-06-17 20:42       ` Tomas Härdin
2025-06-13 16:19     ` Michael Niedermayer
2025-06-17 21:15       ` Tomas Härdin
2025-06-18  3:55         ` Michael Niedermayer
2025-06-18 10:02           ` Michael Niedermayer
2025-06-18 10:09             ` Nicolas George
2025-06-18 15:50           ` Tomas Härdin
2025-06-13 16:22     ` Michael Niedermayer
2025-06-13 14:37 ` Gyan Doshi
2025-06-17 21:33   ` Tomas Härdin
2025-06-18  4:15     ` Gyan Doshi
2025-06-18  7:17     ` Nicolas George
2025-06-13 16:57 ` Nicolas George

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e8d181769cf2af13f7e1c1fe67419374148136f6.camel@haerdin.se \
    --to=git@haerdin.se \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git