Not only does this not solve the first error, it causes another one. Now, not only will the file play at the wrong speed, but it will also drop frames.
So you are saying that VP Project Properties set at 59.94 fps incorrectly plays 59.94 fps media. Please explain how that could possibly be the case. If you have 59,94 fps media, what fps rate do you want Vegas Pro to be set at in Project Properties?
I just spotted the upload sample clip... the reason it doesn't edit or play correctly in Vegas is because the metadata text in the clip header does not match the frames actually in the clip. It appears that the clip was originally created by ffmpeg and then processed with some sort of AI enhancement plugin that changed the framerate form 59.94 to 60.43 without updating the metadata. I set the Vegas project to 60.43 which seems to make it play fine. Here's what I got from MediaInfo followed by the analysis of a proprietary frame-prober:
General Complete name : C:\Users\hv\Downloads\test59.94fps.mov Format : MPEG-4 Format profile : QuickTime Codec ID : qt 0000.02 (qt ) File size : 640 MiB Duration : 2 s 36 ms Overall bit rate mode : Variable Overall bit rate : 2 635 Mb/s Frame rate : 59.940 FPS major_brand : qt minor_version : 512 compatible_brands : qt videoai : Enhanced using prob-3; mode: relative to auto; revert compression at 0; recover details at 0; sharpen at 50; reduce noise at 0; dehalo at 0; anti-alias/deblur at 0; focus fix Off; and recover original detail at 20. Changed resolution to 3840x2160 encoder : Lavf60.20.100 Video ID : 1 Format : ProRes Format version : Version 0 Format profile : 422 HQ Codec ID : apch Duration : 2 s 36 ms Duration_LastFrame : -17 ms Bit rate mode : Variable Bit rate : 2 615 Mb/s Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 59.940 (60000/1001) FPS Color space : YUV Chroma subsampling : 4:2:2 Scan type : Progressive Bits/(Pixel*Frame) : 5.259 Stream size : 640 MiB (100%) Writing library : Apple
--- official format: ProRes --- official codec: ProRes 422 HQ --- official bit rate: 0 --- overall bitrate: 0 --- start timecode: 0, drop-frame:0 Detected 1 video channels Total bitrate: 0 channel # 0 --- codec: ProRes --- content width: 3840 --- content height: 2160 --- source x: 0 --- source y: 0 --- source width: 3840 --- source height: 2160 --- frame rate: 60.43 --- scan: Progressive --- colorspace: YCbCr --- subsampling: 422 ----transer characteristics: Unknown --- max bit rate: 0 --- bit rate: 2635998176 --- bit depth: 0 --- frame count: 123 --- frame map count: 123 --- start offset: 0 --- duration (sec): 2.03541 --- pixel aspect ratio: 1:1 --- image aspect ratio: 3840:2160 --- largest compressed frame size: 5476062 --- average compressed frame size: 5452586 --- GOP histogram : 123 @ 1 [ maxGOPlen=1 ] --- max GOP length: 1 --- profile and level: 0x0 --- profile constraint: 0x0 --- NRT codec: --- fourcc: apch --- rotation: 0
Not quite -- the ProRes file is created by a program using ffmpeg.exe (original source file is mp4/H264).
How did you extract this information?
I'm not free to share that but the frame-rate is consistent with what ffprobe reports:
PS C:\Users\hv\Downloads> ffprobe -hide_banner 'test59.94fps.mov' Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test59.94fps.mov': Metadata: minor_version : 512 major_brand : qt compatible_brands: qt videoai : Enhanced using prob-3; mode: relative to auto; revert compression at 0; recover details at 0; sharpen at 50; reduce noise at 0; dehalo at 0; anti-alias/deblur at 0; focus fix Off; and recover original detail at 20. Changed resolution to 3840x2160 encoder : Lavf60.20.100 Duration: 00:00:02.04, start: 0.000000, bitrate: 2636045 kb/s Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv422p10le(progressive), 3840x2160, 2636036 kb/s, 60.43 fps, 59.94 tbr, 60k tbn (default) Metadata: handler_name : VideoHandler vendor_id : FFMP encoder : Lavc60.37.100 prores_ks
So Vegas is using bad information, because the packets have the frame time clearly described as "dts_time=0.016683", which is 59.94fps.
Besides, even the ffprobe screenshot shows the correct fps (59.94 tbr)
Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv422p10le(progressive), 3840x2160, 2636036 kb/s, 60.43 fps, 59.94 tbr, 60k tbn (default)
[PACKET]
codec_type=video
stream_index=0
pts=0
pts_time=0.000000
dts=0
dts_time=0.000000
duration=1001
duration_time=0.016683
size=5475743
pos=36
flags=K__
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=1001
pts_time=0.016683
dts=1001
dts_time=0.016683
duration=1001
duration_time=0.016683
size=5478626
pos=5475779
flags=K__
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=2002
pts_time=0.033367
dts=2002
dts_time=0.033367
duration=1001
duration_time=0.016683
size=5478905
pos=10954405
flags=K__
[/PACKET]
As an fyi, I tried a repackage with ffmpeg on the clip you uploaded and it did not fix it. Only thing that worked was a transcode with the prores_ks codec. That generated a file size of 463,637 KB with both fps and tbs equal to 59.94 as per ffprobe. I tried a variety of bits_per_mb values but none yielded the file size of your original clip. This command line yielded a larger clip if that's what you are going for:
ffmpeg7g -i "D:\TEST Clips\BadProres\test59.94fps.mov" -c:v prores_ks -profile:v hq -bits_per_mb 2048 -y "prores(bits_per_mb=2048).mov"
Resultant ffprobe output looks like this:
PS D:\TEST clips\BadProres> ffprobe -hide_banner 'prores(bits_per_mb=2048).mov' Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'prores(bits_per_mb=2048).mov': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt encoder : Lavf61.1.100 Duration: 00:00:02.05, start: 0.000000, bitrate: 2766416 kb/s Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv422p10le(progressive), 3840x2160, 2766409 kb/s, 59.94 fps, 59.94 tbr, 60k tbn (default) Metadata: handler_name : VideoHandler vendor_id : FFMP encoder : Lavc61.3.100 prores_ks
You might consider adjusting your workflow to do the AI processing on the original clip first and doing the ffmpeg transcode to prores last using the latest v7. And contacting the author of the AI utility for advice or a fix. Personally, I'd just ditch it and use Vegas for everything. Vegas AI fx is pretty good and undergoing continuous development.
Your sample file does not have an audio track. Does your external application have the option of creating a still image sequence? If so, you can avoid the whole mess.
@rgr said: "ShutterEncoder uses ffmpeg -- and ffmpeg couldn't handle it."
It looks as if Shutter Encoder handled it for me.
Not only does this not solve the first error, it causes another one. Now, not only will the file play at the wrong speed, but it will also drop frames.
So you are saying that VP Project Properties set at 59.94 fps incorrectly plays 59.94 fps media. Please explain how that could possibly be the case. If you have 59,94 fps media, what fps rate do you want Vegas Pro to be set at in Project Properties?
I don't know what's unclear here. Vegas recognizes the file as 60fps and plays it that way instead of the correct 59.94fps. If you change the project fps to 59.94, the movie will still play as 60fps, but some frames will be removed to conform with the new fps (similarly, if you set the project to 30fps, half of the frames will be removed).
@rgr said: "ShutterEncoder uses ffmpeg -- and ffmpeg couldn't handle it."
It looks as if Shutter Encoder handled it for me.
Great. It seems to work -- but the new clip length is ~20s longer in the MediaInfo screenshot.
But in the meantime I found another way -- loading into VirtualDub and copying as DirectCopy also fixes the framerate.
Nevertheless, Vegas should take the framerate not from information values, but from dts points. I have already noticed that it also incorrectly handles gaps in aac files and shortens the audio track by the value of these gaps.
The file import module in Vegas has long been in need of significant improvement.
Do other NLEs work by taking data from dts points?
@rgr said: "It seems to work -- but the new clip length is ~20s longer in the MediaInfo screenshot."
The Shutter Encoder derived clip is not 20s longer. It is 20ms (20/1000 seconds, 0.020 seconds) longer.
@rgr said: "It seems to work -- but the new clip length is ~20s longer in the MediaInfo screenshot."
The Shutter Encoder derived clip is not 20s longer. It is 20ms (20/1000 seconds, 0.020 seconds) longer.
Of course you're right :)
But from the difference in file size I assume that Shutter Encoder simply recoded the file. Is there a preview of the command that goes to ffmpeg?
@rgr asked: "Is there a preview of the command that goes to ffmpeg?"
If you right click in the "Progress Status" area you get an option to Show Console.
I rarely do.
Thanks -- I see it does re-encode. So VirtualDub (Direct Stream Copy) remains the only option for lossless repair of such a file for now.