Opened 4 years ago

Closed 3 years ago

#12319 closed Bug Report - General (Fixed)

Switching LiveTV channels breaks VAAPI acceleration

Reported by: Martin <bugs@…> Owned by: JYA
Priority: major Milestone: 0.28
Component: MythTV - Video Playback Version: 0.27.4
Severity: medium Keywords:
Cc: Stuart Auchterlonie Ticket locked: no

Description

I have VAAPI acceleration configured for TV playback and this works fine for first channel watched during LiveTV (~20% cpu usage). After switching channels, cpu usage goes up to ~140% and 'perf top' introduces swscaler library being used. Stopping LiveTV and reentering works around the problem.

mythtv 2:0.27.4+fixes.20141108.0f0e678-0ubuntu0mythbuntu2

I watch DVB-C HD (H.264) content.

Attachments (2)

mythfrontend.log (10.5 KB) - added by Martin <bugs@…> 4 years ago.
Log of a LiveTV session with exactly one channel switch at 08:55:42
vaapi_alternating.log (92.1 KB) - added by Frank Phillips <fphillips81@…> 4 years ago.
-v playback log. vaapi -> ffmpeg -> vaapi

Download all attachments as: .zip

Change History (12)

Changed 4 years ago by Martin <bugs@…>

Attachment: mythfrontend.log added

Log of a LiveTV session with exactly one channel switch at 08:55:42

Changed 4 years ago by Frank Phillips <fphillips81@…>

Attachment: vaapi_alternating.log added

-v playback log. vaapi -> ffmpeg -> vaapi

comment:1 Changed 4 years ago by Frank Phillips <fphillips81@…>

Confirmed on latest fixes/0.27. It appears the codec id is changing from MPEG2 VAAPI to MPEG2, for whatever reason.

Related: #11746

comment:2 Changed 4 years ago by alex.l.williamson@…

I'm seeing the same thing, mythtv-frontend-0.27.4-2.fc21.x86_64

The behavior is actually that vaapi works every other channel change, which perhaps suggests that the odd number changes detect some vaapi resource as already in use by the current playback.

comment:3 Changed 4 years ago by Cédric Schieli <cschieli@…>

I can confirm the "works every other channel change" thing on my frontend built from an old fixes/0.27 snapshot (926bb8d2427388f3f051ee642bd7b629b4d18601)

comment:4 Changed 4 years ago by Cédric Schieli <cschieli@…>

The root cause is that VAAPIContext::IsFormatAccelerated? always returns false if a VAAPIDisplay already exists which is the case when switching from one LiveTV channel to another.

This was introduced in 501bd3ebde353bd077c604783e78baabf6df4a96 to allow PiP with VAAPI.

Reverting this commit has fixed the issue for me (I'm not using PiP).

comment:5 Changed 4 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added

The true fix may actually be to reuse the existing context. I have vaapi on one of my systems so i'll be able to test anything we may come up with

comment:6 Changed 4 years ago by JYA

Status: newaccepted

comment:7 Changed 4 years ago by jim_32766@…

I too can confirm that vaapi and ffmpeg are alternating as I change channels. I have also noticed when first entering a channel, even though vaapi is selected, the frames decoded/free runs a very low ratio, e.g. 4/19, and the playback is not smooth. A short pause, just a second, before resuming play results in a much higher ratio, e.g. 21/2, and the playback is smooth. I don't know if this is related but wanted to pass the information along.

comment:8 Changed 4 years ago by alex.l.williamson@…

Is this fixed anywhere? If not, could someone please look into it? I'm still seeing this on mythtv-frontend-0.27.4-6.fc22.x86_64 and explaining to the wife how to determine when this is happening and how to re-select the channel got me the are-you-f'ing-kidding-me look.

comment:9 in reply to:  8 Changed 4 years ago by johannes@…

Replying to alex.l.williamson@…:

Is this fixed anywhere?

It is fixed in the 0.28 development version.

comment:10 Changed 3 years ago by paulh

Milestone: unknown0.28
Resolution: Fixed
Status: acceptedclosed

Reported to be fixed in master

Note: See TracTickets for help on using tickets.