[mythtv] render2019 comments

[Mark Kendall]

On Tue, 1 Oct 2019 at 16:07, Mike Bibbings <mike.bibbings at gmail.com> wrote:
> I have tried 2019-render branch on a few different machines, accelerated playback works ok once I had setup new video profile.
>
> Originally the frontends were running master branch with appropriate accelerated video profile.
>
> Is it intended to automatically migrate old profiles to  new profiles or will Users have to reconfigure ?

I'm not sure how to deal with this yet. I considered adding some code
to ensure they were set to sensible equivalents in the display profile
pages - but that would require the user to actually go into the
settings pages.

I'm not sure it is best handled with a schema upgrade - there are
currently no schema changes. Some video display profile elements are
now redundant/removed (e.g. the OSD selection) - it is just the values
that have changed.

The best option may be to automatically check at startup and if any
changes are made then send a UI message saying that - and ask the use
to check their profiles.

or just say in the release notes that you need to update your profiles...

> I have tried on Intel Graphics : TV via HDMI 1920x1080 50Hz and laptop 1366x768 @60HZ
>
> Nvidia Graphics: laptop 1920x1080 @60Hz

I'm working through some issues with Piotr for nvidia/VDPAU - should
be resolved shortly but you may get out of memory issues.

> AMD Ryzen 3 2200G with Radeon Vega Graphics: TV via HDMI 3840x2160 @50Hz and 60Hz

I'd be interested to see some -v playback logs with radeon graphics -
I've not tested with AMD at all.

>
> I can also try on Raspberry Pi models 2,3 and 4 if someone can give me the build incantations for OpenMax (Pi 2 Pi3) and Opengl vc4-fkms-v3d (pi4), including what other build depends are required (some mesa-dev libraries ?).

I don't have a working Pi build at the moment - that's not to say the
mythtv code doesn't work - it's just a mess with raspbian at the
moment.

MMAL and V4L2 are now the decoders for the pi.

MMAL requires the closed source/broadcom driver to work for direct
rendering but that requires that you build your own version of Qt5
with pi support built in (though it has just occurred to me that there
may be a workaround!). Direct rendering is also not that speedy
currently and there is no hardware (MMAL) deinterlacing.

V4L2 requires the opensource OpenGL driver (which is now the default
on the Pi4). The main problem here is that there is no direct
rendering support, so it is not as fast as it could be, and the pi
v4l2 codecs driver does not pass through interlaced flags - so auto
deinterlacing does not work.

I've put most of this on a wiki page (it's a work in progress) -

https://www.mythtv.org/wiki/2019-render

>
> The only real problem I have is the UK Freeview DVB-T/T2 LiveTV channel switching issue (trac ticket https://code.mythtv.org/trac/ticket/13292)  is now even worse in that it takes much longer to show failure.
>
>
> Using any of my tuners: TBS6280 (dual tuner PCI-e) or SiliconDust HD HomeRun CONNECT QUATTRO (model HDHR5-4DT, firmware  20190621) or Hauppauge Quad HD (PCI-e)  or TBS 6522 (dual tuner PCI-e) or Astrometa (USB).
>
> I have put a few mythfrontend logs (-v playback,libav --loglevel debug) in my Dropbox https://www.dropbox.com/sh/0n0t3ebp4nwiy3g/AACeC4WijoHLzj6Mrq1pgdmDa?dl=0
>
> The change  m_ic->max_analyze_duration = 60 * AV_TIME_BASE; has had some effect in that some channel changes are now "working" after 20 seconds or more, depending on channel rate.
>
> I still see instances of the wrong codec being opened and the reopening failing (invalid argument). Also I see Probe size (5000000) being hit.
>
> 2019-10-01 13:46:56.032686 I [23348/23348] CoreContext decoders/avformatdecoder.cpp:2107 (ScanStreams) - AFD: Already opened codec not matching (MP2 vs MP2). Reopening
> Looking at the code
>
> avformatdecoder.cpp seems to have a error starting at if block at line 2102
>
>         if (enc->codec && par->codec_id != enc->codec_id)
>         {
>             LOG(VB_PLAYBACK, LOG_INFO, LOC +
>                 QString("Already opened codec not matching (%1 vs %2). Reopening")
>                 .arg(ff_codec_id_string(enc->codec_id))
>                 .arg(ff_codec_id_string(enc->codec->id)));
>             gCodecMap->freeCodecContext(m_ic->streams[strm]);
>             enc = gCodecMap->getCodecContext(m_ic->streams[strm]);
>         }
>
>
> l2106               .arg(ff_codec_id_string(enc->codec_id))
> l2107               .arg(ff_codec_id_string(enc->codec->id)));
> both have the same codec, I suspect one of them should refer to par->codec_id

I've seen some of these issues (I'm using an old HDHomeRun dvb-t
tuner). Live tv is, as ever, a black hole:) I'll take a look.

The max_analyze_duration change is probably only helping in some cases
as in others the stream will be scanned and not fully parsed but the
ffmpeg code will still report success.

My gut feeling is that the in memory check needs to go...

Thanks and regards
Mark