Re: [Mlt-devel] [Kdenlive-devel] AVCHD seeking committed into FFmpeg repository
Brought to you by:
ddennedy,
lilo_booter
From: Dan D. <da...@de...> - 2009-09-03 07:40:43
|
On Thu, Sep 3, 2009 at 12:29 AM, Dan Dennedy<da...@de...> wrote: > Did some testing with the patch applied... > > On Tue, Sep 1, 2009 at 11:54 PM, Dan Dennedy<da...@de...> wrote: >> >> You added a seek-to-first-keyframe in producer_open(). However, I want >> to avoid seeking there to avoid adding addtional time to just load a >> file. When there is a large project file, it can have a big impact on >> project load times. There is already a problem in kdenlive with that. >> I have a commercial client I support that loads 24 hour playlists of >> music videos, short channel promos, advertisements, etc. Imagine that. >> >> If we defer this initial seek to inside producer_get_image, will it >> cause a problem if audio is fetched first? To be specific, I would put >> it inside that function around line 797, inside the following block: >> >> // Seek if necessary >> if ( position != expected || last_position == -1 ) >> ... >> else if ( seekable && ( position < expected || position - expected >>>= 12 || last_position == -1 ) ) >> { >> <here> >> >> The _last_position property is initialized to -1. There is another >> place where it is set back to -1, however. So, we can initialize >> _last_position to -2, and only do your new logic on -2. (And convert >> these values to more meaningful constants.) > > I did the above except I left your seek-on-open there and made a copy > in the place I suggested with choice switchable via a #ifdef. I verified that it does not work when I moved this routine to where I had preferred (AVCHD with new_seek=1 is not frame accurate). At least, not without some further modification to make it work there. I suppose that is OK as long as this is only on for new_seek=1 and H.264 TS. IOW, no seek-on-open and new_seek=0 seems to be fine for non-AVCHD. -- +-DRD-+ |