Offline renderer not working anymore #219
Comments
|
can you try binaries from github actions to find out which commit breaks? |
|
Framework at commit [1ee41322] ensure all packet fifo set same max when buffering does produce the bug, Not all videos get stuck so i guess this is a concurrency issue. Regards |
|
I expect that commit can fix the frozen but not introduce the frozen. I need your test program to debug, can you send me a binary? |
|
I sent you a link via email |
|
Are you able to reproduce the bug ? Do you have time available to work on this ? Regards |
|
Yes. Working on it. |
|
in heavym exported video all frames are the same. in boxes example + the latest sdk, i keep a few video items, frames after seek are correct. I also tested |
|
renderVideo() return value is correct in boxes example, what about heavym? |
It is not correct in HeavyM no. The following is HeavyM code, logs below show that renderVideo always return the same timestamp, each one is stuck somewhere between 5000 ms and 7000 ms. void MDKPlayer::render()
{
/* [.........] */
const auto renderedPos = m_mdkPlayer->renderVideo(this) * 1000.f;
qDebug() << this << " renderedPos = " << QString::number(renderedPos)
<< " currentPosition = " << QString::number(m_currentPosition)
<< " difference = " << QString::number(m_currentPosition - renderedPos);
/* [.........] */
}
bool MDKWrapper::incrementTimeAndFrame(const double elapsed_msec)
{
/* [.......] */
m_currentPosition += elapsed_msec * m_speed;
/* [.......] */
qDebug() << this << " seek " << QString::number(m_currentPosition);
m_mdkPlayer->seek(
m_currentPosition,
mdk::SeekFlag::FromStart,
[doneSeekingCond, doneSeekingMutex, doneSeeking](auto)
{
std::unique_lock lock(*doneSeekingMutex);
*doneSeeking = true;
doneSeekingCond->notify_one();
});
constexpr int waitingTime_sec(10);
std::unique_lock doneSeekingLock(*doneSeekingMutex);
doneSeekingCond->wait_for(doneSeekingLock, std::chrono::seconds(waitingTime_sec), [doneSeeking]{ return *doneSeeking; });
if (!doneSeeking) qWarning() << "Failed to seek " + QString::fromStdString(m_mediaPath) + " (MDKWrapper::incrementTimeAndFrame)";
m_newFrameReadyCond.wait_for(newFrameReadyLock, std::chrono::seconds(waitingTime_sec), [this]{ return m_hasNewFrameReady.operator bool(); });
if (!m_hasNewFrameReady.operator bool()) qWarning() << "No frame ready in" + QString::fromStdString(m_mediaPath) + " (MDKWrapper::incrementTimeAndFrame)";
}Logs |
unit is second, precision is 1 microsecond what about seek callback position value? |
|
btw, why do you seek for every frame? |
Thanks for the clarification
The seek callback value is correct
I need the video to be at the correct timestamp for each frame of the export. |
It's weird. I keep only 1 video in heavym, same result. but in boxes example renderVideo() result is correct.
no, it will seek to the same position multiple times. Maybe you can use
|
Yes i know that is, previous frameworks make only a few video freeze (same code), but the recent frameworks make the bug more likely to happen (to the point it always happen).
No I cannot, it seems simple for a scenario where the timeline only plays videos from start to finish but in reality the timeline can be setup in many ways, with cues to trigger sequences, videos can be restarted throughout etc... Changing the method will impact so much code that it's going to be a huge mess. Moreover the advantage of this method is that the renderer has the same code than inline rendering, it's just the way we ask for a new frame that changes (one is realtime, the other one is done step by step) |
I tried the method you suggested on a simple case to see if results were promising or not and it was not very successfull anyway : videos would play at non constant rate in export, sometime speeding up or slowing down. Have you been able to find why renderVideo and seek give a different timestamp result ? Regards |
|
Do you have arm64 heavym? It's too slow to open on my mac |
Unfortunately we don't, we need to switch to Qt 6 to compile an arm64 version and we have not yet gone through this work as this involves many breaking changes. |
|
Hi |
|
no |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi
In our software, we have a video export functionnality that allows the user to export its projection mapping in the form of a video.
In this case we have an offline version of our renderer (as opposed to realtime) and we pause videos in the scene and seek the correct timestamp for every frame. (seek incremented timestamp -> wait for seeking done and new frame ready callback -> render frame -> loop)
It seems that the latest MDK version does not produce the image associated with timestamp accurately anymore and videos appear to be frozen when seeked incremently in paused state.
Does that ring a bell on your side ?
Could this commit be the cause of this ? [ecbd37db] ffmpeg: skip read when stream paused
Regards
Adrien
The text was updated successfully, but these errors were encountered: