[FFmpeg-user] Reversing PAL->NTSC telecining.

[Nicholas Robbins]

> On Sunday, January 12, 2014 12:15 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> > Nicholas Robbins <nickrobbins <at> yahoo.com> writes:
> 
>>  > If you play the original vob file with ffplay and seek 
>>  > (with "up" and "page-up") do you see monotonic 
> timestamps 
>>  > in the console output or does something funny happen?
>> 
>>  I'm not sure what you mean.  If I do "ffplay IN.vob -ss 1580" 
> (to skip to
> near the 26:25 error)
> 
> My English is limited but what I meant was "ffplay IN.vob", 
> then use PgUp and Up to seek, watch the timestmap on the 
> console, and see if it does something funny at some point 
> (like resetting to 0).
> 

Ah, didn't think the seeking would hide the issue but it did. I played from the start and the timestamp loops at the 1600 mark, if the timestamp is the first number on the constantly updating stat line.


>>  > Can you upload the sample that causes the memory problems?
>> 
>>  It happens on this sample 26 minutes in.
> 
> This sounds as if my guess with the timestamp discontinuity 
> might be right.
> 
>>  That is approximately a GB file. I don't think you want 
>>  me to upload it.
> 
> Why do you think so?
> (There is a ticket that originally needed a 10GB file.)
> 
> I am just (very) unhappy if 20M are uploaded although 
> 100k allow to reproduce the problem.
> 
>>  Would a dd grab from the middle help?
> 
> If the output file allows to reproduce the issue, definitely!

Strange things here. I did this:

$ for x in 1 2 3 4 5; do dd if=IN.vob of=short-$x.vob bs=1K count=${x}M; done

then

$ for VIDEO in short-*.vob ; do echo $VIDEO ;/usr/bin/ffprobe ${VIDEO} 2>&1 >/dev/null | /bin/grep 'Duration'; done
short-1.vob
  Duration: 00:20:43.20, start: 0.045500, bitrate: 6909 kb/s
short-2.vob
  Duration: 00:16:24.75, start: 0.045500, bitrate: 17445 kb/s
short-3.vob
  Duration: 00:37:09.65, start: 0.045500, bitrate: 11557 kb/s
short-4.vob
  Duration: 00:57:36.56, start: 0.045500, bitrate: 9940 kb/s
short-5.vob
  Duration: 01:13:06.64, start: 0.045500, bitrate: 9248 kb/s

I also did 

dd if=IN.vob of=mid.vob bs=1K count=1M skip=1M

which gives
mid.vob
  Duration: 26:26:25.24, start: 1243.278867, bitrate: 90 kb/s

when I run each of them through 

time ffmpeg -y -fflags +genpts -i short-${x}.vob -map 0:v -c copy -f matroska /dev/null

I get the following run times:

time used (m:ss):
1: 0:30
2: 1:30
3: 2:52
4: 3:32
5: 3:43.
mid: 0:51

reported encoded duration (h:mm) :
1: 0:20 minutes
2: 0:43
3: 1:03
4: 1:24
5: 1:39
mid: 0:22

qualitative behavior and memory usage

1: cpu usage about 50% and max memory usage 9M. Timely. No problem. Seems disk IO bound as reruns go much faster.

2: at 26 and a bit, cpu usage hits 100% and memory usage climbs to 600M and then the encode resumes, jumps ahead quite a bit and finishes.

3: same as 2 except memory climbs to 1G and then the encode resumes and jumps ahead and memory drops slightly to 900M and finishes in a timely fashion.

4: same as 3
5: same as 3 (slightly more memory usage).

mid: same as 2, except stalls at 5 minutes in.

Seems like this one is not quite as bad as what I saw from the earlier sample, but I've returned that dvd to a friend.

Which of these vob's do you want? 

> 
>>  I don't know if that is how vob's work.
> 
> You can cut program streams (like transport streams) 
> with dd (if that was the question).

Yes, it was. 

-Nick