[FFmpeg-devel] [PATCH 3/3] avformat: add basic timeline support
u at pkh.me
Wed Dec 31 14:50:21 CET 2014
On Wed, Dec 31, 2014 at 01:33:44PM +0100, Nicolas George wrote:
> Le decadi 10 nivôse, an CCXXIII, Clement Boesch a écrit :
> > From: Clément Bœsch <clement at stupeflix.com>
> > ---
> > Another approach this time: exporting a filtergraph from the demuxer
> > (when requested) and inserting it in the tools automatically.
> > FIXME: doesn't work when using -ss with ffmpeg, maybe because it's
> > shifting the timestamps of the frames before feeding them to
> > libavfilter. I probably need guidance here.
> I suspect it aims at a similar goal than this patch series:
> Did you have a look at it? It has the benefit of working at the demuxer and
> decoder level, without lavfi.
> At the time, I was stuck by strange threading problems, I have not yet
> looked at it again.
Yes, I also tried to do it at demuxer level, but keep in mind that the mov edit
list needs some timing adjustment (after you trim in the middle).
15:30:23 <@ubitux> wm4: so... doing it at demuxer level is kind of annoying because of the dts (i believe)
15:31:04 <+wm4> hm?
15:31:06 <@ubitux> i mean, for the packet that are supposed to be dropped, i can't really adjust the dts
15:31:46 <@ubitux> but then after you get back packet to be presented, these must be time adjusted (both pts... and actually dts)
15:32:04 <@ubitux> and so you get dts smaller than the previous ones that were not supposed to be presented
15:32:10 <@ubitux> and it's a mess
15:32:16 <@ubitux> but maybe i miss a trick somewhere
15:32:25 <@ubitux> i'd say i'd just don't touch the dts and only the pts
15:32:29 <@ubitux> but it breaks badly
15:33:27 <+wm4> hm
15:35:33 <@ubitux> http://b.pkh.me/0001-avformat-RFC-WIP-add-basic-timeline-support.patch
15:35:42 <@ubitux> it would look like this
15:35:44 <@ubitux> but it doesn't work.
15:36:18 <@ubitux> so it looks appealing, but unless i find a way to adjust the pts/dts properly, it can't work
15:38:43 <@ubitux> in theory i'd say that not changing the dts is the correct thing to do
15:38:57 <@ubitux> but unfortunately ffmpeg doesn't like the inconsistency between pts and dts
15:40:58 <+wm4> no, dts and pts must be consistent
15:41:54 <+wm4> hm possible we could create another mechanism that changes the timestamps after decoder
15:41:57 <+wm4> *possibly
15:42:44 <+wm4> but yeah, it's a mess
Basically, in case this is not clear, for the packets that must be decoded (but
not presented / needed to decode the frame that will be presented later), we
don't know what timing and dts to set, because they overlap (you need to avoid
a time wrap for the segments you remove).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 473 bytes
Desc: not available
More information about the ffmpeg-devel