[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