[mythtv-users] Anyone running MythTV 31 on 32-bit x86 with nVidia card?

[Tom Dexter]

On 2/11/21, John Pilkington <johnpilk222 at gmail.com> wrote:
> On 11/02/2021 19:47, Tom Dexter wrote:
>> On 2/11/21, Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:
>>> On Thu, 11 Feb 2021 09:49:59 -0500, you wrote:
>>>
>>>> On 2/11/21, George Mari <george_mythusers at mari1938.org> wrote:
>>>>> On 2/10/21 11:56 AM, Tom Dexter wrote:
>>>>>> My trusty old frontend is a 32-bit x86 machine with a GT 430 nVidia
>>>>>> card.
>>>>>>
>>>>>> Quite some time ago I upgraded to MythTV 30.0 but ended up reverting
>>>>>> back to 29.1 because I had some issues with some (though not most)
>>>>>> h264 videos. Specifically, some h264 videos would fail the VDPAU
>>>>>> decode and fallback to software decoding. These were videos that used
>>>>>> VDPAU with no issue in other players like xine, and also in MythTV
>>>>>> 29.1. This was never resolved and was an issue that apparently
>>>>>> couldn't be reproduced on 64 bit systems.
>>>>>>
>>>>>> My understanding is that the FFmpeg hardware acceleration code has
>>>>>> been radically changed in version 31.
>>>>>>
>>>>>> As per the subject, if anyone is running MythTV 31 on 32-bit x86 and
>>>>>> is using an nVidia GPU, it would help me enormously if they could
>>>>>> test
>>>>>> this example:
>>>>>>
>>>>>> http://jell.yfish.us/media/jellyfish-60-mbps-hd-h264.mkv
>>>>>>
>>>>>> ...and see if it uses VDPAU decoding, which can be determined during
>>>>>> playback from the menu under Playback -> Playback Data.
>>>>>>
>>>>> I have a 64-bit Fedora installation with a GT 430 card - not exactly
>>>>> what you are asking for, I know.
>>>>>
>>>>> But for me, the video Playback Data shows h.264 ffmpeg
>>>>>
>>>>
>>>> Wow. So it's NOT using VDPAU, and that's with MythTV 31? That is
>>>> really not good news at all. Do other h264 videos use VDPAU? That
>>>> sounds like a significant bug to me. Even on my 32-bit system that
>>>> video uses VDPAU without issues in xine, mpv, and in MythTV 29.1.
>>>>
>>>> When I was temporarily on 30.0 I posted comments about this on this
>>>> (semi-related) bug, but at that time apparently nobody using 64-bit
>>>> could duplicate this one:
>>>>
>>>> https://code.mythtv.org/trac/ticket/13223
>>>>
>>>> As noted there, the error that caused it to fallback to software
>>>> decode was this:
>>>>
>>>> 2019-05-17 10:37:09.222935 E [14504/28060] Decoder
>>>> avformatdecoder.cpp:3785 (ProcessVideoPacket?) - AFD: video
>>>> avcodec_send_packet error: Invalid data found when processing input
>>>> (-1094995529) gotpicture:0
>>>>
>>>> I'm hesitant to update, though I'm going to have to soon, as (for a
>>>> number of reasons) I can no longer compile MythTV 29.1 on my Gentoo
>>>> system. What's worse is that, since I'm running 29.1 I can't very well
>>>> log a bug or test any of this.
>>>>
>>>> I'd be interested to see what others find testing this...with 32 or 64
>>>> bit. Thanks for the reply! That's significant for sure.
>>>>
>>>> Tom
>>>
>>> That file is encoded using the H.264 High at L5 profile.  I am not sure
>>> if a GT430 can play that profile, so that may be why it is dropping
>>> back to using ffmpeg.  You only need High at L4.1 for playing BluRay, so
>>> a lot of earlier Nvidia cards did not support higher than that, IIRC.
>>> In v31 (using the new rendering code), when I play that file using
>>> mythavtest on my GT1030, it plays using VDPAU.
>>
>> Again though, that can't possibly be the issue because it can use
>> VDPAU on that same system and GT430 in MythTV 29.1, xine, and mpv.
>> Clearly has to be a software issue and not the card.
>>
>> Tom
>
> But you may well have to tell it to use VDPAU or NVDEC in your playback
> options in the frontend.  Frontend setup > Video > Playback, iirc
>
> John P

If you mean the playback profile, my default has always used VDPAU for
everything. Again, what everyone seems to be missing is that none of
that would explain why it uses VDPAU just fine in 29.1 (which I'm
using now) and failed in version 30, with everything (including the
playback profile) being the same.

Tom