Opened 9 years ago

Closed 16 months ago

#10745 closed Bug Report - General (Fixed)

Myth player not properly resetting after resolution change

Reported by: JYA Owned by: Mark Kendall
Priority: minor Milestone: 31.0
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by JYA)

Attached are 3 samples, all mpeg-ts streams with a H264 video stream and a AAC audio stream

bipbop234.ts is made of 3 x 10s. First block is at 480x320, 2nd and 3rd are at 1280x720. Between 2nd and 3rd it's just a change of video bitrate. This file plays fine with the avfd h264 reset hack. The file exhibit the same problem as #10715

nasa-8s2.ts has a resolution change occurring at 8s... About 30% of the time, myth with the avfd hack will crash and the AAC audio will stop decoding properly.

nasa-27s.ts is like nasa-8s2.ts but with the change over occurring at 27s.

The problem exhibited by those 3 files ultimately is breaking proper handling of HLS stream should the player determine that a lower bitrate stream is to be used.

Note that a recent version of mplayer will play all those files just fine.

Attachments (1)

h264reset.patch (14.6 KB) - added by JYA 9 years ago.
This patch close the h264 decoder and re-open it if a change of resolution is detected

Download all attachments as: .zip

Change History (11)

comment:1 Changed 9 years ago by JYA

Description: modified (diff)

Changed 9 years ago by JYA

Attachment: h264reset.patch added

This patch close the h264 decoder and re-open it if a change of resolution is detected

comment:3 Changed 9 years ago by Daniel Thor Kristjansson <danielk@…>

Resolution: fixed
Status: newclosed

In 83e227a15b64ed217638269f8eca1037774a187f/mythtv:

Fixes #10745. Fix segfault on H.264 resolution change.

The H264PreProcessPkt() code was stubbed out for resolution change,
but we were not actually uning the m_h264_parser values. Without this
we wouldn't actually know about changes until after they had occurred
and then we'd be giving ffmpeg improperly sized video frames in the

Note: For this to work you will need to disable ffmpeg's multi-threaded
decoding. This is a limitation of the ffmpeg library we're using.
We shouldn't crash if multi-threading is enabled but simply end
playback at the resolution change.

comment:4 Changed 9 years ago by Daniel Thor Kristjansson <danielk@…>

In 7593192d066a75ee9f55887bc8880dc35dc5b285/mythtv:

Refs #10745. close & reopen H.264 codec when necessary.

The libav H.264 decoder doesn't support resolution changes in
multithreaded mode. When we detect a resolution change in this
mode we now close and reopen the codec. jya came up with the
workaround, I just refined it a little bit.

comment:5 Changed 8 years ago by JYA

Resolution: fixed
Status: closednew

Re-opening ticket as this fix was really just a hack and doesn't handle all changes appropriately.

comment:6 Changed 8 years ago by JYA

Mark #11740 as a duplicate of this bug...

comment:7 Changed 8 years ago by Raymond Wagner


comment:8 Changed 7 years ago by paulh

Milestone: 0.26.2unknown

comment:9 Changed 17 months ago by Mark Kendall

Milestone: unknown31.0
Owner: changed from danielk to Mark Kendall
Status: newaccepted
Version: UnspecifiedMaster Head

Samples generally play fine in master with VDPAU and VAAPI but are still not handling decoder release properly (just a concurrent resource issue).

NVDEC falls over however - because it does not like concurrent decoders.

comment:10 Changed 16 months ago by Mark Kendall

Resolution: Fixed
Status: acceptedclosed

Stream changes are now handled *relatively* seemlessly by VAAPI, VDPAU and NVDEC for both decode only and direct rendering.

MMAL/V4L2 appear to be ok but not tested extensively.

I can't test VideoToolBox? at the moment.

MediaCodec? is the problem child and is still a work in progress.

Resolution changes are firmly on my radar and form part of my normal testing - so closing - given this ticket is 8 years old:)

Note: See TracTickets for help on using tickets.