This created a file I could use to compare to the 30 fps 480p files that I scaled to 1080p Y4M files to perform the comparison.Īuthor’s Note:During the actual project, I created the 30 fps comparison file in two stages, first creating the 60 fps Y4M file via the first argument, then converting that to 30 fps and seeking to the right frame via the third argument (substituting the 60 fps Y4M file for the input file). I fixed this with a simple seek command that advanced FFmpeg 1/60 of a second into the file before starting the conversion. As luck would have it, however, it threw out the wrong frame – I needed odd frames to compare to my encoded files, and this produced even frames. This command kept the same speed but threw out every other frame which is what I wanted. ffmpeg -i input_60.mp4 -filter:v "setpts=0.5*PTS" -pix_fmt yuv420p output_30.Y4M This sounded exactly what I wanted, so I tried this argument. Note that this method will drop frames to achieve the desired speed.” For example, if there are two successive frames shown at timestamps 1 and 2, and you want to speed up the video, those timestamps need to become 0.5 and 1, respectively.
According to the FFmpeg documentation, “The filter works by changing the presentation timestamp (PTS) of each video frame. To make a long story short, in FFmpeg-speak, I didn’t want to change the frame rate, I wanted to slow the video down, which you do with the setpts video filter documented here. In fairness, that’s what my argument asked FFmpeg to do, though clearly not what I wanted it to do. The frame rate looked correct, but when I loaded the file into the Moscow University Video Quality Measurement Tool and compared it to the 480p files I had scaled to 1080p files, I noticed the scores were abnormally low.Ī bit more analysis revealed that while FFmpeg had delivered the requested frame rate, it had done so by halving the frame rate and converting the one-minute file to two-minutes and preserving every frame. Here’s what MediaInfo said about the file I created. ffmpeg -y -i input_60.mp4 -pix_fmt yuv420p -vsync 0 -r 30 output_30.Y4M Here’s what I tried first, a command that converts the file into a Y4M file at 1080p resolution. Here’s what I came up with.īy way of background, here’s MediaInfo on the source file:
This assumption proved incorrect, and it cost me a morning to figure out a workaround. I’ve not performed measurements like this in the past and assumed that simply converting the 60 fps sources file to 30 fps via the “-r” option would convert from 60 fps to 30 fps and discard every other frame, which is what I needed.
A recent consulting project involved computing the VMAF, SSIM, and PSNR scores of 30 fps 480p video encoded from a p source file.
0 kommentar(er)
