[FFmpeg-user] Using -filter_complex instead of lavfi with amerge hangs.

[Tim Nicholson]

On 28/06/12 11:33, Nicolas George wrote:
> Le nonidi 9 messidor, an CCXX, Tim Nicholson a écrit :
>> Not sure about that as the original file is huge, *but* all streams were
>> definitely longer than the 10 seconds I was asking it to encode.
>>
>> However doing a first pass to make a 10 second 4 track mov from the
>> original file, and then using the above syntax completed successfully.
>>
>> So is it that the streams are of different length (unlikely since I
>> wasn't taking the whole file) or the -t 10, or something to do with the
>> interleave on the original file?
> 
> Ok, I understand the bug. The short of it is: you can not use -t with
> -filter_complex.
> 
> The slightly longer version: -t is an output option. In fact, if you put -t
> on one input, it is just kept warm for the next output (this in itself is
> already a bug).
> 
> But the test on the time given to -t is tested on the input file (see
> check_output_constraints).
> 
> Streams from -filter_complex are not associated with any input file, so the
> constraint can not be tested.
> 

Which probably explains why -t appeared to work on a short clip (10secs)
being made even shorter ( -t 5). The unwanted 5 seconds simply piled up
in the buffer and then the transcode completed. However on a much longer
clip eventually it ran out of memory and so failed to complete....

> The correct fix, IMHO, is to distinguish -t for the input and the output,
> but that will require some work.
> 
>> ..and yes all streams in the original file are reported by ffprobe as
>> being the same length..
> 
> IMHO, this is not completely reliable, but now we know it is not the source
> of the problem.
> 
>> What problem is it that needs fixing? I cannot find anything on trac. It
>> would seem to be somewhat serious if it hangs without good reason.
> 
> The whole transcoding process in ffmpeg was designed before filters
> appeared, when there was a clear input<->output mapping. The result is that
> the various functions take their timestamps more or less where they can.
> Unfortunately, with filters, there is no clear mapping, and even when there
> is, the timestamps can be completely different.
> 
> So the whole process need to be scrutinized to really distinguish parts that
> should look at timestamps from the input and parts that should look at
> timestamps from the output.
> 

Thanks for looking at it and the explanation. Perhaps we should document
the fact that "-t" and "-filter_complex" are currently incompatible?

Not sure where would be most appropriate, but as a start I have opened
trac #1491 for this.

> Regards,
>[...]


-- 
Tim