[FFmpeg-trac] #9377(undetermined:new): QSV MPEG2 => H264 transcode PSNR dropped by 32%

[FFmpeg]

#9377: QSV MPEG2 => H264 transcode PSNR dropped by 32%
-------------------------------------+-------------------------------------
             Reporter:  eero-t       |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by wenbin,chen):

 Replying to [comment:9 eero-t]:
 > According FFmpeg documentation, default for "-vsync" is "auto" which
 selects either "cfr" or "vfr".     Because I specified bitrate, not FPS, I
 assume FFmpeg to have selected VFR, which seems to drop timestamp only if
 consecutive frames would have duplicate timestamp.

 According to my debug, it chooses VSCFR which is a subset of CFR

 >
 > Are you saying that this is MediaSDK timestamp handling bug exposed by
 the FFmpeg change (to actually tell MediaSDK that there was no timestamp
 on some frame), one that can be only fixed on MediaSDK side? (will you
 file bug?)

 Not sure if it is bug, because all timestamp are correct except the first
 frame which is set to 0. I track the process how MediaSDK decode. For this
 video, the timestamp that ffmpeg passes to MSDK are all NOPTS, and
 MediaSDK can only get timestamp from B frame and it guess timestamp for
 other frames (I and P). The first two frames are I and P frame, so MSDK
 guess them wrong.

 >
 > As PSNR / SSIM calculations do frame-by-frame comparison, any change in
 frame timestamps during transcoding would make things go wrong as it
 affect frame content => should I '''always''' use "-vsync passtrough" (and
 "-an") on transcode operation intended for PSNR / SSIM calculations? And
 for performance comparisons?

 You'd better add this option in case ffmpeg inserts or removes frames and
 you don't know.

 >
 > PS. Is the cause for my other (more recent) PSNR bug similar:
 https://trac.ffmpeg.org/ticket/9481 ?

 I will check this issue.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9377#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker