[Kdenlive-devel] Fwd: max_analyze_duration reached

[Dan Dennedy]

On Mon, Sep 22, 2014 at 10:05 AM, Pascal Fleury <
fleury at users.sourceforge.net> wrote:

> Hi Dan,
>
> On Mon, Sep 22, 2014 at 3:30 AM, Dan Dennedy <dan at dennedy.org> wrote:
>
>> On Sun, Sep 21, 2014 at 5:30 PM, Pascal Fleury <
>> fleury at users.sourceforge.net> wrote:
>>
>>> Hello,
>>>
>>> I am completely stuck, any help welcome...
>>>
>>> I am about to finish a video project, where I use pretty long files
>>> (several 1080p at 25 13 minute chunks, audio @ 96kHz stereo 32 bit float
>>> for 1.5 hours) and it seemed to work nicely so far. I used proxy clips all
>>> along, as working off the original video is just not possible.
>>>
>>
>> I never use proxy clips, almost always source clips, and very
>> occasionally transcode problematic clips.
>>
>
> On my machine, navigating through original clips is way too slow. Also I
> have 4 video tracks, with mostly 2 tracks having a video at any given time.
> Proxy clips are actually making the whole thing very usable, if not really
> comfortable.
>

>
>>
>>
>>> Now I try to render the project, and I face many issues: first, when
>>> rendering the project with proxy clips set on the clips (the little 'P'),
>>> it does not use the full resolution for the final render. I think this is a
>>> known issue (ignores the little checkbox in the render dialog).
>>>
>>> My real issue is that if I remove the proxy clips, then it tries to
>>> re-render the thumbnails on the time line, and gets them all wrong. The
>>> files are correct, but it does not display the right images (takes some
>>> others), and renders full black video.
>>>
>>> After saving and reloading, it's even worse, as I face the issue with
>>> lots of lines like in the title (more, see below). And after this, _all_
>>> clips on the timeline are zero length, completely ruining my project. I use
>>> git for all text files, and did regular checkpoints, so I have not lost
>>> much besides time, and rollbacks are easy.
>>>
>>>
>> Sounds like "remove the proxy clips" is not a safe operation.
>>
>
> I think it tries to get the original clip length, and from the error
>  message, seems to not get a useful answer. If it returns a length of zero
> (or negative) in case it reaches the maximum analysis length, then it would
> explain why my clips get all shrunk on the timeline.
>

>
>>
>>> So essentially, I am stuck with a project I cannot render after 60 hours
>>> of editing time... Any help ? Anything I
>>>
>>
>> I think you need a workaround for that problem with the checkbox being
>> ignored, but I do not know anything about the proxy mode in Kdenlive. Maybe
>> there is a way to modify the xml and render it with melt.
>>
>
> I will fiddle a bit more with that checkbox, as I think I had other issues
> with sub-projects that I imported.
>
>
>>
>>
>>> could do to get a final video from my project ? Or is this
>>> max_analyze_duration from an underlying tool that I could downgrade/upgrade
>>> ?
>>>
>>> I can definitely tell you that the message "max_analyze_duration
>> reached" comes from libavformat. It appears very frequently in many tools
>> (too verbose), is related to determining the duration of a clip, and is not
>> likely related to your problem.
>>
>
> As I mentioned above, does libavformat then return a size of e.g. 0 if it
> could not analyze it fully ?
>

I just looked at libavformat code to learn more about this. It is not only
determining the duration; it is gathering all the essential information
about the file like tracks, codecs, fps, initial timestamps, metadata, etc.
Depending upon the format, sometimes it is not clear when all of the
information has been collected. In that case it reads frames/packets
representing up to max_analyze_duration (5s default), to finish collecting
more possible information. More often than not, it will have collected it,
but it is being diligent and reporting verbosely about its diligence.


> Is there a cmdline tool that I could run on these WAV and video files to
> see the failure mode ?
>

melt -verbose {filename} -consumer xml time_format=clock

Then, look for the "length" property (HH:MM:SS.ms) to see if it seems
correct. It also reports some information about streams and codecs so you
can determine if that looks sane.

-- 
+-DRD-+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20140922/fba2492c/attachment.html>