VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Results 1 to 16 of 16
Thread
  1. 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
    Quote Quote  
  2. 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?
    Quote Quote  
  3. 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
    Quote Quote  
  4. 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
    Quote Quote  
  5. Originally Posted by sneaker View Post
    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.
    Quote Quote  
  6. 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 . Image
    [Attachment 44411 - Click to enlarge]
    Quote Quote  
  7. Member
    Join Date
    Aug 2010
    Location
    San Francisco, California
    Search PM
    Analyze with FFprobe and note the the tbn (stream timebase) values. The concat demuxer requires that all constituents have the same timebase.
    Quote Quote  
  8. 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).
    Quote Quote  
  9. 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.)
    Quote Quote  
  10. You would think so, but when dropped into AVP to merge the files:

    Image
    [Attachment 44413 - Click to enlarge]
    Quote Quote  
  11. 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 .
    Quote Quote  
  12. 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.
    Quote Quote  
  13. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Quote Quote  
  14. Thanks for all your replies, im doing some testing today and will report back!
    Quote Quote  
  15. Originally Posted by Cornucopia View Post
    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.
    Quote Quote  
  16. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Quote Quote  



Similar Threads