You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looked into that today, and I believe the 6th frame is produced by the FPS filter. The test asks for "P720p30fps16x9" profile, but the input video is 25FPS (which I checked ffprobe -show_frames -unit: frame duration is 0.04s or 40ms). Now converting from 25FPS to 30FPS requires adding 5 frames per second, or one additional frame every five original frames. This is what I believe happens here. To be more precise, these are original video timestamps:
pkt_pts_time=1.480000 s
pkt_pts_time=1.520000 s
pkt_pts_time=1.560000 s
pkt_pts_time=1.600000 s
pkt_pts_time=1.640000 s
So original video has 5 frames over 0.16s
And transcoded video timestamps:
pkt_pts_time=1.466016 s
pkt_pts_time=1.499349 s
pkt_pts_time=1.532682 s
pkt_pts_time=1.566016 s
pkt_pts_time=1.599349 s
pkt_pts_time=1.632682 s
So transcoded video has 5 frames over 0.166666s. Not sure why the timestamps are shifted (I mean why the first frame of transcoded video doesn't repeat the timestamp of the first frame of original video), but I guess this is how filter works.
I also verified my theory by invoking the test with "P720p25fps16x9" profile, thus getting rid of FPS filter. The results were as expected, 5 output frames. My conclusion is: this is not really a bug, transcoder is behaving properly.
Add fix for failing test.
Input segment has 5 frames and produced output seams to repeat second frame, giving 6 frames in output.
Input:
Output:
The text was updated successfully, but these errors were encountered: