Enhancement: Improve playback performance of intra x264 #34750

New Issue

Björn Sonnenschein · 2013-03-23T21:53:31+01:00

2013-03-23 21:53:31 +01:00

%%%Linux Mint 64, recent build from the bildbot.

When there are two x264 Clips in the timeline which overlap each other and you start playback, the first clip is played smoothly, but as soon as the second clip starts, the playback stutters. I guess this is a searching Issue that can't be solved in blender.

However, if the clips are coded as intraframe (gop 1), because all frames are I frames, playback should always be smooth (my pc is not bad).

Maybe it would make sense to play only the I frames of All-I clips wothout trying to resolve any non-existing gop structure?%%%

%%%Linux Mint 64, recent build from the bildbot. When there are two x264 Clips in the timeline which overlap each other and you start playback, the first clip is played smoothly, but as soon as the second clip starts, the playback stutters. I guess this is a searching Issue that can't be solved in blender. However, if the clips are coded as intraframe (gop 1), because all frames are I frames, playback should always be smooth (my pc is not bad). Maybe it would make sense to play only the I frames of All-I clips wothout trying to resolve any non-existing gop structure?%%%

Björn Sonnenschein commented

2013-03-23 21:53:31 +01:00

Changed status to: 'Open'

Thomas Dinges commented

2013-03-24 11:03:10 +01:00

%%%Please attach example files or upload some video snippets + blendfile to a share hoster so we can check this easily. %%%

Björn Sonnenschein commented

2013-03-24 12:01:39 +01:00

%%%Okay, here is a short clip: http://www.mediafire.com/?t0irtax1gb9888r
The clip is in the timeline of the attached .blend with relative path (same directory of the .blend).

I have noticed that the amount of stuttering is related to the video's bitrate. With higher bitrate the playback of the second clip in the timeline slows down and because of this i have uploaded a file with hight bitrate. Read speed of my pc is not the bottleneck. Kdenlive a similiar timeline smoothly, too.%%%

%%%Okay, here is a short clip: http://www.mediafire.com/?t0irtax1gb9888r The clip is in the timeline of the attached .blend with relative path (same directory of the .blend). I have noticed that the amount of stuttering is related to the video's bitrate. With higher bitrate the playback of the second clip in the timeline slows down and because of this i have uploaded a file with hight bitrate. Read speed of my pc is not the bottleneck. Kdenlive a similiar timeline smoothly, too.%%%

Sergey Sharybin commented

2013-03-25 08:20:56 +01:00

%%%No seek of non-existing frames happening in this case -- early out using single strip happening here. You could double-check this by generating timecodes for the strips.

And i guess actual issue is causes by playback sync. If i set it to No-Sync playback is always smooth on my laptop. Btw, i could not reproduce your issue -- playback is always bad if using AV-Sync option and it's always smooth when not using sync.

Also, is it a regression for you or this is something which never worked?%%%

%%%No seek of non-existing frames happening in this case -- early out using single strip happening here. You could double-check this by generating timecodes for the strips. And i guess actual issue is causes by playback sync. If i set it to No-Sync playback is always smooth on my laptop. Btw, i could not reproduce your issue -- playback is always bad if using AV-Sync option and it's always smooth when not using sync. Also, is it a regression for you or this is something which never worked?%%%

Björn Sonnenschein commented

2013-03-25 11:27:20 +01:00

%%%8 bit dnxhd was used as an intermediate codec until now, so I haven't tried x264 before.

I see, with no sync it is smooth, except at the beginning of each clip. You have a short frame freeze everytime when a new clip starts and it's first frames are not buffered yet (so refresh sequencer should be used before playing to reproduce this), you may also see that the timeline cursor hooks up for a little moment on the beginning of a strip.
And It seems that, for me, playback with av sync is smooth for a clip if the cursor is placed somewhere on it before playback starts.

%%%

%%%8 bit dnxhd was used as an intermediate codec until now, so I haven't tried x264 before. I see, with no sync it is smooth, except at the beginning of each clip. You have a short frame freeze everytime when a new clip starts and it's first frames are not buffered yet (so refresh sequencer should be used before playing to reproduce this), you may also see that the timeline cursor hooks up for a little moment on the beginning of a strip. And It seems that, for me, playback with av sync is smooth for a clip if the cursor is placed somewhere on it before playback starts. %%%

Sergey Sharybin commented

2013-03-25 11:54:01 +01:00

%%%No buffering happens at all (unless you're using prefetching). It's just opening FFmpeg context and initializing initial frame buffers which takes time.

Would try to look into issue with av-sync but that's not actually my area.%%%

%%%No buffering happens at all (unless you're using prefetching). It's just opening FFmpeg context and initializing initial frame buffers which takes time. Would try to look into issue with av-sync but that's not actually my area.%%%

Sergey Sharybin commented

2013-03-26 14:52:46 +01:00

%%%Joerg, afraid i'll hand this report to you.

From what i understand, it's not actually correct logic in AUD_OpenALDevice::AUD_OpenALhandle::getPosition(). Namely that lines inside if(!m_isBuffered) condition. Seems this would be correct if no ahead reading happens and all unprocessed buffers are queued to OpenAL. However, it doesn't seem to be so -- there're much more buffers read than queued to OpenAL, which makes position being really jumpy.

Not sure why SDL fails as well, but this function seems really suspicious for me.%%%

%%%Joerg, afraid i'll hand this report to you. From what i understand, it's not actually correct logic in AUD_OpenALDevice::AUD_OpenALhandle::getPosition(). Namely that lines inside if(!m_isBuffered) condition. Seems this would be correct if no ahead reading happens and all unprocessed buffers are queued to OpenAL. However, it doesn't seem to be so -- there're much more buffers read than queued to OpenAL, which makes position being really jumpy. Not sure why SDL fails as well, but this function seems really suspicious for me.%%%

Joerg Mueller commented

2013-03-31 09:50:09 +02:00

%%%I talked to the developer of OpenAL soft when I wrote that code and it's as accurate as it can. As long as the playback is smooth it should be off by 1 frame max.

Apart from that sound cannot be the bottleneck, as there is no sound is this movie file... I've tried the sync modes on my laptop here. No sync plays "smoothly" but with lower FPS and frame drop and AV sync both jump, but that's because the video decoding is too slow obviously and this is expected behaviour. In what way is it "bad" for you Sergey?

I cannot help with the video decoding stuff, maybe Peter can?! Maybe the video decoding code seeks too much when AV sync is on, if you know where the code is, try printing the frame numbers in the video every time a frame is requested and where it seeks.%%%

%%%I talked to the developer of OpenAL soft when I wrote that code and it's as accurate as it can. As long as the playback is smooth it should be off by 1 frame max. Apart from that sound cannot be the bottleneck, as there is no sound is this movie file... I've tried the sync modes on my laptop here. No sync plays "smoothly" but with lower FPS and frame drop and AV sync both jump, but that's because the video decoding is too slow obviously and this is expected behaviour. In what way is it "bad" for you Sergey? I cannot help with the video decoding stuff, maybe Peter can?! Maybe the video decoding code seeks too much when AV sync is on, if you know where the code is, try printing the frame numbers in the video every time a frame is requested and where it seeks.%%%

Peter Schlaile commented

2013-04-14 17:56:39 +02:00

%%%please keep in mind, that blender since version 2.5 doesn't do prefetching or multi-threaded rendering (there is no easy solution, because of the animation system rewrite).

In Blender 2.49 this was also more or less a hack.

We need to write a serious prefetch and thread-management system which interoperates well with the new animation system.
I have some ideas, how that should look like, but haven't found the time to write it down.

Smooth playback is essentially pure luck with the current code base, sorry.%%%

%%%please keep in mind, that blender since version 2.5 doesn't do prefetching or multi-threaded rendering (there is no easy solution, because of the animation system rewrite). In Blender 2.49 this was also more or less a hack. We need to write a serious prefetch and thread-management system which interoperates well with the new animation system. I have some ideas, how that should look like, but haven't found the time to write it down. Smooth playback is essentially pure luck with the current code base, sorry.%%%

Thomas Dinges commented

2013-07-07 01:21:47 +02:00

%%%Closing and marking as ToDo item. %%%

Thomas Dinges commented

2013-07-07 01:21:47 +02:00

Changed status from 'Open' to: 'Archived'

Thomas Dinges closed this issue

2013-07-07 01:21:47 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Enhancement: Improve playback performance of intra x264 #34750