search

MythTV / mythtv

The official MythTV repository
https://www.mythtv.org
GNU General Public License v2.0
704 stars 345 forks source link

enable use of system FFmpeg #428

Open ulmus-scott opened 2 years ago

ulmus-scott commented 2 years ago

In order to use the system supplied FFmpeg, we need to:

1. eliminate/upstream our modifications

Investigate subtitle changes/additions:

MPEG-TS changes

2. Only use the following FFmpeg headers (eliminate use of internal FFmpeg headers)

Headers installed by the -dev packages on Ubuntu:

libavcodec/:

ac3_parser.h adts_parser.h avcodec.h avdct.h avfft.h bsf.h codec_desc.h codec.h codec_id.h codec_par.h d3d11va.h dirac.h dv_profile.h dxva2.h jni.h mediacodec.h packet.h qsv.h vaapi.h vdpau.h version.h videotoolbox.h vorbis_parser.h xvmc.h

libavdevice/:

avdevice.h version.h

libavfilter/:

avfilter.h buffersink.h buffersrc.h version.h

libavformat/:

avformat.h avio.h version.h

libavutil/:

adler32.h aes_ctr.h aes.h attributes.h audio_fifo.h avassert.h avconfig.h avstring.h avutil.h base64.h blowfish.h bprint.h bswap.h buffer.h camellia.h cast5.h channel_layout.h common.h cpu.h crc.h des.h dict.h display.h dovi_meta.h downmix_info.h encryption_info.h error.h eval.h ffversion.h fifo.h file.h film_grain_params.h frame.h hash.h hdr_dynamic_metadata.h hmac.h hwcontext_cuda.h hwcontext_d3d11va.h hwcontext_drm.h hwcontext_dxva2.h hwcontext.h hwcontext_mediacodec.h hwcontext_opencl.h hwcontext_qsv.h hwcontext_vaapi.h hwcontext_vdpau.h hwcontext_videotoolbox.h hwcontext_vulkan.h imgutils.h intfloat.h intreadwrite.h lfg.h log.h lzo.h macros.h mastering_display_metadata.h mathematics.h md5.h mem.h motion_vector.h murmur3.h opt.h parseutils.h pixdesc.h pixelutils.h pixfmt.h random_seed.h rational.h rc4.h replaygain.h ripemd.h samplefmt.h sha512.h sha.h spherical.h stereo3d.h tea.h threadmessage.h timecode.h time.h timestamp.h tree.h twofish.h tx.h version.h video_enc_params.h xtea.h

libpostproc/:

postprocess.h version.h

libswresample/:

swresample.h version.h

libswscale/:

swscale.h version.h

Used internal headers

libavformat/

libavcodec

libavutil/

ulmus-scott commented 2 years ago

Regarding libavcodec/get_bits.h (and golomb.h), we would need to write our own (or use someone else's) C++ version.

Alternatively, we could use FFmpeg's parsers: FFmpeg: Frame parsing Most of the information we use is stored in the AVCodecParserContext, but the frame rate is stored in the complementary AVCodecContext.

ulmus-scott commented 2 years ago

libavutil/internal.h appears to be for 

// This can be enabled to allow detection of additional integer overflows with ubsan
//#define CHECKED
...
// For debuging we use signed operations so overflows can be detected (by ubsan)
// For production we use unsigned so there are no undefined operations
#ifdef CHECKED
#define SUINT   int
#define SUINT32 int32_t
#else
#define SUINT   unsigned
#define SUINT32 uint32_t
#endif

SUINT is conditionally used once in libavcodec/golomb.h in get_ur_golomb_jpegls(), which is itself not used in the MythTV code.

KungFuJesus commented 1 year ago

I realize this isn't the most appropriate place to bring this up but...there seems to be a regression that was introduced into FFmpeg on the version that's incorporated into the fixes/32 branch. There are blocking artifacts with MPEG-TS demuxing when using nvdec or VDPAU for decoding (and I've seen evidence that va-api also occasionally sees this issue). It's particularly noticeable on interlaced content for some reason. For a time, mpv also seemed to have this issue, which as far as I know leverages my system installed FFmpeg. Some time recently I updated FFmpeg to 4.4.2 and those artifacts disappeared. Whether that was working around latent ffmpeg behavior on their part (I searched their repo, couldn't find any meaningful messages) or FFmpeg fixed a bug, I'm not sure.

I will say the closest thing I've found to evidence and a workaround for this in the mythtv repo was the H264 blocking artifact fix here: https://github.com/MythTV/mythtv/commit/c257bacbfe

All of this is to say, I'm hoping a release is turned around with these fixes soon - it'd be great to see if this regression is fixed.

ulmus-scott commented 1 year ago

@KungFuJesus You should have opened a new bug report.

Does your blocking look like https://trac.ffmpeg.org/attachment/ticket/9532/tweevoortwaalf_ffmpeg.png ? Because that is what the commit you mentioned fixed. That blocking occurred at the start and (sometimes) on skipping.

KungFuJesus commented 1 year ago

Yes, though blocking artifacts I'm sure is a broad symptom. It seems most common when there's a moment of fast transition where the compression has to make more out of the bitrate. It goes away when using software decoding or when the mpeg transport stream is removed with a lossless transcode. I'll get you a screenshot.

KungFuJesus commented 1 year ago

blocking_artifact

KungFuJesus commented 1 year ago

I can send you the whole transport stream but it's pretty huge. I don't have a great place to readily host it.

ulmus-scott commented 1 year ago

@bennettpeter Thoughts on this blocking? It sounds different to me from what Klaas found. If you think it worthwhile, I can try merging the upstream FFmpeg release/4.4 into ours again for fixes/32.

@KungFuJesus You can chop an MPEG Transport Stream at any arbitrary place, e.g. with dd, to create a smaller sample.

when the mpeg transport stream is removed with a lossless transcode.

So if I understand correctly, the blocking only occurs on .ts files and not after lossless cutting and remuxing to .mpg?

What hardware are you using and is this replicable on another system?

I would like you to attach a log from mythfrontend -v playback:debug --logpath=SOME_PATH, where SOME_PATH is a valid path, of playing a file that shows the blocking.

KungFuJesus commented 1 year ago

So if I understand correctly, the blocking only occurs on .ts files and not after lossless cutting and remuxing to .mpg?

Yes from what I remember.

What hardware are you using and is this replicable on another system?

Yes, every system I've tested on using vdpau or nvdec decoding reproduces this. This particular system is fairly old hardware but I've produced this on Maxwell and pascal based hardware using both nvdec and vdpau.

I would like you to attach a log from mythfrontend -v playback:debug --logpath=SOME_PATH, where SOME_PATH is a valid path, of playing a file that shows the blocking.

Will do so when I'm home. I can also cut up a short duration TS if it's feasible to upload on GitHub. I saw one person around November of last year report a similar issue on the mythtv forums. I'll open up a new issue with all the details and sample file, log output, forum post, etc.