On 27 March 2018 at 20:44, Derek Buitenhuis <derek.buitenh...@gmail.com> wrote:
> So, I know we have edit list "support" in mov.c, but I am steadfast in my > belief that it is incorrect to implement it at the demuxing layer. By the > ISOBMFF spec, it is supposed to be applied at the presenattion layer. I'm > aware we probably cannot remove the current implementation very easily > (or at all?) because many will argue it is "removing a feature". Thus, for > ISOBMFF and mov support, this will likely have to live under a movflag, > I assume? > > Anyway, this is my proposal for generic stream side data for virtual > timelines. > This is also meant to cover Matroska ordered chapters and editions, though > I > am not entirely sure how segment linking would work into this, if I am > honest. > > If/once I have the side data structs and API (in the following RFC patch) > agreed > upon, I am willing to write: > > * Support for exporting MOV/ISOBMFF edit lists via side data > * Support for exporting Matroska edit lists via side data > * Porting the fftools to use it (if wanted) > > As a side note, I would appreciate input from someone who unerstands > Matroska > better than I do on this. I haven't included e.g. the Hidden/Enabled flags > in > AVtimelineEntry since they don't seem to actually be useful to the actual > timeline (they seem to be mostly related to displaying chapter names or > not). > > The side data structs and API are based off of the recently pushed > encryption > side data changes. The media rate is a rational, because exporting a float > would change on different platforms, and would make adding regression tests > problematic. > > So, everyone, rev up your diesel powered bikesheds and drive them full > steam > into this thread's back yard, over my daffodils. > > Derek Buitenhuis (1): > avcodec/avutil: Add timeline side data > > libavcodec/avcodec.h | 8 +++ > libavutil/timeline.h | 160 ++++++++++++++++++++++++++++++ > +++++++++++++++++++++ > 2 files changed, 168 insertions(+) > create mode 100644 libavutil/timeline.h > > -- > 1.8.3.1 > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > I think we should drop the internal crap if the tools and the API support it. Would also solve a lot of issues like ffmpeg.c not trimming the start frame (so people complain all the time about longer files). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
