[FFmpeg-user] How can I join video files?

Tarun singhal tsinghal18 at gmail.com
Mon Feb 20 17:47:08 CET 2012


"Making it a seprate utility"

I agree ffmpeg is already a complicated tool, adding merging facility can
make it more complicated.
Making merging as a seprate utility, sound like a fine idea, until users
are saved from intermediate steps,

Regards,
Tarun Singhal




On Mon, Feb 20, 2012 at 10:13 PM, Tarun singhal <tsinghal18 at gmail.com>wrote:

> Well, I am still in learning stage, but I faced same use case,
>
> The problem is, if the segments are in GB scale and are of different
> format, concatenating them by converting into mpg raw video format, is
> highly costly business,
>
> According to me command line can look like this -
>
> ffmpeg -i "merge: seg1,seg2,seg3" <transcoding_options> output
>
> "merge" would be a new option introduced
> At the back end: We can try to analyze each segment specified in the input
> option, and process everything.
>
> logic:
> step 1: start transcoding seg1 as per <transcoding_option>, and as it get
> finished,
> step2:  just start transcoding seg2 and those frames are to be added to
> stream being obtained from step1
> and go on...
>
> I don't know how that logic will look like, just thought to share what I
> think.
>
> Regards,
> Tarun Singhal
>
>
>
>
> On Sun, Feb 19, 2012 at 1:04 AM, Andrey Utkin <
> andrey.krieger.utkin at gmail.com> wrote:
>
>> 2012/2/17 Peter B. <pb at das-werkstatt.com>:
>> > 2) I agree with you that concat+remux+transcode in one step might be
>> > "sugarization", compared to subsequent FFmpeg calls, when you only have
>> to
>> > transcode a handful of files - but with mass transcoding (several
>> hundred
>> > files per day) of "heavy" stuff (like e.g. FFv1 with 350-600 MB/Minute),
>> > intermediate steps add up runtime-wise.
>> >
>> > For example:
>> > At the Austrian Mediathek (=national audio/video archive), we're
>> producing
>> > several hundred FFv1 encoded minute-sequences per day as archive format.
>> >
>> > Now, transcoding this archive material into e.g. DVD-MPEG or web-videos,
>> > they need to be concatenated *and* transcoded.
>> > Intermediately "touching" the harddisk would add a tremendous slowdown
>> of
>> > this already slow transcoding process (FFv1->MPEG on 3.6Ghz CPU:
>> ~20-25fps).
>> >
>> > I know it's a super-rare-extremely-special-and-not-so-everyday usecase,
>> but
>> > currently I need to use mencoder for this - but would looooove to use
>> FFmpeg
>> > (because I think it's better supported).
>>
>> Merging video in one pass, when full transcoding is acceptable, is
>> possible using API (i mean requires specific application ATM).
>> I guess this task can raise timing (and a/v sync) issues when
>> transcoding variable-framerate files, like FLV.
>> Well, it is often easy to implement app that works on exact type of
>> files, and hard to think up how all-purposed app should work. (E.g. i
>> have made an app that merges certain FLV h264 videos just by remuxing,
>> a lot later i've realized that it's not guaranteed to work).
>>
>> But video merging is feature of high demand, i agree ffmpeg should
>> have such tool.
>> But i think it's easier to make it separate utility. I just wonder how
>> can we denote our intention to merge video, how should ffmpeg command
>> line look like?
>> If you provide samples of your files, you have a chance to get
>> supported with such tool from early days, if volunteers appear to put
>> efforts on it.
>>
>> --
>> Andrey Utkin
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>
>


More information about the ffmpeg-user mailing list