Mailing List Archive

Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup)
I have rebased onto the master branch my ffmpeg-cleanup
https://github.com/MythTV/mythtv/pull/416 pull request and Peter Bennett
has pulled it into the devel/ffmpeg-resync branch for ease of testing.

Peter and I have tested it, but we would appreciate more testing before
merging it into master.

Thanks,

Scott Theisen
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
> Wiadomo?? napisana przez Scott Theisen <scott.the.elm@gmail.com> w dniu 04.07.2022, o godz. 03:38:
>
> I have rebased onto the master branch my ffmpeg-cleanup https://github.com/MythTV/mythtv/pull/416 pull request and Peter Bennett has pulled it into the devel/ffmpeg-resync branch for ease of testing.
>
> Peter and I have tested it, but we would appreciate more testing before merging it into master.
>
> Thanks,
>
> Scott Theisen

Scott,

I gave very brief testing of hw assisted decode on various hw in my testbed:

stateless v4l2_request API; h6 & rpi4; mpeg2/h264/hevc/vp8/vp9: OK
stateful v4l_m2m API; rpi4; h264: OK
vdpau API; ION2; h264: NOK; see (1)
vaapi API; intel n3450; mpeg2/hevc/vp8/vp9: OK; h264 NOK; see (2)


(1): i'm observing issue with LiveTV staring in approx 2..3 per 5 starts with ffmpeg decode. Also some h264 test videos are failing do decode: hxxp://warped.inet2.org/h264-Sat_1080i_25fps.mkv
I'm not observing this with current master - so it looks like issue happens on ffmpeg-resync branch.
https://pastebin.com/fq6iSH7J is log from 2 LiveTV starts: 1st with expected vdpau and second where it goes with ffmpeg (probably as fallback from failed vdpau attempt).

(2): issue seems similar to (1)

Let me know if I can do anything extra to chelp...


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
On 7/4/22 12:42, Piotr Oniszczuk wrote:
>
>> Wiadomo?? napisana przez Scott Theisen<scott.the.elm@gmail.com> w dniu 04.07.2022, o godz. 03:38:
>>
>> I have rebased onto the master branch my ffmpeg-cleanuphttps://github.com/MythTV/mythtv/pull/416 pull request and Peter Bennett has pulled it into the devel/ffmpeg-resync branch for ease of testing.
>>
>> Peter and I have tested it, but we would appreciate more testing before merging it into master.
>>
>> Thanks,
>>
>> Scott Theisen
> Scott,
>
> I gave very brief testing of hw assisted decode on various hw in my testbed:
>
> stateless v4l2_request API; h6 & rpi4; mpeg2/h264/hevc/vp8/vp9: OK
> stateful v4l_m2m API; rpi4; h264: OK
> vdpau API; ION2; h264: NOK; see (1)
> vaapi API; intel n3450; mpeg2/hevc/vp8/vp9: OK; h264 NOK; see (2)
>
>
> (1): i'm observing issue with LiveTV staring in approx 2..3 per 5 starts with ffmpeg decode. Also some h264 test videos are failing do decode: hxxp://warped.inet2.org/h264-Sat_1080i_25fps.mkv
> I'm not observing this with current master - so it looks like issue happens on ffmpeg-resync branch.
> https://pastebin.com/fq6iSH7J is log from 2 LiveTV starts: 1st with expected vdpau and second where it goes with ffmpeg (probably as fallback from failed vdpau attempt).
>
> (2): issue seems similar to (1)
>
> Let me know if I can do anything extra to chelp...

Piotr,

Since the issue is only with LiveTV, try the attached patch.  (The
commit hash is against my ffmpeg-cleanup branch but that doesn't really
matter.)

From your log:
```
2022-07-04 17:13:03.806788 W [mpegts @ 00007f229cb19780] Could not find
codec parameters for stream 0 (Video: h264, none): unspecified size
Consider increasing the value for the \'analyzeduration\' (60000000) and
\'probesize\' (5000000) options
2022-07-04 17:13:03.807066 I AFD: Stream #0: ID: 0x281 Codec ID: h264
Type: Video(0x0) Bitrate: 0
...
2022-07-04 17:13:03.808502 I VDPAUDec: VDPAU does not support decoding
\'h264 0x0\'
2022-07-04 17:13:03.808542 I AFD: Unavailable decoders: vdpau
...
2022-07-04 17:13:03.850283 I Duration: 00:00:02.52, start: 92891.733922,
bitrate: 1979 kb/s
```

It appears the stream was too short to properly initialize the hardware
decoder.  Comments in avformatdecoder.cpp mention it could be up to 5
seconds between keyframes.  That obviously depends on the encoder and
the settings the broadcaster uses.  (If I remember correctly, ATSC in
the US requires a keyframe every second so a picture can be displayed
quickly.)

Restoring the checks for a fully initialized video codec parser for
LiveTV should fix that by waiting 250ms at a time for more recorded
stream to decode.


Regarding your mkv sample, I can play it fine with ffmpeg decoding with
it in my Videos directory.  So I would need a log from master and a log
of it not working to try to determine what went wrong.  I would prefer
logs where `--logpath=SOME_PATH` is in the command line so I can see the
file and line numbers.

Thanks for testing,

Scott
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
> Wiadomo?? napisana przez Scott Theisen <scott.the.elm@gmail.com> w dniu 04.07.2022, o godz. 22:42:
>
> On 7/4/22 12:42, Piotr Oniszczuk wrote:
>>
>>> Wiadomo?? napisana przez Scott Theisen <scott.the.elm@gmail.com>
>>> w dniu 04.07.2022, o godz. 03:38:
>>>
>>> I have rebased onto the master branch my ffmpeg-cleanup
>>> https://github.com/MythTV/mythtv/pull/416
>>> pull request and Peter Bennett has pulled it into the devel/ffmpeg-resync branch for ease of testing.
>>>
>>> Peter and I have tested it, but we would appreciate more testing before merging it into master.
>>>
>>> Thanks,
>>>
>>> Scott Theisen
>>>
>> Scott,
>>
>> I gave very brief testing of hw assisted decode on various hw in my testbed:
>>
>> stateless v4l2_request API; h6 & rpi4; mpeg2/h264/hevc/vp8/vp9: OK
>> stateful v4l_m2m API; rpi4; h264: OK
>> vdpau API; ION2; h264: NOK; see (1)
>> vaapi API; intel n3450; mpeg2/hevc/vp8/vp9: OK; h264 NOK; see (2)
>>
>>
>> (1): i'm observing issue with LiveTV staring in approx 2..3 per 5 starts with ffmpeg decode. Also some h264 test videos are failing do decode: hxxp://warped.inet2.org/h264-Sat_1080i_25fps.mkv
>> I'm not observing this with current master - so it looks like issue happens on ffmpeg-resync branch.
>>
>> https://pastebin.com/fq6iSH7J
>> is log from 2 LiveTV starts: 1st with expected vdpau and second where it goes with ffmpeg (probably as fallback from failed vdpau attempt).
>>
>> (2): issue seems similar to (1)
>>
>> Let me know if I can do anything extra to chelp...
>>
>
> Piotr,
>
> Since the issue is only with LiveTV, try the attached patch. (The commit hash is against my ffmpeg-cleanup branch but that doesn't really matter.)
>
> From your log:
> ```
> 2022-07-04 17:13:03.806788 W [mpegts @ 00007f229cb19780] Could not find codec parameters for stream 0 (Video: h264, none): unspecified size
> Consider increasing the value for the \'analyzeduration\' (60000000) and \'probesize\' (5000000) options
> 2022-07-04 17:13:03.807066 I AFD: Stream #0: ID: 0x281 Codec ID: h264 Type: Video(0x0) Bitrate: 0
> ...
> 2022-07-04 17:13:03.808502 I VDPAUDec: VDPAU does not support decoding \'h264 0x0\'
> 2022-07-04 17:13:03.808542 I AFD: Unavailable decoders: vdpau
> ...
> 2022-07-04 17:13:03.850283 I Duration: 00:00:02.52, start: 92891.733922, bitrate: 1979 kb/s
> ```
>
> It appears the stream was too short to properly initialize the hardware decoder. Comments in avformatdecoder.cpp mention it could be up to 5 seconds between keyframes. That obviously depends on the encoder and the settings the broadcaster uses. (If I remember correctly, ATSC in the US requires a keyframe every second so a picture can be displayed quickly.)
>
> Restoring the checks for a fully initialized video codec parser for LiveTV should fix that by waiting 250ms at a time for more recorded stream to decode.

Perfect.
Applying patch fixes issue with LiveTV :-)


>
>
> Regarding your mkv sample, I can play it fine with ffmpeg decoding with it in my Videos directory. So I would need a log from master and a log of it not working to try to determine what went wrong. I would prefer logs where `--logpath=SOME_PATH` is in the command line so I can see the file and line numbers.

It looks i was wrong saying: .mkv sample plays ok in current master.
.mkv sample fails on current master with vdpau/vaapi api
but plays ok with hw decoding on current master (and also on ffmpeg-resync) with: v4l2_request and v4l2_m2m api

So issue is rather no fmpeg-resync regression - but rather more general regression in current master :-(

If this will be helpful - pls find 2 logs:
-failing on n3450 vaapi; ffmpeg-resync : hxxp://warped.inet2.org/failing.log
-working on h6 v4l2_request; ffmpeg-resync: hxxp://warped.inet2.org/ok.log

btw:
i also discover current master fails hw decode on mesa/vaapi
hw decode ok but with black screen on mesa/vdpau
....but this is another issue

br

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
On 7/5/22 04:37, Piotr Oniszczuk wrote:
> It looks i was wrong saying: .mkv sample plays ok in current master.
> .mkv sample fails on current master with vdpau/vaapi api
> but plays ok with hw decoding on current master (and also on ffmpeg-resync) with: v4l2_request and v4l2_m2m api
>
> So issue is rather no fmpeg-resync regression - but rather more general regression in current master:-(
>
> If this will be helpful - pls find 2 logs:
> -failing on n3450 vaapi; ffmpeg-resync : hxxp://warped.inet2.org/failing.log
> -working on h6 v4l2_request; ffmpeg-resync: hxxp://warped.inet2.org/ok.log

You website is asking for a login, so I can't look at your logs.

>
> btw:
> i also discover current master fails hw decode on mesa/vaapi
> hw decode ok but with black screen on mesa/vdpau
> ....but this is another issue

It is probably best to open a new issue on GitHub so this thread stays
on topic.

Scott
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
> Wiadomo?? napisana przez Scott Theisen <scott.the.elm@gmail.com> w dniu 05.07.2022, o godz. 20:05:
>
> On 7/5/22 04:37, Piotr Oniszczuk wrote:
>> It looks i was wrong saying: .mkv sample plays ok in current master.
>> .mkv sample fails on current master with vdpau/vaapi api
>> but plays ok with hw decoding on current master (and also on ffmpeg-resync) with: v4l2_request and v4l2_m2m api
>>
>> So issue is rather no fmpeg-resync regression - but rather more general regression in current master:-(
>>
>> If this will be helpful - pls find 2 logs:
>> -failing on n3450 vaapi; ffmpeg-resync : hxxp://warped.inet2.org/failing.log
>> -working on h6 v4l2_request; ffmpeg-resync: hxxp://warped.inet2.org/ok.log
>
> You website is asking for a login, so I can't look at your logs.

Ah i'm sorry.
Now should be ok :-p

>
>>
>> btw:
>> i also discover current master fails hw decode on mesa/vaapi
>> hw decode ok but with black screen on mesa/vdpau
>> ....but this is another issue
>
> It is probably best to open a new issue on GitHub so this thread stays on topic.

I looked closer on mesa thing.
After mesa update, rebuild, make sure llvm cooperates ok with mesa and various tests i see:
-current mesa/vaapi works ok on current master.
-current mesa/vaapi not works on ffmpeg-resync.

So maybe we will return to testing mesa/vaapi on ffmpeg-resync when we fix my .mkv sample decoding issue?

br
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
On 04/07/2022 02:38, Scott Theisen wrote:
> I have rebased onto the master branch my ffmpeg-cleanup
> https://github.com/MythTV/mythtv/pull/416 pull request and Peter Bennett
> has pulled it into the devel/ffmpeg-resync branch for ease of testing.
>
> Peter and I have tested it, but we would appreciate more testing before
> merging it into master.
>
> Thanks,
>
> Scott Theisen

I'm having problems getting this. I thought I had built from that
branch soon after this Call, but what I got was 33Pre117.g25b7583221.

Now the latest commit appearing at
https://github.com/MythTV/mythtv/commits/devel/ffmpeg-resync is
bd41df47c69 from July 1, and starting another build gives

john@HPFed rpm]$ ionice -c3
~/packaging/MythTV/rpm/BUILD_MYTHTV_RPMS_from_repoA -r
fedora-35-x86_64-rpmfusion_free devel/ffmpeg-resync
Cloning into 'mythtv'...
done.
Updating files: 100% (18296/18296), done.
branch 'devel/ffmpeg-resync' set up to track 'origin/devel/ffmpeg-resync'.
Switched to a new branch 'devel/ffmpeg-resync'
----
Building mythtv version 33.Pre.117.g25b7583221 at commit
25b7583221bc49f66d4b82774a2ce99c4aadf5e1
----
^C

Suggestions? Thanks,

John P




_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
On 06/07/2022 10:40, John Pilkington wrote:
> On 04/07/2022 02:38, Scott Theisen wrote:
>> I have rebased onto the master branch my ffmpeg-cleanup
>> https://github.com/MythTV/mythtv/pull/416 pull request and Peter
>> Bennett has pulled it into the devel/ffmpeg-resync branch for ease of
>> testing.
>>
>> Peter and I have tested it, but we would appreciate more testing
>> before merging it into master.
>>
>> Thanks,
>>
>> Scott Theisen
>
> I'm having problems getting this.  I thought I had built from that
> branch soon after this Call, but what I got was 33Pre117.g25b7583221.
>
> Now the latest commit appearing at
> https://github.com/MythTV/mythtv/commits/devel/ffmpeg-resync is
> bd41df47c69 from July 1, and starting another build gives
>
> john@HPFed rpm]$ ionice -c3
> ~/packaging/MythTV/rpm/BUILD_MYTHTV_RPMS_from_repoA -r
> fedora-35-x86_64-rpmfusion_free devel/ffmpeg-resync
> Cloning into 'mythtv'...
> done.
> Updating files: 100% (18296/18296), done.
> branch 'devel/ffmpeg-resync' set up to track 'origin/devel/ffmpeg-resync'.
> Switched to a new branch 'devel/ffmpeg-resync'
> ----
> Building mythtv version 33.Pre.117.g25b7583221 at commit
> 25b7583221bc49f66d4b82774a2ce99c4aadf5e1
> ----
> ^C
>
> Suggestions?   Thanks,
>
> John P
>
>

It looks as if

cd <path/to>repoA
git checkout devel/ffmpeg-resync
git pull --rebase

may have fixed it. Now building 33.Pre.574.gbd41df47

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Call for testing branch devel/ffmpeg-resync (ffmpeg-cleanup) [ In reply to ]
On 7/6/22 06:22, John Pilkington wrote:
> On 06/07/2022 10:40, John Pilkington wrote:
>> On 04/07/2022 02:38, Scott Theisen wrote:
>>> I have rebased onto the master branch my ffmpeg-cleanup
>>> https://github.com/MythTV/mythtv/pull/416 pull request and Peter
>>> Bennett has pulled it into the devel/ffmpeg-resync branch for ease
>>> of testing.
>>>
>>> Peter and I have tested it, but we would appreciate more testing
>>> before merging it into master.
>>>
>>> Thanks,
>>>
>>> Scott Theisen
>>
>> I'm having problems getting this.  I thought I had built from that
>> branch soon after this Call, but what I got was 33Pre117.g25b7583221.
>>
>> Now the latest commit appearing at
>> https://github.com/MythTV/mythtv/commits/devel/ffmpeg-resync is
>> bd41df47c69 from July 1, and starting another build gives
>>
>> john@HPFed rpm]$ ionice -c3
>> ~/packaging/MythTV/rpm/BUILD_MYTHTV_RPMS_from_repoA -r
>> fedora-35-x86_64-rpmfusion_free devel/ffmpeg-resync
>> Cloning into 'mythtv'...
>> done.
>> Updating files: 100% (18296/18296), done.
>> branch 'devel/ffmpeg-resync' set up to track
>> 'origin/devel/ffmpeg-resync'.
>> Switched to a new branch 'devel/ffmpeg-resync'
>> ----
>> Building mythtv version 33.Pre.117.g25b7583221 at commit
>> 25b7583221bc49f66d4b82774a2ce99c4aadf5e1
>> ----
>> ^C
>>
>> Suggestions?   Thanks,
>>
>> John P
>>
>>
>
> It looks as if
>
> cd <path/to>repoA
> git checkout devel/ffmpeg-resync
> git pull --rebase
>
> may have fixed it.  Now building 33.Pre.574.gbd41df47
>
>
The correct version currently for devel/ffmpeg-resync is
v33-Pre-574-gbd41df47c6 so you are now correct.

The problem may have arisen because the devel/ffmpeg-resync branch has
been rebased several times.

This is one approach.

git checkout devel/ffmpeg-resync
git fetch origin
git reset --hard origin/devel/ffmpeg-resync

If you are a developer that would lose any local changes you had committed.

Peter


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVC Baseline Profile support [ In reply to ]
On 7/6/22 03:41, Piotr Oniszczuk wrote:
>
>> Wiadomo?? napisana przez Scott Theisen<scott.the.elm@gmail.com> w dniu 05.07.2022, o godz. 20:05:
>>
>> On 7/5/22 04:37, Piotr Oniszczuk wrote:
>>> It looks i was wrong saying: .mkv sample plays ok in current master.
>>> .mkv sample fails on current master with vdpau/vaapi api
>>> but plays ok with hw decoding on current master (and also on ffmpeg-resync) with: v4l2_request and v4l2_m2m api
>>>
>>> So issue is rather no fmpeg-resync regression - but rather more general regression in current master:-(
>>>
>>> If this will be helpful - pls find 2 logs:
>>> -failing on n3450 vaapi; ffmpeg-resync : hxxp://warped.inet2.org/failing.log
>>> -working on h6 v4l2_request; ffmpeg-resync: hxxp://warped.inet2.org/ok.log
>> You website is asking for a login, so I can't look at your logs.
> Ah i'm sorry.
> Now should be ok :-p

Just to clarify the behavior when you say failing on n3450, do you mean
it doesn't decode at all or just that it doesn't use hardware acceleration?

Noteworthy lines from failing.log:
```
2022-07-05 09:48:55.647891 I [5383/5383] CoreContext
mythvideoprofile.cpp:305 (MythVideoProfile) - VideoProfile: Accepting:
cmp() w() h() framerate() codecs( ) dec(vaapi) cpus(2) skiploop(enabled)
rend(opengl-hw) deint(high:shader:driver,high:shader:driver)
upscale(bilinear)
2022-07-05 09:48:55.647910 I [5383/5383] CoreContext
mythvideoprofile.cpp:305 (MythVideoProfile) - VideoProfile: Accepting:
cmp() w() h() framerate() codecs( ) dec(ffmpeg) cpus(2)
skiploop(enabled) rend(opengl-yv12) deint(medium:shader,medium:shader)
upscale(bilinear)
...
2022-07-05 09:48:56.257242 I [5383/5383] CoreContext
mythvideoprofile.cpp:446 (LoadBestPreferences) - VideoProfile:
LoadBestPreferences(1920x1080, 50.000, h264)
2022-07-05 09:48:56.257265 I [5383/5383] CoreContext
mythvideoprofile.cpp:471 (LoadBestPreferences) - VideoProfile:
LoadBestPreferences result: priority:1 width: height: fps: codecs:
2022-07-05 09:48:56.257273 I [5383/5383] CoreContext
mythvideoprofile.cpp:476 (LoadBestPreferences) - VideoProfile:
decoder:vaapi renderer:opengl-hw deint0:high:shader:driver
deint1:high:shader:driver cpus:2 upscale:bilinear
2022-07-05 09:48:56.257324 I [5383/5383] CoreContext
mythvaapicontext.cpp:152 (GetSupportedCodec) - VAAPIDec: VAAPI does not
support decoding 'h264 Baseline yuv420p'
2022-07-05 09:48:56.257334 I [5383/5383] CoreContext
avformatdecoder.cpp:2304 (ScanStreams) - AFD: Unavailable decoders: vaapi
```

Your Intel N3450 has 4 cores, why use only 2 of them?

Your sample, h264-Sat_1080i_25fps.mkv, has a video stream using AVC
Baseline Profile.  libva has deprecated (
https://github.com/intel/libva/commit/6f69256f8ccc9a73c0b196ab77ac69ab1f4f33c2
) this on 2017-09-17 saying:
```
Deprecate H.264 baseline profile and FMO support

This is not now and never will be supported by any hardware, nor is
it supported by any current software.

```

If I understand what the Baseline Profile enables, the video stream
should not decode properly if it actually uses those features. Since it
presumably did decode properly using hardware acceleration, the video
stream is probably a mislabeled Constrained Baseline.

Could you get the output of `vainfo` on your Intel system?

Try this (raises a -Wdeprecated-declarations)
```
diff --git a/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
b/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
index 514eec029b..ba9751c871 100644
--- a/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
+++ b/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
@@ -68,6 +68,7 @@ VAProfile MythVAAPIContext::VAAPIProfileForCodec(const
AVCodecContext* Codec)
         case AV_CODEC_ID_H264:
             switch (Codec->profile)
             {
+                case FF_PROFILE_H264_BASELINE: return
VAProfileH264Baseline;
                 case FF_PROFILE_H264_CONSTRAINED_BASELINE: return
VAProfileH264ConstrainedBaseline;
                 case FF_PROFILE_H264_MAIN: return VAProfileH264Main;
                 case FF_PROFILE_H264_HIGH: return VAProfileH264High;
```

or this hack:
```
diff --git a/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
b/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
index 514eec029b..c3a0550687 100644
--- a/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
+++ b/mythtv/libs/libmythtv/decoders/mythvaapicontext.cpp
@@ -68,6 +68,7 @@ VAProfile MythVAAPIContext::VAAPIProfileForCodec(const
AVCodecContext* Codec)
         case AV_CODEC_ID_H264:
             switch (Codec->profile)
             {
+                case FF_PROFILE_H264_BASELINE: // XXX HACK: assume
mislabeled and hope for the best
                 case FF_PROFILE_H264_CONSTRAINED_BASELINE: return
VAProfileH264ConstrainedBaseline;
                 case FF_PROFILE_H264_MAIN: return VAProfileH264Main;
                 case FF_PROFILE_H264_HIGH: return VAProfileH264High;
```

>
>>> btw:
>>> i also discover current master fails hw decode on mesa/vaapi
>>> hw decode ok but with black screen on mesa/vdpau
>>> ....but this is another issue
>> It is probably best to open a new issue on GitHub so this thread stays on topic.
> I looked closer on mesa thing.
> After mesa update, rebuild, make sure llvm cooperates ok with mesa and various tests i see:
> -current mesa/vaapi works ok on current master.
> -current mesa/vaapi not works on ffmpeg-resync.
>
> So maybe we will return to testing mesa/vaapi on ffmpeg-resync when we fix my .mkv sample decoding issue?
>
> br

What doesn't work?

Scott