Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 2 years ago

Last modified 7 days ago

#10745 new Bug Report - General

Myth player not properly resetting after resolution change

Reported by: jyavenard Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - General Version: Unspecified
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by jyavenard)

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 jyavenard 2 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 (9)

comment:1 Changed 2 years ago by jyavenard

  • Description modified (diff)

Changed 2 years ago by jyavenard

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

comment:3 Changed 21 months ago by Daniel Thor Kristjansson <danielk@…>

  • Resolution set to fixed
  • Status changed from new to closed

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
meantime.

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 21 months 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 months ago by jyavenard

  • Resolution fixed deleted
  • Status changed from closed to new

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

comment:6 Changed 8 months ago by jyavenard

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

comment:7 Changed 8 months ago by wagnerrp

  • Milestone changed from 0.26 to 0.26.2

comment:8 Changed 7 days ago by paulh

  • Milestone changed from 0.26.2 to unknown

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.