[FFmpeg-devel] [PATCH] WIP: concat demuxer mode concealing input errors
george at nsup.org
Sat Apr 19 11:57:42 CEST 2014
Le decadi 30 germinal, an CCXXII, Andrey Utkin a écrit :
> Not sure whether this is important or usable for anybody else.
> I'm doing it for a case happening in one of my apps. It happens that some
> files pending to concatenation are broken, e.g. mp4 files are unfinished
> and ffmpeg cannot find their moov block, this makes concatenation to stop.
> For now, as a workaround i ffprobe each chunk before including it to
> concatenation list, but if we have such mode in concat demuxer itself, we
> could also handle problems which happen after opening input file, and also
> have less overhead on those checks.
I must say, I do not like it very much. I will not oppose it, but at least I
will ask for a third opinion and in the meantime try to convince you.
My main concern is that this feature is very specific to your use case, and
not a very good solution for it either.
As you wrote:
> - failure of file reading (av_read_frame()) is not tested;
If the file is corrupted in the middle, concatdec will forward the error,
and transcoding will stop.
But that is not the only problem: the demuxer can not guard against a
corrupted bitstream that would cause decoding to fail.
You also have the problem of mismatched streams: if your files have
different codecs, it will completely fail, and there is currently nothing
you can do about it.
For these reasons, I believe the solution using ffprobe for pre-processing
is in fact better. The overhead you want to avoid is the price of working
with unreliable sources: if you skip it, you make your process that much
A last point: you says "mp4 files are unfinished", this suggests a better
solution for that particular case: only include the files when you are sure
they are finished. For example, if your files come from HTTP form upload,
store them in a separate directory during the upload and only move them in
the final directory once the upload is complete and successful.
> - failure to open non-first items gives bad results because DTS shifting
> is done wrong, see "// FIXME" place. I have no idea how to make it in a
> good way, currently.
There is no way around it: if you can not open a file, you can not know its
duration. If you want to skip the file, you just have to make an assumption
on its duration. Probably 0.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel