VideoHelp Forum
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 31
Thread
  1. I've spent like 10 hours googling about frame rates, but can't find a thorough answer to this very specific question.

    I'm planning to use Shutter Encoder to change from VFR 59.6x > CFR 60 and also DNxHR. The crucial detail is: Does the smallest divisible unit of fps-speed-variability have an equally accurate or even more accurate counterpart unit in the realm of frame-insertion-and-deletion algorithm that is used by VFR>CFR converters ? Because VFR adjusts the playback speed of every frame by decimal points to the third place, but it still reflects what took place in real time in front of the camera. I know the conversion will create a near identical copy, but can it match the accuracy if it was measured at let's say a thousand random points for deviations of even 1 milliseconds?

    And I'm not too worried about audio sync to the original sound, I'm more worried about internal nano-stretching and nano-shrinking that will change when certain frames are triggered within the playback in relation to other frames - compared to how the VFR would have played: with more frame relational integrity.

    Before anyone says this level of precision is unnecessary - I have my artistic reasons for getting as close as humanly possible to perfection.

    If anyone can shed light on this, I will send my sincere blessings to you and your loved ones. Because I'm so frustrated that I'm about to start teaching myself C and Assembly so I can examine ffmpeg's source code.
    Quote Quote  
  2. Originally Posted by LapisLazuliLicorice View Post
    I'm planning to use Shutter Encoder to change from VFR 59.6x > CFR 60 and also DNxHR. The crucial detail is: Does the smallest divisible unit of fps-speed-variability have an equally accurate or even more accurate counterpart unit in the realm of frame-insertion-and-deletion algorithm that is used by VFR>CFR converters ? Because VFR adjusts the playback speed of every frame by decimal points to the third place, but it still reflects what took place in real time in front of the camera. I know the conversion will create a near identical copy, but can it match the accuracy if it was measured at let's say a thousand random points for deviations of even 1 milliseconds?
    Not really - your target fps is 60/1 - therefore the smallest discrete unit of time possible , or 1 frame, is 16.66666...ms . (1/60 = 0.01666... sec duration per frame)

    Anything more precise than 16.66666... ms is "interpolation" or guessing. Not authentic recorded data .

    Had you shot CFR @ 60/1, the smallest unit of time is still 16.66666...ms . Recording CFR would usually be more accurate than your VFR recording (VFR is usually from dropped frames - ie. You're usually missing data in the recording, but an average of 59.6 is probably only minimally variable and not too much to worry about)

    Or if you "interpolated" or synthesized "inbetween" frames, such as optical flow methods, then you could have higher precision, because you have more samples per second. However, they can be prone to artifacts

    but it still reflects what took place in real time in front of the camera.
    Or partially "missed" what actually took place. Hence the lower framerate. The average FPS might be 59.6, but there might be a section with a low FPS. On highly variable recordings, there might be larger dips


    Before anyone says this level of precision is unnecessary - I have my artistic reasons for getting as close as humanly possible to perfection.
    Then record CFR, and at a higher FPS . More real samples per unit time.
    Quote Quote  
  3. Originally Posted by LapisLazuliLicorice View Post
    Before anyone says this level of precision is unnecessary - I have my artistic reasons for getting as close as humanly possible to perfection.
    Calculate delta PTS btween frames, find lowest one, use it as your target PTS i.e. fps (1/smallest delta PTS) - this will be perfect VFR to CFR conversion.

    Or stop using malfunctioned capture device (a.k.a. camera) - poor software developers without basic knowledge about video produce faulty software where VFR is created (instead CFR).
    Quote Quote  
  4. Originally Posted by pandy View Post
    Or stop using malfunctioned capture device (a.k.a. camera) - poor software developers without basic knowledge about video produce faulty software where VFR is created (instead CFR).
    Bandicam actually claims VFR is better! (Which for their screencap purposes isn't necessarily wrong.)

    I wonder if the precision OP requires has to do with settling an argument in a game capture video.
    Quote Quote  
  5. VFR is better for compression purposes, if the VFR was done correctly .

    eg. If there is absolutely no change, then repeated identical frames can be represented by 1 frame instead of encoding many duplicates. Although identical frames do not "cost" much to encode with modern codecs - if you have strings of hundreds or thousands of identical frames, a few bytes here and there adds up

    The problem is "on the fly" VFR recording often drops real unique frames, as the encoder "warms up" or picks up speed. The transition between no motion , to movement and motion often isn't perfect. A large buffer (stream recorders tend not have this), or CFR to VFR conversion non real time/offline often provides more accurate CFR to VFR conversion than a "live" or realtime VFR recording
    Quote Quote  
  6. Originally Posted by poisondeathray View Post
    Anything more precise than 16.66666... ms is "interpolation" or guessing. Not authentic recorded data .
    So this concept might possibly be going over my head - if so I apologize for sticking to my own concept - but I still feel like I'm describing another type of precision. It's more like a precision about when each frame will fire/trigger as opposed to the VFR version. Since the decimal point fps speeds of VFR will put frame triggers in relative positions that vary from 16.66ms, because I thought it offers greater precision. Now, will the dynamic speed-adjusting algorithm of the VFR (which speeds up and slows down according to instructions attached to each frame) be within the grasp of VFR>CFR converters to nail on the dot for each frame trigger?

    Originally Posted by poisondeathray View Post
    Or if you "interpolated" or synthesized "inbetween" frames, such as optical flow methods, then you could have higher precision, because you have more samples per second. However, they can be prone to artifacts
    Good to know, do NOT want artifacts.

    Originally Posted by poisondeathray View Post
    Then record CFR, and at a higher FPS . More real samples per unit time.
    I didn't even know VFR existed until I had shot a lot of difficult footage. I now hate it with a vengeance and am saving up for a real camera. But I still want to salvage the precious footage, it's good enough to deliver.


    I think I thought of a better question --- So I know I might have to accept whatever comes out after converting, but what if I used the VFR footage I have now, without converting it? Would I be better off not converting if i wanted to preserve frame relational integrity? Is that even possible since I still have to import it into NLE (DVResolve) to sync it to audio ?
    Quote Quote  
  7. Originally Posted by pandy View Post
    Calculate delta PTS btween frames, find lowest one, use it as your target PTS i.e. fps (1/smallest delta PTS) - this will be perfect VFR to CFR conversion.
    Woah! This might be just what I need! Especially since I heard YouTube respects original frame rates. But wouldn't it eventually get misaligned as it goes through frame by frame? Because it will be cutting by a distance that is shorter than most of the frames, so there will be a little extra on each one, and eventually it will land equidistantly on two frames and have to choose one to use that is closer, but it would be 8 milliseconds off (which is a little less than half of one frame) ?

    Originally Posted by pandy View Post
    Or stop using malfunctioned capture device (a.k.a. camera) - poor software developers without basic knowledge about video produce faulty software where VFR is created (instead CFR).
    I didn't even know VFR existed until I was trying to edit my footage. I would never willingly choose VFR, but now I have all this footage and I want to deliver as best I can. I'm a beginner and taking my mistakes in stride. I will start saving up for a real camera after this.
    Quote Quote  
  8. Originally Posted by smrpix View Post
    I wonder if the precision OP requires has to do with settling an argument in a game capture video.
    This is for dance videos. Very unforgiving margins.
    Quote Quote  
  9. Originally Posted by LapisLazuliLicorice View Post
    So this concept might possibly be going over my head - if so I apologize for sticking to my own concept - but I still feel like I'm describing another type of precision. It's more like a precision about when each frame will fire/trigger as opposed to the VFR version. Since the decimal point fps speeds of VFR will put frame triggers in relative positions that vary from 16.66ms, because I thought it offers greater precision. Now, will the dynamic speed-adjusting algorithm of the VFR (which speeds up and slows down according to instructions attached to each frame) be within the grasp of VFR>CFR converters to nail on the dot for each frame trigger?
    It sounds like you're asking about where the duplicates will be inserted, and questioning the precision

    For the VFR to CFR conversion, you are limited to 16.666 ms precision, regardless of what the source VFR was. The 16.666ms constraint is from converting it to 60/1 CFR.

    Here is another way to think of it: Had you recorded a CFR 60/1 FPS version, that is the "full" 100% accurate version. Your version has missing frames. A "perfect" VFR to CFR conversion would use a time machine and record CFR in the first place. Duplicates are obviously not the same thing as the real unique frame (assuming you're not shooting a static scene), but the best you can do is essentially : "Where can the VFR to CFR algorithm insert duplicate frames to make it similar to the full 60/1 FPS version ?". They are inserted in areas where the frame rate drops (or the timestamp delta increases) . There are only 60 possible "slots" you can place a frame in any given second if you're converting to 60/1 CFR - hence the 16.666ms constraint - and many of them are "already occupied" . You cannot have a quarter of a frame or some fractional frame. The "already occupied" spots are the existing VFR recorded frames with their timestamps. VFR to CFR algorithms only insert missing frames where there are gaps, or drops in the FPS. Because your average FPS is 59.6, it suggests you're not missing very many frames. There are slightly different VFR to CFR algorithms, but you're not going to notice much difference in your case, because you are likely minimally variable

    Note that VFR timestamps are not always accurate from the camera . They can "overshoot" or "undershoot" to compensate and keep sync. The timestamps are compensatory for the dropped frames, had been CFR. Keep in mind the VFR version is usually missing frames (there are some exceptions) compared to a CFR recorded version. Fewer frames or fewer samples per time frame - means less precision overall, not more. But you might have a short section or "bursts" that are technically faster than 60/1 FPS (< 16.6666... ms delta per frame) if you examine the timestamps, but a previous section would have a low FPS . So greater precision in the short burst, but terrible precision in the low FPS section with many dropped frames. Overall there will be less precision, because you have fewer frames.



    Originally Posted by poisondeathray View Post
    Or if you "interpolated" or synthesized "inbetween" frames, such as optical flow methods, then you could have higher precision, because you have more samples per second. However, they can be prone to artifacts
    Good to know, do NOT want artifacts.
    Sometimes they can produce good results, especially some of the machine learning variants like RIFE, DAIN. It's very source dependent. The NLE versions of optical flow aren't great. If/when interpolation works, instead of inserted stutter duplicates, it could look like a real CFR version. It depends on the context and the source. But I see in a later post it's dance material - they generally interpolate poorly by traditional methods. RIFE can be ok sometimes. If you can salvage/improve a shot, sometimes it can be worthwhile exploring it



    I think I thought of a better question --- So I know I might have to accept whatever comes out after converting, but what if I used the VFR footage I have now, without converting it? Would I be better off not converting if i wanted to preserve frame relational integrity? Is that even possible since I still have to import it into NLE (DVResolve) to sync it to audio ?
    Almost all NLE's , editors have CFR based timelines . Many will convert it to CFR behind the scenes, others might have problems like sync issues because they didn't convert to CFR.
    Quote Quote  
  10. Originally Posted by LapisLazuliLicorice View Post
    Woah! This might be just what I need! Especially since I heard YouTube respects original frame rates. But wouldn't it eventually get misaligned as it goes through frame by frame? Because it will be cutting by a distance that is shorter than most of the frames, so there will be a little extra on each one, and eventually it will land equidistantly on two frames and have to choose one to use that is closer, but it would be 8 milliseconds off (which is a little less than half of one frame) ?
    Remember - there is some limitations, one is resolution of the PTS (usually very high for example MPEG-2 PTS resolution is 1/90000 s i.e. in theory you can have 90000 fps video), another one is limitations of the codec itself - there is not to many very high fps codecs capable to accommodate such high fps.

    Providing some example: lets assume your smallest delta PTS is 8 ms then VFR converted to 125 fps CFR should be perfect - you may after such conversion try to reduce frame rate to some more common by using for example motion converter.

    Originally Posted by LapisLazuliLicorice View Post
    I didn't even know VFR existed until I was trying to edit my footage. I would never willingly choose VFR, but now I have all this footage and I want to deliver as best I can. I'm a beginner and taking my mistakes in stride. I will start saving up for a real camera after this.
    VFR commonly is symptom that things are done in software that don't care... In theory modern display devices can be VFR type (albeit within quite limited scope) but they are rarely VFR compatible and usually they expect CFR at the input.
    Quote Quote  
  11. Member
    Join Date
    Jun 2022
    Location
    Dublin
    Search Comp PM
    This is complicated all right, my head is hurting. Its also possible to do vfr to cfr without losing any quality, no converting, transcoding or adding extra frames, I think so anyway. outputting to raw then exporting with corrected pts.

    https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20video
    Last edited by JN-; 15th Mar 2023 at 14:08.
    Quote Quote  
  12. Originally Posted by poisondeathray View Post
    There are only 60 possible "slots" you can place a frame in any given second if you're converting to 60/1 CFR - hence the 16.666ms constraint - and many of them are "already occupied" . You cannot have a quarter of a frame or some fractional frame. The "already occupied" spots are the existing VFR recorded frames with their timestamps. VFR to CFR algorithms only insert missing frames where there are gaps, or drops in the FPS.
    Well then it sounds like I'm trying to get water out of a stone, and I should stop doing that.

    Originally Posted by poisondeathray View Post
    Because your average FPS is 59.6, it suggests you're not missing very many frames. There are slightly different VFR to CFR algorithms, but you're not going to notice much difference in your case, because you are likely minimally variable
    Alright that alleviates much of my worries, thanks.

    Originally Posted by poisondeathray View Post
    But I see in a later post it's dance material - they generally interpolate poorly by traditional methods. RIFE can be ok sometimes. If you can salvage/improve a shot, sometimes it can be worthwhile exploring it
    Got it, so the odds are against me in this context. Good to know Optical Flow is the bottom of the barrel, so I won't burn valuable time on it. And I'll keep RIFE and DAIN on my list of things to study and experiment with.

    Originally Posted by poisondeathray View Post
    Almost all NLE's , editors have CFR based timelines . Many will convert it to CFR behind the scenes, others might have problems like sync issues because they didn't convert to CFR.
    Ok, so that's a no-go.

    Thank you for going on this deep dive with me. This is the level of detail I was craving.
    Quote Quote  
  13. Originally Posted by pandy View Post
    Providing some example: lets assume your smallest delta PTS is 8 ms then VFR converted to 125 fps CFR should be perfect - you may after such conversion try to reduce frame rate to some more common by using for example motion converter.
    Interesting... So what is "motion converter"? I tried googling it in different contexts but can't find anything on it. A similar idea was suggested to me on another forum - that I go high FPS - but then I was told I would lose any benefits as soon as I converted to my lower delivery FPS, so I had abandoned that idea. Is it a type of interpolation?
    Last edited by LapisLazuliLicorice; 15th Mar 2023 at 22:59.
    Quote Quote  
  14. Originally Posted by JN- View Post
    This is complicated all right, my head is hurting. Its also possible to do vfr to cfr without losing any quality, no converting, transcoding or adding extra frames, I think so anyway. outputting to raw then exporting with corrected pts.

    https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20video
    Brute Force - I didn't think of that! Just might be crazy enough to work. But how would I put it back together without manually examining 1,728,000 frames? Aren't all the pts already "correct" relative to the reduced number of frames that VFR produces? Does the algorithm exist that could sort them back under one frame rate?
    Quote Quote  
  15. Originally Posted by LapisLazuliLicorice View Post
    Originally Posted by JN- View Post
    This is complicated all right, my head is hurting. Its also possible to do vfr to cfr without losing any quality, no converting, transcoding or adding extra frames, I think so anyway. outputting to raw then exporting with corrected pts.

    https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20video
    Brute Force - I didn't think of that! Just might be crazy enough to work. But how would I put it back together without manually examining 1,728,000 frames? Aren't all the pts already "correct" relative to the reduced number of frames that VFR produces? Does the algorithm exist that could sort them back under one frame rate?

    That keeps the original bitstream (keep the same frames, none added or dropped from the original recording), but discards the timestamps. You assume some average constant framerate (e.g. 59.6) and you'll go slightly in and out of sync in places - that might be important for a dance coreographed to some music. The timestamps were what kept everything in sync because you have missing frames (some frames are displayed longer, effectively "duplicates" as "placeholders" to keep sync). You're still missing the same frames so there will be jumps in the motion in places instead of slight pauses vs if you converted to CFR via inserted duplicates.

    The exact number for the average framerate is determined by the total framecount and total duration. Hence the name, "Frames Per Second" . Total framecount / Total Duration in seconds
    Quote Quote  
  16. Member
    Join Date
    Jun 2022
    Location
    Dublin
    Search Comp PM
    I converted a sample phone footage using the method I mentioned earlier. Mediainfo: It was an original VFR frame rate of 59.701, Max 60, min 29.99, "real" frame rate 60. I selected to output at 60 fps I could see no problem, identical data rate and file size. The before and after GOP of 60 was the same ... IPPP ... I

    If you can supply a sample I can convert and then you can see if its what you need ? Maybe you have already done so. The scene I tested obviously wasn't a dance scene, just slow moving traffic, people etc. 2560 x 1440.
    Last edited by JN-; 16th Mar 2023 at 06:45.
    Quote Quote  
  17. Originally Posted by JN- View Post
    I converted a sample phone footage using the method I mentioned earlier. Mediainfo: It was an original VFR frame rate of 59.701, Max 60, min 29.99, "real" frame rate 60. I selected to output at 60 fps I could see no problem, identical data rate and file size. The before and after GOP of 60 was the same ... IPPP ... I
    You simply don't understand. Suppose I have a VFR video with 2000 frames. The first 1000 frames plays at 25 fps, 40 seconds. The second 1000 frames plays at 50 fps, 20 seconds. That's an average frame rate of 2000 frames divided by 60 seconds, 33.333 frames per second. If you convert to that constant average frame rate the first 1000 frames will play in 30 seconds, not 40 seconds. The second 1000 frames will also play in 30 seconds, not 20 seconds. So the video will be in sync with the audio at the very start and very end, but will be out of sync all through the middle. That is what poisondeathray was trying to explain to you.
    Quote Quote  
  18. Member
    Join Date
    Jun 2022
    Location
    Dublin
    Search Comp PM
    “You assume some average constant framerate (e.g. 59.6) and you'll go slightly in and out of sync in places - that might be important for a dance coreographed to some music.”

    I am pretty sure that I did understand PDR'S very apt description above. I made my comment / suggestion not as a perfect solution but simply one that might get the OP close to what he wants to achieve. I use that method on my own phone clips, but I do appreciate that my hobbyist clips don’t require the exactness of a dancing routine.
    Quote Quote  
  19. Originally Posted by poisondeathray View Post
    That keeps the original bitstream (keep the same frames, none added or dropped from the original recording), but discards the timestamps. You assume some average constant framerate (e.g. 59.6) and you'll go slightly in and out of sync in places - that might be important for a dance coreographed to some music. The timestamps were what kept everything in sync because you have missing frames (some frames are displayed longer, effectively "duplicates" as "placeholders" to keep sync). You're still missing the same frames so there will be jumps in the motion in places instead of slight pauses vs if you converted to CFR via inserted duplicates.
    Got it, so all those frames would now be assigned the exact same duration that is commensurate with their original average framerate, or even a new framerate.
    But yeah, that's a big NO for dancing. It canNOT be out of sync. That's worse than artifacts, and worse than stuttering.

    It's a cool concept though, now that I understand it. Might come in handy for another project so I'll keep it in my arsenal.
    Quote Quote  
  20. If anyone is still here- I have a plan now, could you let me know if the order makes sense?

    - convert VFR (MP4) 59.6 --> CFR (DNxHR) 59.6 FPS (FPS same as source, to cut down on duplicates and leave space for interpolation)
    - interpolate (FlowFrames) up to 60 FPS
    - import to NLE to sync audio
    - export to DNxHR
    - convert to H.264 UHD
    - upload to YT
    Last edited by LapisLazuliLicorice; 16th Mar 2023 at 22:34.
    Quote Quote  
  21. Originally Posted by LapisLazuliLicorice View Post
    If anyone is still here- I have a plan now, could you let me know if the order makes sense?

    - convert VFR (MP4) 59.6 --> CFR (DNxHR) 59.6 FPS (FPS same as source, to cut down on duplicates and leave space for interpolation)
    - interpolate (FlowFrames) up to 60 FPS
    - import to NLE to sync audio
    - export to DNxHR
    - convert to H.264 UHD
    - upload to YT

    I wouldn't do it that way, because inserted(interpolated) frames by flowframes are not necessarily in the correct locations (times). You will have the same issue of going in and out of sync, because your input into flowframes @ 59.6 is out of sync to begin with

    To do it properly , they would need to be interpolated specifically in the correct locations. e.g. VFR to CFR per "normal method" , resulting in duplicate frames placed in the correct locations (times) as "placeholders", then interpolate over the duplicates . There are scripts in avisynth , vapoursynth such as filldrops that can do it for duplicates based on detection thresholds, and manual functions as well where you specify the exact frames or ranges

    For something important, I'd want to manually verify that interpolated frames are ok, if not then keep a duplicate for that location (or the other option is a blend) . Also, if one model or algorithm doesn't "solve" a section , you can try some other method or setting. eg. there are some rare cases that mvtools2 breezes over some frames, but rife has problems with. mvtools2 itself has hundreds of settings. I posted some comparisons before, and helper functions for avs and vpy .
    Last edited by poisondeathray; 16th Mar 2023 at 22:48.
    Quote Quote  
  22. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Dnxhr will not do 59.6fps. As a pro intermediate codec, it is constrained to standard framerates (23.976, 24, 25, 29.97, 30, 50, 59.94, 60). It also has constraints on resolution options and bitrate options.
    Use a more generic lossless codec intermediate (e.g. lagarith, huffyuv, etc) until you get to a standard framerate.

    Btw, IIWY, I'd convert VFR 59.6 to CFR 59.6, then change the timebase and assume 59.94 or 60, depending. Then squeeze the audio to match & maintain sync (pitch-corrected, of course). Yes, it would be a speedup, but it would be a speedup of ONLY 0.5%, which the vast majority of humans would not be able to tell the difference, if not also presented compared with running clocks, running for quite some time. For reference NTSC 29.97 vs 30 is a 0.1% difference, equating to 108 FRAMES difference (a couple of seconds) per hour.

    Scott
    Quote Quote  
  23. I think you should start by checking exactly why your video is 59.6 fps. You can get the VFR timestamps with ffprobe. Here's an example drag-and-drop batch file:

    Code:
    echo entry,media_type,pkt_dts,pkt_dts_time,best_effort_Timestamp_time,duration,pkt_duration_time,ftype,coded# > "%~nx1.csv"
    "g:\program files\ffmpeg64\bin\ffprobe.exe" -v 32 -stats -y -hide_banner -i %1 -select_streams v -print_format csv -of csv -show_entries "frame=media_type,coded_picture_number,pkt_dts,pkt_dts_time,pkt_duration,pkt_duration_time,best_effort_timestamp_time,pict_type" >> "%~nx1.csv"
    Image
    [Attachment 69847 - Click to enlarge]


    That's from a CFR video (I don't have a VFR video handy). The output CSV file was opened in LibreOffice. Once you have identified the nature of the problem(s) you can deal with them accordingly.
    Quote Quote  
  24. Originally Posted by poisondeathray View Post
    I wouldn't do it that way, because inserted(interpolated) frames by flowframes are not necessarily in the correct locations (times). You will have the same issue of going in and out of sync, because your input into flowframes @ 59.6 is out of sync to begin with

    To do it properly , they would need to be interpolated specifically in the correct locations. e.g. VFR to CFR per "normal method" , resulting in duplicate frames placed in the correct locations (times) as "placeholders", then interpolate over the duplicates.
    Got it, once again my understanding was incomplete. I thought scanning for duplicates wouldn't be feasible or automatable, and I also thought the VFR > CFR conversion would have already translated pts variablity into duplicates just to get it to CFR, and then the stepping-up to 60 fps would be a second wave of duplicates that would be interspersed evenly by the interpolation algorithm, after deducting a bit from from every whole frame. Anyway, now that you told me the correct way, I'll gladly follow that. You've saved me hundreds of hours of trial & error on so many details, thanks a million!!
    Last edited by LapisLazuliLicorice; 18th Mar 2023 at 02:10.
    Quote Quote  
  25. Originally Posted by Cornucopia View Post
    Dnxhr will not do 59.6fps. As a pro intermediate codec, it is constrained to standard framerates (23.976, 24, 25, 29.97, 30, 50, 59.94, 60). It also has constraints on resolution options and bitrate options.
    Use a more generic lossless codec intermediate (e.g. lagarith, huffyuv, etc) until you get to a standard framerate.
    Did not know that. I would've been unpleasantly surprised mid-editing. Ok, I wrote down that alternative strategy.

    The audio squeezing plan I'm wary of: people that love a certain song and have memorized it might notice. Although I'm curious- if I do a test run, would it outperform the other methods? I'll keep it in the arsenal. Thanks for breaking down how to apply it in my case.
    Last edited by LapisLazuliLicorice; 18th Mar 2023 at 01:58.
    Quote Quote  
  26. Originally Posted by jagabo View Post
    I think you should start by checking exactly why your video is 59.6 fps... Once you have identified the nature of the problem(s) you can deal with them accordingly.
    You're right, I never even tried to classify the pattern before strategizing. This coming week I will sit down and run those. Thanks!
    Quote Quote  
  27. Hey poison death ray- so I thought I understood the process you explained, but now I'm trying to figure out what you meant by-

    Originally Posted by poisondeathray View Post
    VFR to CFR per "normal method"
    Did you mean an ffmpeg Drop & Duplicate conversion like the one below? And then interpolate over those duplicates?

    Code:
    ffmpeg -i <input> -filter:v fps=fps=60 <output>
    Or did you mean an ffmpeg conversion to DNxHR without changing FPS, like the one below? And then interpolate without changing FPS, and edit and deliver at whatever FPS comes out?

    Code:
    ffmpeg -i in.mp4 -c:v dnxhd -profile:v dnxhr_sq out.mov
    Or did you mean Shutter Encoder: MP4 --> DNxHR with Conform (by Drop?) to 60 FPS?


    ...Or was it something else?
    Quote Quote  
  28. Originally Posted by LapisLazuliLicorice View Post
    You're right, I never even tried to classify the pattern before strategizing. This coming week I will sit down and run those. Thanks!
    If it's a phone or similar device, usually an average FPS of 59.6 (assuming a base FPS of 60/1) means single drops sporadically spaced. For you that would be 7 or 8 frames every 1000 frames (you have 99.3 % of the frames) . Sometimes mediainfo will report min and max FPS along with the average. Large deviations and lower average FPS usually indicates more consecutive drops and bigger problems. 59.6 is not too bad , especially if the drops are not in critical locations, because the FPS is higher. If you blink most viewers miss the pause and jump in motion


    Originally Posted by LapisLazuliLicorice View Post
    Hey poison death ray- so I thought I understood the process you explained, but now I'm trying to figure out what you meant by-

    Originally Posted by poisondeathray View Post
    VFR to CFR per "normal method"
    Did you mean an ffmpeg Drop & Duplicate conversion like the one below? And then interpolate over those duplicates?

    Code:
    ffmpeg -i <input> -filter:v fps=fps=60 <output>

    Yes, or similar method. I haven't really used ffmpeg -vf fps too much for VFR to CFR, but it should give similar results . It's difficult to screw that part up with a high average FPS and relatively few dropped frames. On more variable videos, with lower average fps, you can get more variation in results between algorithms

    The inserted duplicates make up 59.6 => 60/1 (or whatever your desired CFR rate is) . They are "placeholders" for the dropped frames.

    The VFR timestamps are functionally the same thing - They display the current frame for twice as long 16.667ms *2 = 33.333ms - so it's a placeholder but without an encoded "physical" duplicate . Most people in your situation would just leave it at that and edit. It looks exactly like your current video , except it's CFR now.

    I typically use avisynth and filldrops or filldropsrife . The inserted duplicates in the script are lossless so the thresholds can be set lower (no compression differences, they are exact duplicates) and you don't need an encoded intermediate for that step . I don't think ffmpeg has a motion interpolation script based on thresholds for duplicates, and it's minterpolate filter has a memory leak. But again, interpolation can produce artifacts. I would double check the results, or use only the ones that look ok
    Quote Quote  
  29. Originally Posted by poisondeathray View Post
    If it's a phone or similar device, usually an average FPS of 59.6 (assuming a base FPS of 60/1) means single drops sporadically spaced.
    Or sometimes a drop to half frame rate to give the the CCD more times to gather light between frames (ie, longer exposures to reduce noise). In cases like this using the higher frame rate for a CFR encoding will maintain the exact frame times. For example a camera may start at 60 fps, drop to 30 fps, then go back to 60 fps. Each of the 30 fps frames can be duplicated to make that section 60 fps while maintaining the original start time of each original frame.

    But it's much more complex in the general case. Suppose you have a mix to 60 and 24 fps. You can't use 60 fps CRF because half of the the 24 fps frames will not start at the right time. Each of the 24p frames need to be displayed for 2.5/60 seconds. If you use a 2:3 repeat pattern the second frame will begin too soon. If you use a 3:2 repeat pattern the second frame will begin too late. You have to use 120 fps as your CFR in this case. Then each 24p frame can be duplicated for a total of 5 frames (120/5 = 24) and each 60 frame can be duplicated to 2 frames (120/2 = 60).

    With other mixes you may need to use a CFR of many thousands of frames per second if you insist on perfect timing. This quickly gets to be very impractical.
    Quote Quote  
  30. Don't cameras tend to try to play nice with their environment? I'm pretty sure my old smartphone does. If I run my Plasma TV at 60Hz and point the camera at it, I can generally see the rolling shutter in action for a brief period but it seems to lock onto the TV pretty quickly. If I change the TV to 50Hz the same thing happens until it syncs again.

    Would it be safe to assume that while the camera's adjusting itself, it'd be dragging the frame rate along for the ride?

    I'm fairly sure anything that doesn't output a constant light would have some effect. Florescent lights, for example. I know some LEDs used for (budget?) stage lighting don't put out a constant light, but use PWM or something similar to dim and change color. I filmed a band in a small venue last year and the LEDs looked like they were strobing on occasion, although at different speeds and at different times, which I'm sure confused the camera and even messed with the auto focus now and then.

    Speaking of rolling shutters.... if the OP's camera has one, then a frame doesn't represent a single moment in time as such, so maybe that'll give frame placement accuracy a different perspective.

    https://en.wikipedia.org/wiki/Rolling_shutter
    Last edited by hello_hello; 26th Mar 2023 at 01:24.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!