Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#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 Hans Henrik Bergan, 4 years ago

(such a warning could also save people debugging time by making the problem obvious, and help prevent tickets like #7640 from being created)

comment:2 by Carl Eugen Hoyos, 4 years ago

Please explain how you get “random colours”.

comment:3 by Hans Henrik Bergan, 4 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?)

Last edited 4 years ago by Hans Henrik Bergan (previous) (diff)

comment:4 by v0lt, 4 years ago

I have a similar bug #7651.

Last edited 4 years ago by v0lt (previous) (diff)

comment:5 by Carl Eugen Hoyos, 4 years ago

Resolution: needs_more_info
Status: newclosed

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.)

in reply to:  5 comment:6 by Hans Henrik Bergan, 4 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.

Last edited 4 years ago by Hans Henrik Bergan (previous) (diff)
Note: See TracTickets for help on using tickets.