#8460 closed defect (needs_more_info)
H.264 VFR timestamp hazards (which means frame duration... or playback experience hazards)
Reported by: | gdgsdg123 | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
ffmpeg -y -i "123.avi" -c:v h264_nvenc -r 1 -g 1 -vsync vfr "temp.avi"
The timestamp of the 1st frame is delayed according to -r
(by 1/r exactly), while the rest of the timestamps remain unchanged (have verified this with more complex input source).
Which negatively affects the 1st frame's duration. (and the impact persists in further re-encodings)
ffmpeg -y -i "123.avi" -c:v h264_nvenc -r 1 -g 2 -vsync vfr "temp.avi"
The duration of the 2nd frame is influenced by -r
.
ffmpeg -y -i "123.avi" -c:v h264_nvenc -r 1 -g 3 -vsync vfr "temp.avi"
Appeared normal. (all timestamps are delayed accordingly)
ffmpeg -y -i "123.avi" -c:v libx264 -r 1 -g 1 -vsync vfr "temp.avi"
Normal.
ffmpeg -y -i "123.avi" -c:v libx264 -r 1 -g 2 -vsync vfr "temp.avi"
The duration of P-frames (the 2nd frame in this case) become 1/r. (absent timestamp information in the packet?..)
ffmpeg -y -i "123.avi" -c:v libx264 -r 10 -g 3 -vsync vfr "temp.avi"
Better demonstration of the above problem.
ffmpeg -y -i "123.avi" -c:v libx264 -r 10 -qp 0 -g 3 -vsync vfr "temp.avi"
Normal. (no P-frame in the output, due to the scenecut decision of x264)
Unsure if it's the encoder's fault or FFmpeg's.
Off-Topic
ffprobe -hide_banner -show_entries "frame" -select_streams v:0 -of "xml" "temp.avi"
ffprobe -hide_banner -show_entries "frame=best_effort_timestamp_time" -select_streams v:0 -of "compact=nk=1:p=0" "temp.avi"
...In case you don't know how to use FFprobe.
And in the world of CFR... the duration doesn't have to really exist.
Attachments (1)
Change History (4)
follow-up: 3 comment:2 by , 5 years ago
Resolution: | → needs_more_info |
---|---|
Status: | new → closed |
by , 5 years ago
Attachment: | ffprobe.7z added |
---|
Replying to gdgsdg123:
I heard that HandBrake (which also use x264) encodes videos in a manner similar to 90000 FPS VFR... (1:90000 time base)
If so, and the problem is on the encoder (x264), then the influence of the problem will be super obvious.
While there doesn't seem to be report on such things happening...
I find the problem to be container related...
Cannot reproduce:
AVI exclusive?..
Replying to gdgsdg123:
Just tested with a more common footage (YouTube Preview):
The problem seemed to
only occur on the last 2 frames... * and it influences B-frames too. Check the "PB_duration_quicktest.xml".Highlight (Line 5857 to 5858):
* After comparing the timestamps of the "Fly.mkv" (workaround'd) and the "PB_duration_quicktest.avi" I also find a lot of discrepancies between them... (yes, it means serious frame PTS shifts) (check the "Fly.txt" and the "PB_duration_quicktest.txt")
And further re-encoding based on the problematic file:
...ends in rather unpredictable timestamps. (check the "PB_duration_quicktest_re.txt")