substantial performance regression, ffmpeg6

[kallisti5]

Playing a 2k video on haiku was easily doable pre-ffmpeg6 without stuttering or lag.

After upgrading to ffmpeg6, there is substantial frameloss even at smaller window sizes.

MediaPlayer is also hanging

[kallisti5]

• Matrosoka / WebM (FFmpeg) H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
  • Playback ok.
  • 1920 x 1080, 24fps

• Matrosoka / WebM (FFmpeg) Google VP9
  • Playback studdering after upgrade
  • 3840 x 2160, 25 fps

[kallisti5]

Decoding via CLI shows:

_InitFromTrack(): keyframes: 1, frame count: 15191038800000
MediaTrackVideoSupplier::_SwitchFormat() - preferred color space: B_YUV420
[swscaler @ 0x118dcc083dd0] No accelerated colorspace conversion found from yuv420p to bgra.
MediaTrackVideoSupplier::_SwitchFormat() -  codec changed colorspace of decoded format (B_YUV420 -> B_RGB32)!
should skip -1 lines at bottom!
BMediaEventLooper: SchedulingLatency is 100
BMediaEventLooper: SchedulingLatency is 100
VideoProducer: dropped frame (70) (perf. time 2800000)
VideoProducer: dropped frame (71) (perf. time 2840000)
VideoProducer: dropped frame (73) (perf. time 2920000)
VideoProducer: dropped frame (75) (perf. time 3000000)
VideoProducer: dropped frame (76) (perf. time 3040000)
VideoProducer: dropped frame (77) (perf. time 3080000)
VideoProducer: dropped frame (78) (perf. time 3120000)
VideoProducer: dropped frame (80) (perf. time 3200000)
VideoProducer: dropped frame (81) (perf. time 3240000)
VideoProducer: dropped frame (82) (perf. time 3280000)
.
.

so it appears with ffmpeg6 our performance has suffered on video which tests our decoding abilities.

[kallisti5]

Here's a good test media:

• ​https://archive.org/download/NASA-Ultra-High-Definition/Scott4kUhd.mov

I used to be able to power through playing this on my Ryzen, now it barely works.

Of note, only one CPU core is loaded during playback.

[pulkomandy]

We can configure ffmpeg to decode on multiple threads, apparently this is not the default, was it before?

[kallisti5]

Unsure on multiple threads being default. Here's some extra data points:

• ffplay rendering under mesa 23 + libglvnd broken (a different issue)
• ffplay 4 renders the video smoothly under mesa 22
• ffplay 6 renders the video smoothly under mesa 22
• MediaPlayer ffmpeg 4 renders the video smoothly
• MediaPlayer ffmpeg 6 can't keep up and drops frames

[kallisti5]

One more data point:

• ffplay 4 == small load on all cores
• ffplay 6 == small load on all cores
• MediaPlayer + ffmpeg 6 == one core maxed out
• MediaPlayer + ffmpeg 4 == unknown

[waddlesplash]

Fixed in hrev57688.

[madmax]

[deleted, pointless after the fix]

[waddlesplash]

Well that's interesting. What happened between -1 and -3?

[madmax]

Replying to waddlesplash:

Well that's interesting. What happened between -1 and -3?

Assembler fixes to be able to build with newer binutils, nothing interesting for this ticket.

Bisection points to hrev57461. Reverting that (and resolving the conflict) also returns to multithreaded decoding.

[pulkomandy]

The reuse of fCodecContext may be a problem, I think the thread count is set to 0when the context is allocated (meaning to use the default value), set to 1 by a firt call to avcodec_open, and not reset before the next call?

[waddlesplash]

I think the real difference may be that fCodecContext is initialized with a NULL codec before that and a non-NULL codec in hrev57461, and so the defaults may be different?

[waddlesplash]

It looks like ffplay uses a NULL codec when creating the context and does not explicitly set thread count, so, let's see about doing that instead.

[waddlesplash]

Change amended in hrev57693.

[kallisti5]

Adding a quick comment to note that the performance regressions indeed seem to be fixed on hrev57700. Videos play as expected now.

I get a reasonable load of 0-20% on all cores playing 2k video.

Thanks!