[mythtv] FFmpeg 4.4.1 problems

Mon Nov 22 20:56:27 UTC 2021

On 11/22/21 1:07 PM, Klaas de Waal wrote:
>
> tl;dr Also blocking artifacts when skipping with mpv when VDPAU is used.
> Blocking artifacts with vlc when using VDPAU but also when NOT 
> using VDPAU.
> Blocking artifacts with mplayer.
> Failed to create a MythTV with an unmodified FFmpeg tree.
>
> And this is the long version....
>
> I have been doing some more tests with mpv and this time with various 
> options.
> The file used for testing, tweevoortwaalf-ffmpeg.ts, has been shared 
> in this thread.
> Note that this file is the first 100Mbyte of a mythtv recording and it 
> is representative of what is here on the local cable network, it is 
> not a sequence specially crafted to test decoders.
>
> This plays OK:
> $ mpv tweevoortwaalf-ffmpeg.ts
> $ mpv -vo vdpau tweevoortwaalf-ffmpeg.ts
> $ mpv -vo=gpu tweevoortwaalf_ffmpeg.ts
> $ mpv --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
> $ mpv -vo=gpu --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
>
> This gives blocking artifacts with skipping:
> $ mpv -vo=vdpau --hwdec=vdpau tweevoortwaalf_ffmpeg.ts
> $ mpv --vo=gpu --hwdec=vdpau-copy tweevoortwaalf_ffmpeg.ts
>
> This is the mpv version used, as present in Fedora 35.
> [klaas at modu videos]$ mpv -version
> mpv 0.34.0 Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects
>  built on UNKNOWN
> FFmpeg library versions:
>    libavutil       56.70.100
>    libavcodec      58.134.100
>    libavformat     58.76.100
>    libswscale      5.9.100
>    libavfilter     7.110.100
>    libswresample   3.9.100
> FFmpeg version: 4.4.1
>
> This plays correct but while it uses Nvidia hardware it does NOT use 
> VDPAU as pointed out by Peter:
> $ ffplay -sst 0 -vcodec h264_cuvid tweevoortwaalf_ffmpeg.ts
> But interesting: playback with VLC also gives blocking artifacts!
> VLC uses VDPAU by default as shown here:
> [klaas at modu videos]$ vlc tweevoortwaalf_ffmpeg.ts
> VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2)
> [0000560ed8f70b70] main libvlc: Running vlc with the default 
> interface. Use 'cvlc' to use vlc without interface.
> [00007fd348005720] gl gl: Initialized libplacebo v4.157.0 (API v157)
> libva info: VA-API version 1.13.0
> libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
> libva info: Found init function __vaDriverInit_1_12
> libva info: va_openDriver() returns 0
> [00007fd348005720] glconv_vaapi_x11 gl error: vaCreateSurfaces: 
> attribute not supported
> [00007fd344077100] main video output error: video output creation failed
> [00007fd354c10f90] main decoder error: failed to create video output
> [00007fd3484ada50] gl gl: Initialized libplacebo v4.157.0 (API v157)
> [00007fd354c10f90] avcodec decoder: Using NVIDIA VDPAU Driver Shared 
> Library  495.44  Fri Oct 22 06:03:50 UTC 2021 for hardware decoding
>
> Further complicating the issue is that when playing the same clip on 
> another system with Intel built-in graphics, VLC also gives the 
> blocking artifacts.
>
> Next test with the mplayer: also blocking artifacts when skipping for 
> all tested video output options (vdpau, xv, x11, gl).
> [klaas at modu videos]$ mplayer tweevoortwaalf_ffmpeg.ts
> MPlayer SVN-r38302-11 (C) 2000-2021 MPlayer Team
> do_connect: could not connect to socket
> connect: No such file or directory
> Failed to open LIRC support. You will not be able to use your remote 
> control.
>
> Playing tweevoortwaalf_ffmpeg.ts.
> libavformat version 58.76.100 (external)
> TS file format detected.
> VIDEO H264(pid=2301) AUDIO MPA(pid=2311) SUB Teletext(pid=2401) 
>  PROGRAM N. 1
> FPS seems to be: 25.000000
> ==========================================================================
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> libavcodec version 58.134.100 (external)
> Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
> ==========================================================================
> Load subtitles in ./
> ==========================================================================
> Requested audio codec family [mpg123] (afm=mpg123) not available.
> Enable it at compilation.
> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
> AUDIO: 48000 Hz, 2 ch, floatle, 256.0 kbit/8.33% (ratio: 32000->384000)
> Selected audio codec: [ffmp2float] afm: ffmpeg (FFmpeg MPEG layer-1 
> and layer-2 audio)
> ==========================================================================
> AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
> Starting playback...
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> VO: [vdpau] 1920x1080 => 1920x1080 Planar YV12
> A:71555.4 V:71556.4 A-V: -0.948 ct:  0.000   2/  2 ??% ??% ??,?% 0 0
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
> Bad stream state, please report as bug!
>
>
> It looks like skipping correctly in these transport streams with H264 
> 1080 interlaced is not trivial.
> However, mythfrontend has been skipping correctly for the last 15 
> years up to and including the current master.
> So it should be feasible to get this working also with the latest FFmpeg.
>
> In order to start somewhere I have replaced, in a copy of the current 
> master, the FFmpeg tree with the latest FFmpeg master and then hacked 
> away in the MythTV code so that it could work with an (almost) 
> unmodified ffmpeg tree.
> The great plan behind this is:
> - If it shows blocking behaviour then bisect the ffmpeg from the 
> latest version to something that is close to what is now in master. 
> This is why I want ffmpeg master because there is then a linear 
> sequence of commits instead of a tree.
> - If it does NOT show blocking behaviour then add the MythTV changes 
> one by one and check for blocking behaviour.
>
> However, while compilation is now OK, linking fails with unresolved 
> symbols.
> These are symbols that do show up as global in the object file but 
> then are local when included in the .so file.
> Example, for a file that I did add to libavcodec (that is the "almost" 
> unmodified):
>
> [klaas at modu libavcodec]$ nm libmythavcodec.so | grep ff_codec_type
> 00000000006b4200 t ff_codec_type_string
> [klaas at modu libavcodec]$ nm utils-mythtv.o | grep ff_codec_type
> 0000000000000940 T ff_codec_type_string
> [klaas at modu libavcodec]$ readelf -s utils-mythtv.o | grep ff_codec_type
>    181: 0000000000000940   128 FUNC    GLOBAL DEFAULT    1 
> ff_codec_type_string
> [klaas at modu libavcodec]$ readelf -s libmythavcodec.so | grep ff_codec_type
>  20731: 00000000006b4200   128 FUNC    LOCAL  DEFAULT   12 
> ff_codec_type_string
>
> Note that there are more unresolved who are not from a file that I added.
> This is the complete list from linking programs/mythavtest:
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ffurl_close'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ffurl_seek'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ffurl_open'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ff_ue_golomb_vlc_code'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ffurl_write'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ffurl_read'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ff_se_golomb_vlc_code'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ff_read_frame_flush'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ff_codec_type_string'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ffurl_size'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ff_golomb_vlc_len'
> /usr/bin/ld: ../../libs/libmythtv/libmythtv-32.so: undefined reference 
> to `ff_codec_id_string'
> The two ff_codec_.. functions are in file avcodec/utils-mythtv.c and 
> they can be moved to outside FFmpeg.
> I would have done that if it were the only unresolved symbols.
>
> This is basically where the project is currently halted....
>
> Klaas.
>
>
Those ff_ and ffurL_ functions are in FFmpeg/libavformat/url.h. They are 
exposed in our version of ffmpeg by updating libavformat/libavformat.v. 
You can resolve this by patching libavformat/libavformat.v.

_FFmpeg's version of __libavformat/libavformat.v_

LIBAVFORMAT_MAJOR {
     global:
         av*;
     local:
         *;
};

_Our Version of __libavformat/libavformat.v_

LIBAVFORMAT_MAJOR {
     global:
         av*;
         ffurl_read;
         ffurl_read_complete;
         ffurl_seek;
         ffurl_size;
         ffurl_protocol_next;
         ffurl_open;
         ffurl_open_whitelist;
         ffurl_close;
         ffurl_write;
         url_*;
         ff_timefilter_destroy;
         ff_timefilter_new;
         ff_timefilter_update;
         ff_timefilter_reset;
         get_*;
         put_*;
         ff_codec_get_id;
         ff_read_frame_flush;
     local:
         *;
};

Note: In the latest 4.4.1, /ffurl_open/ is no longer defined, and you 
have to change the calls to /ffurl_open_whitelist/, with three extra 
nullptr parameters added to the call. This change has already been made 
in the devel/ffmpeg_resync branch.

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20211122/02ff1b1e/attachment.htm>