Open ulmus-scott opened 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.
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.
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.
@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.
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.
I can send you the whole transport stream but it's pretty huge. I don't have a great place to readily host it.
@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.
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
, whereSOME_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.
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
#ifdef
ed out and the file referenced is created in an out of tree patch to FFmpeglibavutil/
[x] internal.h see https://github.com/MythTV/mythtv/pull/416
[x] mythtv/libs/libmythtv/mythdeinterlacer.cpp: see https://github.com/MythTV/mythtv/pull/487