Fails on some files when being used during FEL baking

[jessielw]

It happens once maybe every 5 different remuxes I process while encoding with x265 in 2-pass mode.

Basic avs script that it would fail on:

LWLibavVideoSource("BL.mkv")
bl=ConvertBits(16)
LWLibavVideoSource("EL.mkv")
el=ConvertBits(16)
DoviBaker(bl, el, "el_RPU.bin", outYUV=true)
z_ConvertFormat(pixel_type="yuv420p10", dither_type="error_diffusion")

Basic vpy script that it would fail on:

import awsmfunc as awf

src = core.lsmas.LWLibavSource("source.mkv")
el = core.lsmas.LWLibavSource("EL.mkv")
src = awf.MapDolbyVision(src, el)

src = src.std.Crop(top=276, bottom=276)
# ... the rest of your filtering
src = vsutil.depth(src, 10, dither_type="error_diffusion")

Error:

x265 [FLAW]: 2nd pass has more frames than 1st pass (171176 vs 171173)
x265 [FLAW]: x265_encoder_open() failed for Enc, 

Utilizing FFMS2 or DGDecNV results in completed encodes/outputs. However, there is some caveats. It's hard to reproduce, it requires the full file to reproduce. Testing it with just a small snip doesn't make the crash happen. The file in question is around 70GB. If you would like to contact me I could FTP it to you or something of that nature so you could test it yourself if required/desired. Also, it fails when swapping from the first pass to the second pass. Meaning you will have to encode the entire first pass to reproduce it.

[Asd-g]

If you run only the script (for avs with avsmeter, avsr, ffmpeg, for vs with vspipe), is there a crash?

[jessielw]

So, testing a sample this is the error we get when using LWLibavVideoSource when using avsbenchmark.

This is for info

Note: the above failure doesn't happen when using ffms2 with this same file.

[Asd-g]

Sent an email for the video file.

[jessielw]

Grabbing the source again as I must have deleted it. I'll have it uploaded and i'll send you the link tomorrow before the afternoon.

…

________________________________ From: Asd-g ***@***.***> Sent: Tuesday, August 6, 2024 7:50 PM To: HomeOfAviSynthPlusEvolution/L-SMASH-Works ***@***.***> Cc: Jessie Wilson ***@***.***>; Author ***@***.***> Subject: Re: [HomeOfAviSynthPlusEvolution/L-SMASH-Works] Fails on some files when being used during FEL baking (Issue #67) Sent an email for the video file. — Reply to this email directly, view it on GitHub<#67 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQP2ER6ATFAWHPMKDNUGKDZQFOK5AVCNFSM6AAAAABLRDA43WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZSGM2TKMBQGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Asd-g]

Thanks. Downloaded. I'll take a look later.

[jessielw]

Awesome, let me know what you come up with!

[Asd-g]

There is archive password.

[jessielw]

There is archive password.

Sorry, I believe it is just lsmash. Grabbing it again to confirm, I'll have the file in 15 minutes. Confirmed, lsmash is the pw.

[L4cache]

Where is EL?

[jessielw]

I provided it via email to the author. The EL is inside the source.

[L4cache]

I provided it via email to the author. The EL is inside the source.

Sorry but the link is visible here... (you might want to remove it?)
I just didn't realized that it's a combined file.

[jessielw]

Thanks, I wonder what the point is sending something via email if it just publicly displays it? 🤣

But yes, in a remux the EL layer is embedded into the video stream (if it exists).

[L4cache]

At frame 171174 (second last frame) LWLibavSource can't or didn't insert RPU to frame props (FFMS2 can) and placebo.Tonemap crashed because of it. That's the culprit.

[jessielw]

At frame 171174 (second last frame) LWLibavSource can't or didn't insert RPU to frame props (FFMS2 can) and placebo.Tonemap crashed because of it. That's the culprit.

If this was the case, why does FFMS2 not fail under the same conditions?

[L4cache]

(FFMS2 can)

I didn't mean the file lacks RPU.
FFMS2 doesn't have the same problem.

It's weird one says this is a B frame another one says it's a P frame.

LWLibavSource:

FFMS2:

[jessielw]

It's reproducible every single time for sure!

[Asd-g]

ffprobe -i 1917.2019.UHD.BluRay.2160p.TrueHD.Atmos.7.1.DV.HEVC.REMUX-FraMeSToR.mkv -show_frames -select_streams v:0 > log.txt
When viewing log.txt, you will see that the frame before last doesn't have side_data_type=Dolby Vision RPU Data. This is the reason why L-SMASH-Works doesn't set DolbyVisionRPU frame prop for this frame.

ffms2 for this frame specifically also doesn't retrieve any rpu data but it uses already retrieved from previous frame(s).

I suggest to ask for fixing the video file so the rpu data is signaled for every frame.

Edit:

It's weird one says this is a B frame another one says it's a P frame.

From log.txt you can see that this frame is reported as pict_type=B.

Here log.txt if you don't want to generate it.

Btw using the latest ffms2 release the frame type is B.

[jessielw]

ffprobe -i 1917.2019.UHD.BluRay.2160p.TrueHD.Atmos.7.1.DV.HEVC.REMUX-FraMeSToR.mkv -show_frames -select_streams v:0 > log.txt
When viewing log.txt, you will see that the frame before last doesn't have side_data_type=Dolby Vision RPU Data. This is the reason why L-SMASH-Works doesn't set DolbyVisionRPU frame prop for this frame.

ffms2 for this frame specifically also doesn't retrieve any rpu data but it uses already retrieved from previous frame(s).

I suggest to ask for fixing the video file so the rpu data is signaled for every frame.

Unfortunately this is quite common when it comes to dolby vision sources. This can happen directly from the BluRay source in my experience. Is there a suggested work flow for detecting this issue and fixing the video file before processing or should L-Smash work like FFMS2 in this case?

[L4cache]

Btw using the latest ffms2 release the frame type is B.

I'm using FFMS2 version from https://github.com/FFMS/ffms2/releases/tag/5.0, is this version have some problem compared to the one you linked?
Also I use .hevc raw bitstream produced by dovi_tool, is FFMS2 better with MP4/MKV containers?

[jessielw]

Btw using the latest ffms2 release the frame type is B.

I'm using FFMS2 version from https://github.com/FFMS/ffms2/releases/tag/5.0, is this version have some problem compared to the one you linked? Also I use .hevc raw bitstream produced by dovi_tool, is FFMS2 better with MP4/MKV containers?

I believe these are two different forks. If you notice on the original repo it was 4 years without updates. https://github.com/FFMS/ffms2/releases

Where as stvg has updated his fork several times during that 4 year period on doom9 etc. https://codeberg.org/StvG/ffms2/releases

I'm not sure of how different they are and which would be considered better.

[Asd-g]

Unfortunately this is quite common when it comes to dolby vision sources. This can happen directly from the BluRay source in my experience. Is there a suggested work flow for detecting this issue and fixing the video file before processing or should L-Smash work like FFMS2 in this case?

Can you name such UHD-BD source that cause this issue? The UHD-BD (m2ts) has the streams separated while remuxes (mkv) have the streams merged. I've been told that the incorrectly merged streams can be the cause for this issue (old makemkv). Also remuxing the file with new makemkv should fix the issue.

To check if a remux has this issue you can use that ffprobe line I shared and check if the rpu side data exist for latest few frames. Or you can use this avs script:

LWLibavVideoSource(....)
ScriptClip("""
n = 0
for (i = 0, FrameCount() - 1)
{
current_frame = i
if (propGetType("DolbyVisionRPU") == 0)
{
    n = 1
}
}
return n == 1 ? Subtitle("no rpu") : Subtitle("ok")
""")

I wouldn't change the behavior for setting DolbyVisionRPU frame prop to what ffms2 does (in case of missing rpu side data to use the buffer from the previous frame).

As to ffms2... I tested the ffms2 - both 5.0 and 5.0-RC4 have wrong _PictType while 5.0-RC3 is ok.
I use ffms2 only for mkv and raw streams (h264, hevc...).
I use ffms2 from codeberg because I tested it before and the changes usually does not introduce regressions.
You can report the picture type regression on the official repo (https://github.com/FFMS/ffms2).

[jessielw]

Can you name such UHD-BD source that cause this issue? The UHD-BD (m2ts) has the streams separated while remuxes (mkv) have the streams merged. I've been told that the incorrectly merged streams can be the cause for this issue (old makemkv). Also remuxing the file with new makemkv should fix the issue.

Sorry, I meant remuxes ripped directly from the BluRay disc. I realize in my initial statement that's not what I said. Do you think it would be possible to "repair" a remux that was generated with the older version of makemkv that would cause this error? I haven't tested it yet, but I wonder if dovi_tool demux/remux would repair such an issue, or even mkvmerge?

To check if a remux has this issue you can use that ffprobe line I shared and check if the rpu side data exist for latest few frames. Or you can use this avs script:

Thanks for the script! I'll likely setup some sort of check to run through it with VapourSynth/python based on the script you provided above!

I wouldn't change the behavior for setting DolbyVisionRPU frame prop to what ffms2 does (in case of missing rpu side data to use the buffer from the previous frame).

I understand, this makes sense!

As to ffms2... I tested the ffms2 - both 5.0 and 5.0-RC4 have wrong _PictType while 5.0-RC3 is ok.
I use ffms2 only for mkv and raw streams (h264, hevc...).
I use ffms2 from codeberg because I tested it before and the changes usually does not introduce regressions.
You can report the picture type regression on the official repo (https://github.com/FFMS/ffms2).

Thanks for the detailed responses/information on this subject. I can report the regression there.

[Asd-g]

Do you think it would be possible to "repair" a remux that was generated with the older version of makemkv that would cause this error? I haven't tested it yet, but I wonder if dovi_tool demux/remux would repair such an issue, or even mkvmerge?

I cut a small sample of the end of the video file. dovi_tool and mkvmerge cannot repair the issue. Using the latest makemkv fixes the issue.

[L4cache]

Do you think it would be possible to "repair" a remux that was generated with the older version of makemkv that would cause this error? I haven't tested it yet, but I wonder if dovi_tool demux/remux would repair such an issue, or even mkvmerge?

I cut a small sample of the end of the video file. dovi_tool and mkvmerge cannot repair the issue. Using the latest makemkv fixes the issue.

Maybe you can send the sample to FFMS/ffms2#445?

[jessielw]

I cut a small sample of the end of the video file. dovi_tool and mkvmerge cannot repair the issue. Using the latest makemkv fixes the issue.

Thanks for looking into it for me! Again, I appreciate you taking the time and explaining things.

Maybe you can send the sample to FFMS/ffms2#445?

I sent the full size file and the sample links to them

@Asd-g you can close this when ever you see fit!