Myth player not properly resetting after resolution change

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

[JYA]

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

[JYA]

bipbop234.ts: ​http://www.avenard.org/files/media/mediatest/bipbop234.ts

nasa-8s2.ts: ​http://www.avenard.org/files/media/mediatest/nasa-8s2.ts

nasa-27s.ts: ​http://www.avenard.org/files/media/mediatest/nasa-27s.ts

[Daniel Thor Kristjansson <danielk@…>]

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.

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

[JYA]

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

[JYA]

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

[Mark Kendall]

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.

[Mark Kendall]

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:)