search

HomeOfAviSynthPlusEvolution / L-SMASH-Works

Forked from VFR-maniac/L-SMASH-Works; hydra3333/L-SMASH-Works; l33tmeatwad/L-SMASH-Works; HolyWu/L-SMASH-Works; AkarinVS/L-SMASH-Works.
89 stars 15 forks source link

Error opening MPEG-TS files: Error getting frame property "_Matrix" #6

Closed JJKylee closed 3 years ago

JJKylee commented 3 years ago

Here's the script code:

LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\Dual\L-SMASH-Works\LSMASHSource.dll")
LWLibavVideoSource("D:\Test\LG New York HDR UHD 4K Demo (PQ).ts", cachefile="D:\Test\LG New York HDR UHD 4K Demo (PQ)_temp\temp.lwi", prefer_hw=0, format="YUV420P10")

And the screenshot of the error (AvsPmod v2.6.8.7)

L-SMASH-Works_TS_error_20210728

Error getting frame property "_Matrix": property is not set
([ScriptClip], line 1)

This is the same video opened with HolyWu's 20210423 build:

L-SMASH-Works_HolyWu_opening_TS_20210728

And the same video opened with ffms2 (87bae19 StvG, here)

ffms2_opening_TS_20210728

Asd-g commented 3 years ago

You can try the latest version.

JJKylee commented 3 years ago

It works alright now. Many thanks. 😊

JJKylee commented 3 years ago

Sorry, but I was hasty in closing this issue thread.

Now the preview opens OK but the pixel type is incorrectly set to YV12 by default (without the format option) for the same file, whose actual pixel type is YUV420P10.

I've seen the same issue with another HDR video (HLG YUV420P10): here.

Asd-g commented 3 years ago

I guess you're testing with hardware decoding again because with software decoding I cannot reproduce the issue. Try this test ver if it's ok with hardware decoding. LSMASHSource_testhw.zip

JJKylee commented 3 years ago

Thanks.

With the new binary, I've run into this weird phenomenon.

The first PQ HDR10 sample opens well with or without prefer_hw=1 (cache file deleted before each load).

Software decoding:

L-SMASH-Works_TS_HDR_PQ_20210729

Hardware decoding:

L-SMASH-Works_TS_HDR_PQ_HW_20210729

However, with the HLG HDR sample, it's weird.

Software decoding: works well

L-SMASH-Works_TS_HDR_HLG_20210729

But when I delete the cache file and put hardware decoding option, the pixel type becomes weird.

Hardware decoding:

L-SMASH-Works_TS_HDR_HLG_HW_20210729

I have no clue. 😓

Asd-g commented 3 years ago

What's NVIDIA driver version? You need 456.71 or newer. Do older LSMASHSource versions decoding correctly? Any difference if you remux the file into mkv? Unfortunately I don't have NVIDIA GPU to test myself.

JJKylee commented 3 years ago

What's NVIDIA driver version?

My Nvidia driver is NVIDIA Studio driver 471.41 (the most recent one released on July 19, this year).

Do older LSMASHSource versions decoding correctly?

I tested with HolyWu's 20210423 build, and have found that it suffers the same issue. I was not testing it thoroughly back then and didn't find it out. 😓

Any difference if you remux the file into mkv?

I'm observing this phenomenon here. Although the reported pixel type of the AviSynth+ script is YUV420P8, the resulting pixel type becomes YUV420P10 if stream-copy-remuxed to MKV via mkvmerge. It's understandable because stream copy means no decoding.

--------------------------- AviSynth Script ---------------------------

LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\Dual\L-SMASH-Works\LSMASHSource.dll")
LWLibavVideoSource("D:\Test\TravelXP 4K HDR HLG Demo (HLG).ts", cachefile="D:\Test\TravelXP 4K HDR HLG Demo (HLG)_temp\temp.lwi", prefer_hw=1)

------------------------- Source Script Info -------------------------

Width     : 3840
Height    : 2160
Frames    : 14665
Time      : 04:53.300
Framerate : 50 (50/1)
Format    : YUV420P8

------------------------- Target Script Info -------------------------

Width     : 3840
Height    : 2160
Frames    : 14665
Time      : 04:53.300
Framerate : 50 (50/1)
Format    : YUV420P8

---------------------------- Muxing to MKV ----------------------------

mkvmerge 59.0.0

D:\Utilities\MKVToolNix\mkvmerge.exe -o "D:\Test\TravelXP 4K HDR HLG Demo (HLG).mkv" --no-audio --no-subs --no-chapters --no-attachments --no-track-tags --no-global-tags "D:\Test\TravelXP 4K HDR HLG Demo (HLG).ts" --no-video --no-subs --no-chapters --no-attachments --no-track-tags --no-global-tags --audio-tracks 1 --language 1:und --track-name "1:" --default-track 1:0 --forced-track 1:0 "D:\Test\TravelXP 4K HDR HLG Demo (HLG).ts" --ui-language en

...
...

General
Complete name            : D:\Test\TravelXP 4K HDR HLG Demo (HLG).mkv
Format                   : Matroska
Format version           : Version 4
File size                : 698 MiB
Duration                 : 4 min 59 s
Overall bit rate         : 19.6 Mb/s
Encoded date             : UTC 2021-07-30 02:03:14
Writing application      : mkvmerge v59.0.0 ('Shining Star') 64-bit
Writing library          : libebml v1.4.2 + libmatroska v1.6.4

Video
ID                       : 1
Format                   : HEVC
Format/Info              : High Efficiency Video Coding
Format profile           : Main 10@L5.1@Main
Codec ID                 : V_MPEGH/ISO/HEVC
Duration                 : 2 min 40 s
Bit rate                 : 36.1 Mb/s
Width                    : 3 840 pixels
Height                   : 2 160 pixels
Display aspect ratio     : 16:9
Frame rate mode          : Variable
Frame rate               : 91.145 FPS
Original frame rate      : 50.000 FPS
Color space              : YUV
Chroma subsampling       : 4:2:0
Bit depth                : 10 bits
Bits/(Pixel*Frame)       : 0.048
Stream size              : 691 MiB (99%)
Writing library          : ATEME Titan File 3.7.6 (4.7.6.0)
Default                  : Yes
Forced                   : No
Color range              : Limited
Color primaries          : BT.2020
Transfer characteristics : HLG
Matrix coefficients      : BT.2020 non-constant

...
...

(The duration becomes different than the source file, and I guess it's in turn an issue with mkvmerge.)

Now I suspect it might be a driver issue although I'm not sure. Or maybe the sample file is corrupt(?). Anyway, I'm totally at a loss now. 😖

Since software decoding seems to be working OK, I'll go with software decoding first when it comes to HDR TS files.

Thanks for your help.

JJKylee commented 3 years ago

For comparison, I used DGDecNV(=DGIndexNV + DGSource), another indexer + source filter that can frameserve video files using Nvidia graphics card to open the above mentioned HLG HDR video.

For reference, DGSource decodes the video stream using the Nvidia graphics card without any particular option by default, based on its dgi index file generated by DGIndexNV. When the source file has 10-bit depth, the decoded video is delivered as 16-bit and is reported to Avisynth+ as pixel format P016(YUV420P16).

The script code is as follows.

LoadPlugin("D:\Utilities\StaxRip\Settings\Plugins\Dual\DGDecNV\DGDecodeNV.dll")
DGSource("D:\Test\TravelXP 4K HDR HLG Demo (HLG)_temp\TravelXP 4K HDR HLG Demo (HLG).dgi")

And unlike LWLibavVideoSource, I could see that DGSource opens the TS file without issues (with the exception of dropped frames).

DGDecNV_DGSource_TS_HDR_HLG_HW_20210730

So it turns out that it's not a video driver issue.

Asd-g commented 3 years ago

LWLibavVideoSource (software decoding) is giving the correct pixel type but the clip (HLG HDR video) isn't decoded properly. Check the first few frames. FFmpeg is giving errors too. Using ffmpeg to remux the video stream into .hevc and then using mkvmerge to remux it to mkv looks fine. Using mkvmerge to directly remux the video stream from .ts into mkv gives different result than the former process. I'm curious what result gives DGDecNV - similar to directly remuxing into mkv or remuxing into hevc+mkv.

Anyway, I would recommend to not rely ffmpeg decoding for .ts and similar.

JJKylee commented 3 years ago

Got it. Thanks for the detailed info.

kedaitinh12 commented 3 years ago

Don't know if it's same issue with prefer_hw=1 in Vapoursynth, you can check and notice to AkarinVS. He will fix it in GPU support and Asd-g will backport to avisynth ver