Re: [Mlt-devel] [Kdenlive-devel] AVCHD seeking committed into FFmpeg repository

[Dan D. <da...@de...>]

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-+