#7644 closed enhancement (needs_more_info)
print warning for "-c:v copy" + "-ss non-key-frame"
| Reported by: | Hans Henrik Bergan | Owned by: | |
|---|---|---|---|
| Priority: | wish | Component: | undetermined |
| Version: | unspecified | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
as explained in comment 1 of https://trac.ffmpeg.org/ticket/7640#comment:1 , if you cut a video using -c:v copy + -ss and the frame at -ss is not a keyframe, then everything until the first keyframe is usually rendered black / random colors. it would be nice if ffmpeg printed a stderr warning in this scenario, warning that the black/random-color frames are expected behavior and not a bug in ffmpeg.
Change History (6)
comment:1 by , 5 years ago
comment:3 by , 5 years ago
@cehoyos i got from reading comment 1 of ticket #7640 , hopefully @erikbs can explain it.
(i don't know, but my best guess is that the color is player-implementation-defined and some video players decided to add a random color instead of black. - but that is just a guess, i don't know. - or maybe some video players render pre-key-frame from uninitialized memory, and random colors come from whatever garbage was in that uninitialized memory? malloc instead of calloc or a re-purposed block of memory?)
follow-up: 6 comment:5 by , 5 years ago
| Resolution: | → needs_more_info |
|---|---|
| Status: | new → closed |
Without an example for black/random-color frames I don't think this is a valid ticket.
(There is at least one codec for which it does happen, but this is a known and reported bug for this codec, not something unavoidable.)
comment:6 by , 5 years ago
Replying to cehoyos:
Without an example for black/random-color frames I don't think this is a valid ticket.
(There is at least one codec for which it does happen, but this is a known and reported bug for this codec, not something unavoidable.)
there is a real example in #7640
youtube-dl 'https://www.youtube.com/watch?v=PojTP32lE_o' -o in.mkv -q 2>/dev/null ffmpeg -i "in.mkv" -c:v copy -c:a copy -ss 00:11:32 -t 10.8 -y test.mkv
the resulting test.mkv has 2 seconds of black frames not present in the source.
(such a warning could also save people debugging time by making the problem obvious, and help prevent tickets like #7640 from being created)