This is not going to be a great bug report, and I might need some help complementing it with whatever info you might need, I apologize in advance.

I'm rendering a QMediaPlayer onto a QGraphicsItem, and I want to be able to step frames back or forward. I've implemented this feature like this:

    connect(controls, &PlayerControls::next, m_player, [this] {
        QVideoFrame currentFrame = m_player->videoSink()->videoFrame();
        qint64 currentEnd = currentFrame.endTime() / 1000;
        m_player->setPosition(currentEnd + 1);
    });
    connect(controls, &PlayerControls::previous, m_player, [this] {
        QVideoFrame currentFrame = m_player->videoSink()->videoFrame();
        qint64 currentStart = currentFrame.startTime() / 1000;
        m_player->setPosition(currentStart - 1);
    }); 

This kind of works, but if the CPU load is high, the QMediaPlayer::setPosition operation will overshoot with a couple of frames. Here's some output from my code:

Seek forward to 3157961
New frame at 3157960
New frame at 3158000

Seek back to 3157999
New frame at 3157960
New frame at 3158000

I've debugged the code a bit but not sure i fully grasp the inner workings of all the decoder threads. One thing I've noticed is that PlaybackEngineObject::scheduleNextStep is run excessively (1k+ times) when doing this QMediaPlayer::setPosition on a paused video between QFFmpeg::StreamDecoder0 and QFFmpeg::StreamDecode1 threads.

I've confirmed that av_seek_frame is just run once, but avcodec_receive_frame gets called multiple times, and that the demuxer and 2 stream decoders gets unpaused.

I tried the above code in the player example included in the qtmultimedia repo, but it rarely repros there as I assume there's less things going on on the main thread maybe?

In any case I'm happy to provide any other information or if anyone has any ideas of what I could debug to figure this one out.