29.970 (29970/1000) to 29.970 (30000/1001)

[Mattaeous]

Hello, We have some content that is at 29.970 (29970/1000) and needs to be at 29.970 (30000/1001), Can anybody help with this? Need pointing in the right direction!

Thanks

[sneaker]

1. How is the content stored? (container, bitstream format) Ideally, upload a sample.
2. Do you plan to convert the content to a different format?
3. If so, with re-encoding or just remuxing?
4. How did you determine it is 29970/1000?
5. Why do you want/think you need to convert to 30000/1001?

[Mattaeous]

1. Container
2. The current format is MP4
3. We are trying to concatenate variable framerate material
4. We determined via Mediainfo
5. We need to merge the video files with other video files that are in the same sequence of clips, that are 30000/1001

[sneaker]

There is a chance MediaInfo is misdetecting the fps. Without the file it is hard to say.

You can try to append as is using ffmpeg's concat demuxer:
https://trac.ffmpeg.org/wiki/Concatenate#demuxer

[raffriff42]

You can try to append as is using ffmpeg's concat demuxer...

Your suggestion sounds like it might work -- it's echoed (and expanded upon) here:

Change framerate in ffmpeg without reencoding (superuser.com)

...concat demuxer not rescaling the PTS of inputs after the first file, but simply applying a fixed offset.

[Mattaeous]

We are basically dealing with a camera that has a variable framerate (dont ask), and it splits recordings into 14minute sections, we have found one of the files has been timestamped with the wrong FPS information. Hence the need to convert from 29970/1000 to 30000/1001. We have tried concatenation via AVP as we normally would, and using FFMPEG but we have issues with dropping frames etc. Basically a massive headache

We have tried with a couple of different media info applications and they are reading the same info. See attached photo. The top window is a correct piece of content, and the bottom one is the problem file.

Thanks for your help .
[Attachment 44411 - Click to enlarge]

[JVRaines]

Analyze with FFprobe and note the the tbn (stream timebase) values. The concat demuxer requires that all constituents have the same timebase.

[johnmeyer]

The two numbers are the same thing, so I'm not sure why anything needs to be done. 29.97 is created by this: 30.0 * (1000.0 / 1001.0).

[sneaker]

30000/1001 is 29.9700299700...
So difference is very little but not exactly zero. (Little enough to remux with other fps without going async for normal movie length.)

[Mattaeous]

You would think so, but when dropped into AVP to merge the files:


[Attachment 44413 - Click to enlarge]

[poisondeathray]

There are 2 places framerate and timing information is kept , at the stream level as declared in the video stream header, and the container level as timecodes . You might have to address one or both

The VFR display is likely it's jitter in the container timecodes. Look at the min/max values - very minimally variable - you can probably even treat them all (including the other clips) as CFR , if the other segments show similar degree of deviation

You can use mp4fpsmod to rewrite timecodes, but I think it's windows CLI only.

If the actual elementary video stream (not container timecodes) has an actual different declared video frame rate, there are utilities to patch that , for example a modified ffmpeg build
http://forum.doom9.org/showthread.php?t=152419

Demux , remuxing as CFR should work too, for example using mp4box

The difference of 30000/1001 vs. 29970/1000 over a 14-15 minute segments is probably negligible for sync purposes; but there are methods to adjust the audio if you wanted it exact - but it requires re-encoding the audio .

[johnmeyer]

It seems that people are assuming that when the OP writes "29970/1000" that he is saying this is equivalent to 29.97000000000.

Is that actually what the OP is reporting?

I don't know. As already pointed out, 30.0000 / 1001.0 actually equals 29.97002997003000000000000... and therefore 29.97000000 is an incorrect approximation. However, since most people (and perhaps some media info software) use "29.97" as a shorthand for this longer fraction, I don't think we yet know, in this instance, whether or not 29970/1000 is the same as 30000/1001, or not. I realize that the result of those two divisions, as I just wrote them in that last sentence, are not the same thing, but I am instead questioning whether the report from the software means that the actual frame rates are different.

[Cornucopia]

Let's not just say that it's negligable, let's be honest and accurate and say that for a whole 2 hour movie, it wouldn't even amount to 1 whole frame's-worth of difference. So being too cautionary because it might not be accurate enough is foolish.
I say: Go for changing the timecodes, and patching the stream headers and making it all safely CFR (which is probably what ought to have been all along).

Vfr is a hornet's nest of pain for little or no gain (that couldn't be gotten better by vbr). The only thing that justifies its existence IMO is low-light phone cam recording. And even then, I would say it's a lazy cheat to prop up a too-fragile consumer setup.

Scott

[Mattaeous]

Thanks for all your replies, im doing some testing today and will report back!

[sneaker]

I say: Go for changing the timecodes, and patching the stream headers and making it all safely CFR (which is probably what ought to have been all along).

The question is if it's "true" VFR or just some jitter.You can't just header patch VFR away without losing sync if it's the former.

[Cornucopia]

Unless MediaInfo is grossly inaccurate, it's not a question.
Min 29.6. Max 29.8 isn't truly vfr, it's indicative of 29.97 that is inaccurately stored. I doubt there should even be jitter upon fix.

Scott