Opened 4 months ago

Closed 3 months ago

Last modified 3 months ago

#7644 closed enhancement (needs_more_info)

print warning for "-c:v copy" + "-ss non-key-frame"

Reported by: hanshenrik 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 Changed 4 months ago by hanshenrik

(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 Changed 4 months ago by cehoyos

Please explain how you get “random colours”.

comment:3 Changed 4 months ago by hanshenrik

@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 months ago by hanshenrik (previous) (diff)

comment:4 Changed 4 months ago by v0lt

I have a similar bug #7651.

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

comment:5 follow-up: Changed 3 months ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to 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 in reply to: ↑ 5 Changed 3 months ago by hanshenrik

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 3 months ago by hanshenrik (previous) (diff)
Note: See TracTickets for help on using tickets.