[mythtv-users] Status of ffmpeg 4.4.1

[John Pilkington]

On 06/11/2021 20:20, Klaas de Waal wrote:
> 
> 
> On Sat, 6 Nov 2021 at 14:42, Peter Bennett <pb.mythtv at gmail.com 
> <mailto:pb.mythtv at gmail.com>> wrote:
> 
> 
>     On 11/6/21 9:02 AM, Klaas de Waal wrote:
>>
>>
>>     On Fri, 5 Nov 2021 at 22:49, Klaas de Waal
>>     <klaas.de.waal at gmail.com <mailto:klaas.de.waal at gmail.com>> wrote:
>>
>>
>>
>>
>>         On Fri, 5 Nov 2021 at 21:43, Peter Bennett
>>         <pb.mythtv at gmail.com <mailto:pb.mythtv at gmail.com>> wrote:
>>
>>
>>             On 11/5/21 3:17 PM, Klaas de Waal wrote:
>>>
>>>
>>>             On Wed, 3 Nov 2021 at 20:30, Peter Bennett
>>>             <pb.mythtv at gmail.com <mailto:pb.mythtv at gmail.com>> wrote:
>>>
>>>                 Most things are working with ffmpeg 4.4.1 in the
>>>                 devel/ffmpeg-resync branch
>>>
>>>                 What is not working:
>>>
>>>                 - Audio "upconvert stereo to 5.1 sound" when playing
>>>                 a video with stereo
>>>                 sound - error message and no audio playback .
>>>
>>>                 - Speedup / slowdown when playing a video with dolby
>>>                 5.1 audio - error
>>>                 message and no audio playback .
>>>
>>>                 - Report from John Pilkington that an existing bug
>>>                 with edit markers and
>>>                 step lengths now reacts slightly differently - I
>>>                 don't know if it is
>>>                 better or worse with the new ffmpeg.
>>>
>>>                 I am looking into the 5.1 audio issues.
>>>
>>>                 Peter
>>>
>>>
>>>             Hi Peter,
>>>
>>>             As mentioned in the mythtv-dev mailing list, there are
>>>             with the new FFmpeg often blocking artifacts when
>>>             starting playback and when jumping forward and backward.
>>>             This happens also on recordings made with the old FFmpeg
>>>             so it looks to me like a playback-only issue.
>>>             I do see this on my cable TV recordings which are H264,
>>>             1080i interlaced 50/25 frames per second, both HD and SD.
>>>             I do NOT see this on Bluray rips which are 24p.
>>>             I also do not see this on recordings with MPEG2 video
>>>             coding, only on H264.
>>>
>>>             Hope you can have a look into this also,
>>>
>>>             Thanks,
>>>             Klaas.
>>>
>>>
>>>
>>             I am not able to reproduce this on the devel/ffmpeg-resync
>>             branch. I tried with NVDEC and with OpenGL playback
>>             profiles. Which playback profile are you using?
>>
>>
>>          Hi Peter,
>>
>>         Looks like it happens with VDPAU only. NVDEC, OpenGL and VAAPI
>>         (that on Intel hardware) are OK.
>>         So the failing combination is VDPAU/H264/interlaced.
>>
>>     Tested some more on other recordings and there are also blocking
>>     artifacts with NVDEC, but less pronounced and also sometimes the
>>     stream makes a difference. If it is difficult to reproduce I can
>>     create a ticket for this and attach photographs and clips.
>>
>>     Thanks,
>>     Klaas.
>>
>>
>>     _______________________________________________
> 
>     Hi Klaas
> 
>     I do not have any H264 interlaced recordings. On Comcast we get
>     MPEG2 interlaced and H264 progressive. There is a known problem with
>     MPEG2 and both NVDEC and VDPAU, also NVidia shield where there are
>     frequent pixelations while watching MPEG2, if the stream is highly
>     compressed as some USA channels are. This has been around for many
>     years and NVidia seem to have no plans to fix it.
> 
>     I tried with H264 progressive recordings and I do not see any
>     problem with VDPAU either.
> 
>     Maybe you can send a sample H260 interlaced recording. It will have
>     to be long enough for me to perform skips, if that is the only way
>     to see the problem. What number of seconds do you have for skip
>     ahead and skip back?
> 
> 
> This is a fragment with the first 100MB of a recent recording, H264 full 
> HD interlaced.
> https://drive.google.com/file/d/14Z5lsY37wgr5vuL7bg7CyDDO-wg0SWIx/view?usp=sharing 
> <https://drive.google.com/file/d/14Z5lsY37wgr5vuL7bg7CyDDO-wg0SWIx/view?usp=sharing>
> 
> Playing from the start already gives blocking artifacts, as shown in the 
> following link
> https://drive.google.com/file/d/1UA_m9gEkcrhTe_KfKfTkgKT_MdNDknyL/view?usp=sharing 
> <https://drive.google.com/file/d/1UA_m9gEkcrhTe_KfKfTkgKT_MdNDknyL/view?usp=sharing>
> This is a screenshot taken immediately after the start of playback at 
> the beginning of the file.
> Jumping is configured here for 45 seconds forward and 15 seconds 
> backward but it should not matter for reproducing.
> 
> FYI, Here on my local cable all HD channels are 1080 interlaced, all SD 
> channels are MPEG2 interlaced. The MPEG2 recordings play OK.
> Bluray, 24p, plays OK. I can also receive OTA a 1080 progressive with 
> H265 coding. This also plays OK.
> I use Nvidia GT1030 cards for playback; in the living room on Ubuntu 
> 18.something and the development system on Fedora 35.
> 
> I do hope the links do work.
> 
> Thanks,
> Klaas.

Also FYI:  DVB-T2 broadcasts in the UK using h264 switch 'randomly' 
between progressive and interlaced.  Set pieces such as programme idents 
are often progressive, but studio material immediately following will be 
interlaced.