vd_lavc: ensure decoder state is valid after reinit#17490
vd_lavc: ensure decoder state is valid after reinit#17490kasper93 wants to merge 2 commits intompv-player:masterfrom
Conversation
kasper93
force-pushed
the
hwdec_fix
branch
2 times, most recently
from
ceb2a77 to
31943d7
Compare
philipl
left a comment
philipl
left a comment
There was a problem hiding this comment.
Nice!
I have been running into a problem when using hwdec=vulkan and trying to seek through formats like mpeg-ts where you aren't guaranteed to seek to a key frame.
I am basically guaranteed in this situation that the hwdec would freeze and I'd need to ctrl-c mpv. I'm sure there's some nvidia specific issue there, but with this patch, I can't get it to freeze and I can seek as much as I want with no problems. And it makes sense that if the issue was feeding unusable frames into the decoder, that this would fix it.
| if (!ctx->avctx) | ||
| return AVERROR_EOF; | ||
|
|
||
| if (ctx->wait_for_keyframe && pkt) { |
There was a problem hiding this comment.
stupid question but is there guaranteed to be a keyframe at some point?
There was a problem hiding this comment.
In theory I believe you can craft a file that's only P frames, has no reference picture.
There was a problem hiding this comment.
stupid question but is there guaranteed to be a keyframe at some point?
That was my concern too. Not sure how to handle such possibility.
In theory I believe you can craft a file that's only P frames, has no reference picture.
Please provide a sample file, thanks.
There was a problem hiding this comment.
Can't even download it back now.
There was a problem hiding this comment.
test.mp4
maybe? lol
[in#0 @ 000001c198281e80] Format mov,mp4,m4a,3gp,3g2,mj2 detected only with low score of 1, misdetection possible!
[in#0 @ 000001c198281e80] moov atom not found
[in#0 @ 000001c19824c780] Error opening input: Invalid data found when processing input
There was a problem hiding this comment.
I guess, we will merge, break everyones files and see.
There was a problem hiding this comment.
thought 1:
- remember where the last keyframe was and seek back to that location, start decoding from there and only emit frames once we have reached the old timestamp
- (or does the player core already have logic that handles this? it sounds familiar)
thought 2:
- put some hardcoded upper limit at least
There was a problem hiding this comment.
thought 1
This is already done, our seeking is always seeking on key frames, but seeking is not synchronized with decoder reinit
thought 2
I think I will do that or limit this only to hwdec, where at least the codecs supported by hwdec should have parsers in ffmpeg, so we get keyframe info. And let some some obscure formats be decoded as is
thought 3
sync the reinit sequence with seek, but this looks like major pita and hacks.
This fixes dynamic hwdec switching, which would often fails, because hw decoder were feed data without context, which caused decoding errors, which in turn disabled hwdec. command.c does queue_seek() after decoder reinit, but it may already be too late, by the time seek to keyframe finishes. Fix this, by just discarding the data until we have safe point to start decoding again. This should also fix cases, when media file is cut in a way that would cause decoding errors at the start. Fixes: mpv-player#17484
4 participants
This fixes dynamic hwdec switching, which would often fails, because hw decoder were feed data without context, which caused decoding errors, which in turn disabled hwdec.
command.c does queue_seek() after decoder reinit, but it may already be too late, by the time seek to keyframe finishes.
Fix this, by just discarding the data until we have safe point to start decoding again.
This should also fix cases, when media file is cut in a way that would cause decoding errors at the start.
Fixes: #17484