[FFmpeg-user] Reversing PAL->NTSC telecining.
Nicholas Robbins
nickrobbins at yahoo.com
Wed Jan 8 18:22:51 CET 2014
> On Wednesday, January 8, 2014 11:07 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> > Nicholas Robbins <nickrobbins <at> yahoo.com> writes:
>
>> ffmpeg -fflags +genpts -i in.vob -i novid.mkv -map 0:v
>> -map 1 -c copy out.mkv
>
> Out of curiosity:
> What does FFmpeg not support so that you always have to use
> additional input files?
Mostly because I'm more familiar with the metadata manipulation of mkvmerge, but if I can get this memory situation fixed, I might switch over to ffmpeg for this whole process. (I just figured out how to get sub/idx's into ffmpeg.) However, this happens even without the mkv input file. The same behavior happens with
ffmpeg -fflags +genpts -i IN.vob -map 0:v -c copy OUT.mkv
which stalls around 10 minutes in and starts using more and more memory eventually swapping.
> (And why are you using -c copy, I thought this is all about
> inverse telecine?)
My process is
1) Rip and mux to something with all the metadata I want to keep
2) Inspect for interlacing or telecining visually
3) Transcode to x264 removing interlacing or telecining etc.
I was using mkvmerge for step 1, but it mangled the fps in the stream header (is that the right term?) so that I had to add a fps=fps=30000/1001 in the filterchain for step 3. Now ffmpeg seems to do a better job of part 1 in terms of getting the fps correct, but is using a ton of memory to do so.
> Without checking, I suspect that mkv stores an index (not the
> vob file) which has to be created while writing the file.
>
Seems reasonable.
> If this is reproducible with a simple command line (-i testsrc)
> I would like to test myself, >1G seems too much to me.
No, at least not when I did (just learning about -i testsrc)
ffmpeg -fflags +genpts -f lavfi -i testsrc=duration=1200:size=720x480:rate=30 -map 0 -c copy -f matroska /dev/null
it just chugs along with no problem
>> I will if I have a problem with fieldmatch.
>
> ;-(
> (The point here is that you trust fieldmatch to be superior
> although I hinted several times that this is not actually
> reproducible.)
>
[...]
> Carl Eugen
I'll look into using pullup.
Nick Robbins
More information about the ffmpeg-user
mailing list