[FFmpeg-user] Feature request: show the "speed" of audio only conversions

[Serguei Castillo]

Hi I nned help to concat videos (join in batch mode) I nned join abou
300 videos and I do it one per one.
I have 2 list of videos, one short and another long. I use this
Join video1(list1) to video1(list2) to video2(list1)
Join video2(list1) to video2(list2) to video3(list1)
Join video3(list1) to video3(list2) to video4(list1)..... then star
repeating the list one until the list 2 finish all videos

On 03/09/2015, Moritz Barsnick <barsnick at gmx.net> wrote:
> Hi Roger, users,
>
> On Tue, Jun 30, 2015 at 15:49:34 -0600, Roger Pack wrote:
>> On 6/11/15, Moritz Barsnick <barsnick at gmx.net> wrote:
>> > On Thu, Jun 11, 2015 at 10:31:54 -0600, Roger Pack wrote:
>> > Which is something like a "5.3x" display, such as lame shows it (I
>> > think).
>> >
>> > I think that is just as valid a request for video. I do see the fps,
>> > but I need to do quick head-math and know the fps of the source.
>> >
>> > That said, there may be some ambiguity with regards to which base to
>> > take: Input PTS, output PTS; what about jumps in PTS? Can this work
>> > when copying? I'm thinking out loud too much. ;)
>
> I have done some thinking, and I am convinced I need this feature.
>
>> It would be a huge win to get an "estimated time to completion" as well
>> :)
>
> This is too tricky in this part of the code. I think the muxers and
> demuxers handle durations, and it becomes more complicated if VBR, trim
> filters, enable expressions and other complicated stuff are involved.
> So while an ETA (or a progress in percent) would be nice, I can't wrap
> my head around it.
>
> That said, here's a not-so-quick shot at a speed display (attached). I
> made some other approaches with some other calculations, but it never
> made enough sense.
>
> I used "%.3g" for the printf format, as I like the number of relevant
> digits this way. I haven't looked at the portability of %g across
> supported compilers though.
>
> I haven't bothered writing any info into the "progress information"
> (&buf_script) at this point. I probably should for consistency.
>
> Disclaimer: I don't know if we should even try to get this upstream.
> I'm just playing with the possibilities. ;-) Just for you and me,
> Roger.
>
> [That function could really really really make use of a macro for
>  snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), ...);
>  14 occurrences!
>  ;-) ]
>
> Moritz
>


-- 
SCC