MediaInfoLib
MediaInfoLib copied to clipboard
MediaArea
Does not report interlacing on HEVC video contents
HEVC can hold progressive or interlaced contents; unfortunately mediainfo -f FILE does not report Scan type.
@JeromeMartinez https://github.com/MediaArea/MediaInfoLib/blob/de57976af11a24050f53d62bfaf16f3ddf70e9a2/Source/MediaInfo/Video/File_Hevc.cpp#L2045
This one. If it is 0 then video sequence is progressive, otherwise it is not (there are many variants from 0 to 12 in decimal, see T-REC-H.265-2018).
Ah, glad I found this report.
I've been troubleshooting why my my app is detecting some content as interlaced due to the absence of a ScanType value. It started happening mostly in newer 4K UHD HEVC and UK originating BD content.
For the same file with no ScanType field, ffmpeg.exe -i {inputname} -nostats -filter:v idet -an -f rawvideo -y nul shows there are no interlaced fields.
For now I had to disable de-interlacing based on the ScanType field being absent from MediaInfo CLI output, and rely on the much slower idet approach.
much slower idet approach.
That is always will be more correct especially considering that mkv does support HDR static metadata that (LOL) changes in between frames! Insane but true. And it is on Blu-ray, so m2ts also supports it. Mediainfo usually only scans the start of the file...
I ran through some of my samples with idet, and I don't think I reliably use the data for decision logic.
E.g.
if the percentage of interlaced frames > 0.0 then HandBrakeCLI -comb-detect -decomb
Repeat, and I still get a % > 0.0, so doing -decomb does not eliminate all interlaced frames.
From my samples very few had 0.0% interlaced frames per idet logic.
Insane but true.
So insane what? That you don't take the time to provide a patch? No need to use these accusing words.
mkv does support HDR static metadata that (LOL) changes in between frames!
As far as I understand, HDR static metadata are inside the raw stream without info in the container (mkv or whatever), so I don't understand your sentence accusing mkv here.
Additionally, here it is for MediaInfo issues, please let's stay on topic.
Mediainfo usually only scans the start of the file...
We could implement scan of all frames and report a percentage for each kind, if there is a need.
No need to use these accusing words
Mmmm, I was accusing HDR10 format. Not Mediainfo. Why you would think I was accusing Mediainfo?
inside the raw stream without info in the container
Well, whatever. It still changes, even though it should be static, that is totally strange. I can give a sample if you wanna play with it. And as I understand it, it works correctly everywhere.
We could implement scan of all frames
Is not it already there? In command line options, dunno, never tried it.
I found a very nice but crazy example of interlaced hevc with i and ib (field_seq_flag=1 and pic_struct=10,11 so top with next bottom/bottom with previous top or Top Field First) from our Ostankino in Moscow (DVB-T2). https://yadi.sk/d/bQkXgt900uEdkg
BTW, it looks like we have definitions of it from here https://sourceforge.net/p/mjpeg/mailman/message/9927377/
Variations of frame i-tag: i? unknown (use stream I-tag) im progressive, bottom field first iM progressive, bottom field first, repeat first field ip progressive, top field first iP progressive, top field first, repeat first field if film before pulldown (treat as 'ip' or do telecine) ib interlaced, bottom field first iB interlaced, bottom field first, repeat first field (maybe never used) it interlaced, top field first iT interlaced, top field first, repeat first field (maybe never used) ii interlaced (in 'Ib' stream treat as 'ib', else treat as 'it') ix progressive with last field (treat as 'ii' or exchange second field) ia after pulldown (treat as 'ii' or do reverse telecine)
@JeromeMartinez BTW, this stream is also unsupported in ffmpeg YET! But it is correct!
https://trac.ffmpeg.org/ticket/5514#comment:6
There are differences. In #4141, according to the comments the stream in question has field_seq_flag=1 but pic_struct=3, which is improper syntax, and the reference decoder does the same thing as FFMPEG (output half-height frames). With this particular elementary stream, field_seq_flag=1 and pic_struct=1 or 2 depending on which field it is, which is valid interlaced syntax. The reference decoder produces proper interlaced output frames with this test vector.
And my comment,
Please can you look into this example https://yadi.sk/d/bQkXgt900uEdkg (DVB-T2 ts stream from Ostankino, USSR channel 58, Russia)? Is it the second as well? BTW, about reference decoder, is that this one? https://sourceforge.net/p/mjpeg/mailman/message/9927377/ or what?
P.S. They already answered: it is field_seq_flag=1 and pic_struct=10,11 so top with next bottom/bottom with previous top or Top Field First. LOL, never seen before! Wow.
@ValZapod thanks for the test file, I'll implement its support when I have some free time (=not soon, especially with the nightmare of so many possibilities).
@JeromeMartinez Lol, i found the implementation even to check for the flag and use height * 2 in that case https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2446
@ValZapod thanks for the test file, I'll implement its support when I have some free time (=not soon, especially with the nightmare of so many possibilities).
Some markets have gone live with ATSC 3.0 and some of those stations are broadcasting in 1080i. I've used VLC (which can't play it correctly due FFMPeg's issue) to capture a short clip of our CBS station's broadcast and put it up on my onedrive share folder. MediaInfo reports it as 1920x540 file.
If anyone could use more or different clips from this station please let me know.
https://1drv.ms/u/s!Ap22nCAxKBS7j-Jr9Q8eX45gp2Uh7w?e=3miW5h
Thanks for the file. Remark that the web display is stretched :).
Yeah, my hope of Onedrive fixing their handling of 1080i hvec in the near future (or ever) is very, very (very) low. Fortunately my concern about it is equally low. ;-)
Thanks for the file. Remark that the web display is stretched :).
No, it should not be stretched. The H.265 standard says that in this case the height only applies to a field. I.e. it is 1920x1080.
No, it should not be stretched.
I was wanting to mean that OneDrive also has this issue ;-).
OneDrive also has this issue
Chrome, not Onedrive. I.e. also ffmpeg as Chrome uses ffmpeg remuxer + MojoVideoDecoder that uses MFF. See chrome://media-internals/ IMHO, Onedrive also uses ffmpeg on server side...
To my knowledge, it is onedrive generating the thumbnail which is stretched so it would be their handling that is also incorrect. Looks the same in Chromium and Firefox. Net at the moment is that pretty much everybody is broken though it would appear that FFMPeg getting fixed will fix most things.
Thanks for the file. Remark that the web display is stretched :).
Just realized that I'm a dummy who uploaded ATSC 1.0 samples. Sorry about that. The correct HVEC streams with 1080i (and 720p) are now on the folder.
When the pic_struct value is 1, 2, 9, 10, 11, 12, the interpretation is that this is a field sequence. In such a case, it would be nice if MediaInfo could report the correct frame height (it should be multiplied by 2), for example 1920x1080 instead of 1920x540.
