LAV Filters - DirectShow Media Splitter and Decoders

[VictorLS]

Big Lies.
Proof it, please. Your forks not count ;)
When I've asked deinterlacing of quasi-interlaced channels like 20190815-114627_France24 English.ts (38 MB, 59s) https://disk.yandex.ru/d/quskGJLUjn7bqA - btw it's left from 33e1 11758v:
https://i.postimg.cc/Tpk2wZNx/33e1-10758v-Left.png (https://postimg.cc/Tpk2wZNx)
But here http://forum.doom9.org/showthread.php?p=1846662#post1846662 and here http://forum.doom9.org/showthread.php?p=1847554#post1847554 I was spoken if ffmpeg don't support deinterlacing of such half-height streams so it's impossible LAV Video Decoder can do it. Btw I've found way to do high quality deinterlacing with my AviSynth script and ffdshow raw video filter (with software and even hardware deinterlacing working well on nVIDIA's videocards) or AviSynth filter (only with software Yadif x2 deinterlacing that more actual on AMD's and Intel's videocards which have poorer quality hardware deinterlacing than nVIDIA).

But I believe nevcairiel will can to do automatic deintelacing (to don't change ordinary Auto/Auto settings in LAV Video Decoder) of old ordinary interlaced 20200202-191258_Racing Channel.ts (164 MB, 7min34s) https://disk.yandex.ru/d/U-CvCg8fAF5Djw - I thought it was exception channel so didn't ask that before but today I've received 33e1 12722v16730 Polsat News HD HEVC:
https://i.postimg.cc/Q9WKkjPc/33e1-12722v16730-Polsat-News-HD-HEVCon.png (https://postimg.cc/Q9WKkjPc)
and record two files 20210821-144140_Polsat News HD HEVC.ts (24 MB, 1min5s) https://disk.yandex.ru/d/6QO-DmcBvT-fiw and 20210821-144958_Polsat News HD HEVC.ts (11 MB, 29s) https://disk.yandex.ru/d/-8sldJNRs2DhIg -
look at moving arrow at the end of second Polsat's file
Now deinterlacing of that ordinary interlaced h265 (HEVC) three files works only with follow settings in LAV Video Decoder (I'd want it'll work with Auto/Auto settings):
https://i.postimg.cc/LnSgLKVZ/LAVvideo-Decoder-Deinterlace-Settings.png (https://postimg.cc/LnSgLKVZ)

[Balling]

@VictoLS
Those new two files are not interlaced, these are 25.000 HEVC progressive. Sigh. First one is indeed interlaced hevc, bottom first.

"Your forks do not count " Nev also uses a fork. Some commits are very strange, like https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=422f0a61367f068fb8b1b9ab8cc2eee1808c803c (IMHO 16 should be enough, some tried 64, but it is just strange).

"Video Decoder can do it" It can recognise it, but not even x2 the demisions on one type of interlaced hevc due to ffmpeg fixes (top first, see https://trac.ffmpeg.org/attachment/ticket/5514/src13_interlaced_cut.265). There are two here (second can be only done with hwupload workaround) and more possible in the spec, including soft telecine progressive fields and field duplication and triplication. You screenshot setting do not allow for decoding of your first sample correctly.

Workaround is ffplay src13_interlaced_cut.265 -vcodec hevc_cuvid -vf weave,hwupload_cuda,yadif_cuda=mode=0:parity=0:deint=0,hwdownload,format=nv12

-vcodec is still the only option in ffplay. Very funny. Using "s" to step frame by frame you can see that both top and bottom first are correctly decoded, which is nice.

[nevcairiel]

Some commits are very strange, like https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=422f0a61367f068fb8b1b9ab8cc2eee1808c803c (IMHO 16 should be enough, some tried 64, but it is just strange).

What are you even talking about? That commit is from ffmpeg upstream master, and its for mpegts muxing, code thats not even compiled for LAV Filters since its a demuxer/decoder, not a muxer.

As for HEVC interlaced, I have no interest in that topic. If you want it to be supported, convince someone to work on it for ffmpeg, then LAV will automatically inherit it.

[VictorLS]

nevcairiel
I see, thanks for reply.

[Balling]

I meant this commit, sorry. https://git.1f0.de/gitweb/?p=ffmpeg.git;a=commit;h=9cb8c3a70facbdc9a73750af2c63fcd723eb6ba2;js=1

[huhn]

CPU with much more cores are pretty common now and this is not only for real time decode.

[VictorLS]

Those new two files are not interlaced, these are 25.000 HEVC progressive. Sigh.
Just read https://forum.videohelp.com/threads/393570-Interlace-Checking
First one is indeed interlaced hevc, bottom first.
It seemed you're right - I haven't know how to call such France24 English.ts streams so I called them quasi-interlaced. May be you can give a link to official document (i.e. ITU) where such France24 English.ts streams are called indeed interlaced?
And yes - in yadif of my script (or in ffdshow raw video decoder Output for hardware deinterlacing) I set Bottom Field first.

[Balling]

CPU with much more cores are pretty common now and this is not only for real time decode.

MAX_SLICES is for slice thread decoding, am I right... Yet somehow the original increase was caused by bria SIP videophone avc sample https://github.com/FFmpeg/FFmpeg/commit/6fd91fa11909f27902498648680dbb3d13f1f175 and here increase to 64 happens thanks to HW encoder using h264 (multithreaded SW part of HW decoding, right, genious...) https://github.com/wang-bin/QtAV/issues/923

I was not able to reproduce!

[huhn]

slices are also defined while encoding.

i'm not going into the h264 spec to figure out how many slices a decoder has to support and i don't go into the decode spec to figure out if a file encdode with 256 slices need max slices set to 256.

and the github has a bug shown where increasing the max slices help a file with no counter argument where it would hurt.
the bug ticket doesn't go into why it helps.

so why is it odd if no case is know where it hurts? while on the other hand we have indication that increasing slice number get's more and more popular

[Balling]

@VictorLS

Please point to a particular post in that thread. I suppose the arrow in 20210821-144958_Polsat News HD HEVC.ts sample may have confused you, but that is just a style choice, since after the first interlaced look it is no longer interlaced looking. In your second sample the news studio is progressive but the camera they are overlaying with is interlaced and they are not deintelacing, well, dumb. But that does not make the stream interaced. As for the ITU-T Rec. H.265 spec, this is specified on page 326, "Table D.2 – Interpretation of pic_struct", "Top field paired with previous bottom field in output order" and "Bottom field paired with previous top field in output order" are used (those two both) in your sample.

[nevcairiel]

A too low value for MAX_SLICES has a performance penality for software decoding, as well as just breaking hardware decoding. A higher value does nothing but cost a tiny amount of memory, eg. in software decoding its like 33kb for the 256 slices. That is literally nothing in comparison to the actual slices or frames.
There is no question what value to use, because the answer is always that one that uses a tiny bit more memory but ensures everything decodes as expected. The value of 256 was recommended by one of the primary authors of x264 as a reasonable maximum by the way, and isn't just randomly taken from nowhere.

MAX_SLICES is for slice thread decoding, am I right...

The value has nothing to do with multithreading, it entirely depends on how many slices a video uses. So no, you are not right.

[kasper93]

@Balling @VictorLS

Lots of words, but not much content... Victor even pointed to post that referenced related libavcodec issues for HEVC interlaced support.
https://trac.ffmpeg.org/ticket/4141
https://trac.ffmpeg.org/ticket/5514

As we can see there is little to none interest in those issues and unless you convince someone to work on it, it will stay this way. And rightfully so, interlaced HEVC is not something that should really be used in present day. All HEVC broadcast in Poland are currently in testing stage, including those Polsat samples. I've also posted different sample in mentioned issues for reference, but in the end of the day I don't believe this format will be used.

Like with everything if those interlace HEVC files became more widespread probably someone will contribute the support eventually, but until then there is little incentive to work on this.


Side-note, Poland will be switching to DVB-T2 (and HEVC) next year and in technical requirements issued by our government there is no interlaced formats at all. (sorry for polish text, but you can read the tech keywords :))

https://isap.sejm.gov.pl/isap.nsf/download.xsp/WDU20210000515/O/D20210515.pdf
Dla DVB-T2 za podstawowe przyjęto parametry odbiornika cyfrowego zdefiniowanego w ETSI TS 101 154 [15] dla
poziomu 4.1 HDTV: 50 Hz HEVC HDTV 8-bit (rozdzielczości 1920 x 1080 p50, 1280 x 720 p50) MPEG-2 Audio Warstwa 2
i E-AC-3 audio. W przypadku odbiornika telewizyjnego zdolnego do wyświetlania obrazów UHD, odbiornik DVB-T2
obsługuje także format określony w ETSI TS 101 154 [15] w pkt 5.14 HEVC HDR UHDTV IRD wykorzystujący HLG10
oraz HEVC HDR UHDTV IRD wykorzystujący PQ10, Main 10 Profile, Main Tier dla UHDTV o rozdzielczości 3840 x 2160
oraz AC-4 audio.

[Balling]

@kasper93 It is being used right now on Ostankino's DVB-T2. Interlaced hevc, bottom first. Also those samples are DVB-S(2), i.e. satellites. Nobody is going to switch from them. https://www.lyngsat.com/Eutelsat-33E.html
@nev
P.S. Apparently you can even have 8192 slices. And that will need actually that value in ffmpeg. Oogh. What a joke. https://forum.doom9.org/showthread.php?p=1320333#post1320333

Then the question is how would you recognize amount of slices in the body? Oogh. And recompile it on the fly. JIT in C. Also HW needing more slices defined is totaly a bug.

@VictorLS You can parse hevc bitstream ffmpeg -i "RTRN 770 03-26 03-26-25.ts" -map 0:17 -c copy -bsf:v trace_headers -f null -

And search for pic_struct. BTW, not cool that you removed the sample (I have it).

[GMJCZP]

Hi, I was doing some tests with BeHappy and I noticed that the TrueHD FFMPEG audio files can only be played from the beginning, if you want to play it from the middle you will not be able to. Here's a sample:

Sample (http://www.filedropper.com/samplethd)

[filler56789]

Hi, I was doing some tests with BeHappy and I noticed that the TrueHD FFMPEG audio files can only be played from the beginning, if you want to play it from the middle you will not be able to. Here's a sample:

Sample (http://www.filedropper.com/samplethd)

I presume that that's normal and expected, because TrueHD files are VBR streams which lack the index of a proper container.

[nevcairiel]

That sounds about right, seeking in raw files is often not supported. Put it into a mka or such if you want a better experience.

[GMJCZP]

Thank you both for your answers.
@nevcairiel: What has happened to what I raised in my post #24536 (https://forum.doom9.org/showthread.php?p=1945905#post1945905). ?

[Balling]

.thd files are capable of seeking. https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4490/6zc.thd

P.S. Just like .eac3 or .flac without SEEKTABE (ffmpeg does not support SEEKTABLE yet and flac ref. encoder has a slow bug to encode SEEKTABLE) or MPEG-TS unless it is a buggy LG Chess sample or Dolby E since March (commit https://github.com/FFmpeg/FFmpeg/commit/47d0b86cf3d83abdcf60c5c224bbf6f4a0198d5d). This is a bug in ffmpeg "Lossless check failed" which is either because of file created by old very buggy ffmpeg or ac3 presence. AND NO. Mediainfo no longer shows ac3 presence due to a bug. https://forum.doom9.org/showpost.php?p=1882651&postcount=1660

[SuperLumberjack]

Hello nevcairiel! :)

I have an issue that I posted here with Media Player Classic and some dropped frames which are apparently caused by LAV Audio Decoder: https://forum.doom9.org/showthread.php?t=183149

A nice user recommended to me to talk to you about this problem.

In fact, I have some dropped frames in movies with big soundtracks, in Dolby TrueHD or Dolby Atmos for example, but some movies with DTS-HD Master Audio too.

I thought that the problem came from MadVR, but I tried other video renderers like "EVR custom pres.", I changed modes in LAV Video Decoder, disabled the hardware acceleration, etc., but I noticed that the problem disappeared when I unchecked the "Auto A/V Sync correction" option in LAV Audio Decoder.

But it's only with bitstreaming, not if I choose PCM.

I tried to uninstall Media Player Classic and the filters (I used the K-Lite codecs pack for a long time, but I know that lots of people don't like it) and I started from zero with just Media Player Classic BE, LAV filters and MadVR, all in the last version, for no ambiguity

But I still have the same problem. It's strange, because even with my old laptop I hadn't that :confused:

And I have a AMD Ryzen 5 3600X CPU with a Nvidia GeForce RTX 2060 GPU and 16 Gb of RAM.

It should be enough for 1080p videos no ? :o

So I don't know what to do.

Thanks for your help! ;)

[Balling]

Okay, your thd sample is actually 7 seconds long (00:00:07.61 + 16 frames, all together 8458 frames, duration of frames is not 1200 fps but 1 102.5 fps, cool, so actual length is 7.671 seconds) and thus when you seek in ffplay it will just seek to the end, since left/right is 10 seconds. Now, to close ffplay when it is over your need -autoexit option:
ffplay -autoexit -i .\sample.thd

mpv will allow to seek 5 seconds and it does seek there on your sample. Ooogh. How I did not see it immediately?

BTW, full parsing in mediainfo (frame count is from 0, not from 1) E496A HD - PTS 00:00:07.671 - 8457 (0x2109) (128 bytes)
E496A Header (4 bytes)
E496A CRC?: 12 (0xC) - (4 bits)
E496A Size: 64 (0x040) - (12 bits)
E496C Timestamp?: 10560 (0x2940)
E496E substream_directory (2 bytes)
E496E extra_substream_word: No
E496E restart_nonexistent: Yes
E496E crc_present: Yes
E496E reserved: No
E496E substream_end_ptr: 61 (0x03D) - (12 bits)
E4970 (Data): (122 bytes)
E49EA --------------------------
E49EA --- AC-3, finished ---
E49EA --------------------------

[GMJCZP]

Okay, your thd sample is actually 7 seconds long (00:00:07.61 + 16 frames, all together 8458 frames, duration of frames is not 1200 fps but 1 102.5 fps, cool, so actual length is 7.671 seconds) and thus when you seek in ffplay it will just seek to the end, since left/right is 10 seconds. Now, to close ffplay when it is over your need -autoexit option:
ffplay -autoexit -i .\sample.thd

mpv will allow to seek 5 seconds and it does seek there on your sample. Ooogh. How I did not see it immediately?

BTW, full parsing in mediainfo (frame count is from 0, not from 1) E496A HD - PTS 00:00:07.671 - 8457 (0x2109) (128 bytes)
E496A Header (4 bytes)
E496A CRC?: 12 (0xC) - (4 bits)
E496A Size: 64 (0x040) - (12 bits)
E496C Timestamp?: 10560 (0x2940)
E496E substream_directory (2 bytes)
E496E extra_substream_word: No
E496E restart_nonexistent: Yes
E496E crc_present: Yes
E496E reserved: No
E496E substream_end_ptr: 61 (0x03D) - (12 bits)
E4970 (Data): (122 bytes)
E49EA --------------------------
E49EA --- AC-3, finished ---
E49EA --------------------------

Just follow nevcairiel's recommendation. This also happens with the h264 and m2v files and once inside a suitable container the search is activated.

[Balling]

H264 and m2v are even more so capable of searching. For h264 this should be ideally implemented https://trac.ffmpeg.org/ticket/628

Of course there are some unseakable Annex B files. Like that one: https://github.com/wang-bin/QtAV/issues/923

[SuperLumberjack]

Hello again,

In fact, as I said, I have repeated frames when the "Auto A/V Sync correction" option is checked in LAV Audio Decoder on my desktop PC.

https://i.lensdump.com/i/ZfID3q.md.png (https://lensdump.com/i/ZfID3q)

But I have no problem with my old laptop bought in 2013... :confused:

https://i3.lensdump.com/i/ZcEO6D.md.png (https://lensdump.com/i/ZcEO6D)

And it is with the same cable!

[Balling]

You are using madvr there as can be seen by Ctrl-J menu.

[el Filou]

Does this happen only with this particular file, or with different types of files?
I see on the desktop it's using DXVA11 decoding, and not on the laptop, have you tried to change the decoder? Does this also happen if you use software decoding? Another thing to try: go to the Formats tab in LAV Video and uncheck "Use Microsoft WMV9 MFT decoder".
These are just wild guesses of course.

[SuperLumberjack]

Thanks for your answers! ;)

You are using madvr there as can be seen by Ctrl-J menu.

In fact, I uninstalled Media Player Classic and the filters and started from zero with Media Player Classic BE and all the filters updated.

Here are the active filters :

https://i.lensdump.com/i/ZcqxoZ.md.png (https://lensdump.com/i/ZcqxoZ)

But the problem is still the same. And no problem with my old laptop as I said and the same cable connected to the AV receiver.

Does this happen only with this particular file, or with different types of files?
I see on the desktop it's using DXVA11 decoding, and not on the laptop, have you tried to change the decoder? Does this also happen if you use software decoding? Another thing to try: go to the Formats tab in LAV Video and uncheck "Use Microsoft WMV9 MFT decoder".
These are just wild guesses of course.

No, I have dropped frames with other movies. But generally not with movies with a Dolby Digital sountrack for example.

In fact, after having tried everything related to the video, I wondered if it wasn't something else. So I just tried to switch from the Dolby TrueHD soundtrack (English) to the Dolby Digital soundtrack (French) with "Animatrix" and then I noticed that there is no dropped frame.

I think it's more with some big soundtracks, but it's strange, because I copied my movies on a SSD, to be sure it's not caused by the HDD.

I tried with no hardware acceleration in LAV Video and with all the other modes. But same problem.

I tried to unckecked "Use Microsoft WMV9 MFT decoder" too and even with the internal filters of MPC.

In all cases, the problem appears when I use LAV Audio Decoder and that the "Auto A/V Sync correction" option is checked.

I have no problem with Windows Media Player or VLC either.

[ryrynz]

In all cases, the problem appears when I use LAV Audio Decoder and that the "Auto A/V Sync correction" option is checked.


Can you try the Sanear audio renderer (latest builds bottom of page) just to test if it changes anything?

https://github.com/alexmarsev/sanear/issues/20

[SuperLumberjack]

Yes, but it seems that it's already an internal filter in MPC. No ?
But I will try with the internal audio filter too.

Thanks for your help! ;)

[ryrynz]

True. Best of luck figuring it out.

[GMJCZP]

H264 and m2v are even more so capable of searching. For h264 this should be ideally implemented https://trac.ffmpeg.org/ticket/628

Of course there are some unseakable Annex B files. Like that one: https://github.com/wang-bin/QtAV/issues/923

I do not take the whole reason, before when I used Windows XP I installed Real Media Alternative to be able to reproduce the .ra files and the search was activated, now in Windows 7 I cannot do it, I still do not know why.

[SuperLumberjack]

True. Best of luck figuring it out.

:thanks:

[Balling]

I do not take the whole reason, before when I used Windows XP I installed Real Media Alternative to be able to reproduce the .ra files and the search was activated, now in Windows 7 I cannot do it, I still do not know why.

BTW, I just checked one .h265 file from Apple Dolby Vision screensavers. Due to NAL unit 62 (which has RPU) it cannot seek in it, while latest PowerDVD can. Yeah. Just a bug.

[SuperLumberjack]

Hello :)

I just want to bring updates. I tried with the internal MPC audio decoder instead of LAV Audio and I have no problem. Zero dropped frames!

https://i1.lensdump.com/i/ZbfMra.md.png (https://lensdump.com/i/ZbfMra)

https://i2.lensdump.com/i/ZbfY4e.md.png (https://lensdump.com/i/ZbfY4e)

So there is a problem with LAV Audio, but I don't know what :confused:

I will stay with MPC Audio Decoder for the moment. Thanks ryrynz! ;)

[ryrynz]

I will stay with MPC Audio Decoder for the moment. Thanks ryrynz! ;)

Wicked. Wonder what's going on there.

[SuperLumberjack]

Yes, strange! :o

[clsid]

Isn't it obvious? You already concluded that your issues only happened when using "Auto A/V Sync correction" in LAV Audio + bitstreaming.

[ryrynz]

It's enabled by default though.

If that's the case knowing what's going on here would be useful in fact that's entirely the reason why this option exists.

'If you encounter sync issues, disabling this option can help in debugging the source of the problem'

I really should just remove that option, turning it off does usually never help.


Probably a good thing that never happened.

[nevcairiel]

If you turn that option off, the result is desync. Thats not something you want. All the option does is ensure that audio stays in sync with the timestamps from the container.

[Siso]

If you turn that option off, the result is desync. Thats not something you want. All the option does is ensure that audio stays in sync with the timestamps from the container.

What about using reclock, is this option still needed if reclock syncs video and audio?

[nevcairiel]

The option is always needed. It should only ever do anything if there is a gap in the audio, and you don't want your gap to turn into a sync issue.
If anything goes wrong with bitstreaming, that would just be a bug somewhere. However I think the issues were even system dependent, which has me rather puzzled.

[nevcairiel]

I did just apply a change that might resolve the issue with TrueHD bitstreaming, as it wasn't properly accounting for varying number of samples in every bitstream frame, which is uncommon for bitstreaming and only happens with TrueHD. It should average out typically, but there might be some corner cases where it didn't, so properly counting them makes sense.

You can test it on tomorrows nightly build.

[SuperLumberjack]

OK. :thanks: nevcairiel!

I will try when I will have more time ;)

[ryrynz]

Nice. I was going to check this out as well to see if my setup did the same thing. Will look tonight and report back.

Well, no frame drop issues before and none after but I do wonder if this solves the occasional audio drop out I've experienced.

[clsid]

Sample with DTS audio (https://www.sendspace.com/file/azot2u) where AV Sync Correction causes playback issues.

[nevcairiel]

That file is just broken, and AV Sync correction does what its supposed to. The audio in that file has severe gaps, and AV sync correction fixes the timings to maintain sync - that can result in audible gaps in such a case where its really bad.
If you turn it off, you can see how much of a severe desync it already accumulates over this not even 2 minutes of playback.

Other decoders might have more frequent shorter gaps, but it will still have them, constantly. At a quick glance every 8 audio frames there is a gap of some sort. Hence broken file.

My guess is the video was slowed down from 25 to 24 fps, but the audio was not adapted properly. The audio timings look like it might be around 4% gaps. (or an audio stream from a wrong version was muxed in)

[clsid]

Thanks for checking.

Audio only sample (QDM2) (https://www.sendspace.com/file/ih2jhj) where it also has issues. In this case it might be a bug in FFmpeg, because I think this one once played ok with a much older LAV version.

[richardpl]

Plays fine with mpv.

[clsid]

The problem is specifically with the "AV Sync" algo from LAV. It plays fine with that disabled.

[huhn]

can you think about a block for 8K HEVC10 for AMD navi RDNA1 cards they accept it but the output is ~2 black frames a sec.

they can barely do 60 FPS UHD anyway.

[VictorLS]

@VictoLS
Those new two files are not interlaced, these are 25.000 HEVC progressive. Sigh.
Only by flags but really Polish broadcasters just wrongly don't change flags according to the transmitted progressive or interlaced content.
In your second sample the news studio is progressive but the camera they are overlaying with is interlaced and they are not deintelacing, well, dumb. But that does not make the stream interaced.
In that file not only camera but tickers are also interlaced
https://i.postimg.cc/68L9dJCh/Polsat.png (https://postimg.cc/68L9dJCh)
In new Polish channel Wydarzenia 24 HD HEVC which replace
33e1 12722v16730 Polsat News HD HEVC
I've recorded 20210907-071646_Wydarzenia 24 HD HEVC.ts (127 MB, 5min52s) https://transfiles.ru/wvr42 all studio (camera, tickers and so on) is clearly interlaced (but flags are progressive):
https://i.postimg.cc/D8CMbxMM/WYDARZENIA.png (https://postimg.cc/D8CMbxMM)
You can parse hevc bitstream ffmpeg -i "RTRN 770 03-26 03-26-25.ts" -map 0:17 -c copy -bsf:v trace_headers -f null -
And search for pic_struct.
Thanks for new for me method but I've used non-CommandLine method before to achieve same results.
Repeat - content is mostly interlaced but sometimes (mostly on adv) is progressive but flags are always progressive:
general_progressive_source_flag=1; general_interlaced_source_flag=0; field_seq_flag=0 и pic_struct=0
BTW, not cool that you removed the sample (I have it).
I suppose I've never seen namely RTRN 770 03-26 03-26-25.ts (RTRN is translating in Moscow) before so you're wrong but I'm sure that file was recorded with DVBViewer or more possible TransEdit and uploaded by another Russian guy with nick vramor ;)
But I believe you can reupload it (vramor will not object) I can analyse that stream with both methods.
At the end
First one is indeed interlaced hevc, bottom first.
I prefer call it quasi-interlaced meaning "quasiprogressive interlaced" (also I called such streams half-height in this thread)
As for the ITU-T Rec. H.265 spec, this is specified on page 326, "Table D.2 – Interpretation of pic_struct", "Top field paired with previous bottom field in output order" and "Bottom field paired with previous top field in output order" are used (those two both) in your sample.
Of course, I've read that but I can't find namely word indeed in all over both T-REC-H.265-201911-I!!PDF-E.pdf downloaded from https://www.itu.int/rec/T-REC-H.265-201911-I/en and https://www.etsi.org/deliver/etsi_ts/101100_101199/101154/02.06.01_60/ts_101154v020601p.pdf (I believe that's lastest so actual versions) with the search engine. Btw I have to admit quasi-interlaced (or such) absent there too as any other term to distinguish two different interlace methods I suppose.
Btw MainConcept HEVC Video Decoder I mentioned in this thrad can qualitatively deinterlace quasi-interlaced HEVC video with Set Deinterlacing to By Renderer and MPC-VR with checked Double the frame rate when deinterlacing suppose, why ffmpeg can't I don't know.