[Bug]: Combination of HEVC encoder, --lookahead X (when X≥10) and automatic LTR placement causes issues with specific source file

[DimkaTsv]

Describe the bug
Not sure if there is one or several issues hidden within. Not even sure if it is issue with source or global problem. But i found specific file, which during transcode produces garbled result. It can be watched, but fragment containing 00:10-00:20 interval is missing. Issue is easily visible on PSNR/SSIM graphs.

There definitely is something weird with source, but i cannot easily distinguish what specifically is wrong. Weirdness is such - seeking via MPC-HC, VLC or PotPlayer with HW Acceleration enabled, causes video to stutter or jitter between "future" and "past" frames for about second after skip.
Windows native players do not have such issue, though (aka it seeks perfectly well), but if you do it too much, at some point it will end up "breaking" with 0xC00D36BB error. Playback HW also plays this video and seeks through more or less fine, so this one is perhaps on side of PotPlayer and LAV Filters?.

I have suspicions it is due to same exact non-IDR I-frames which caused corruption on skip causing me to raise these issues. Which i described in these issues:
#447
Nevcairiel/LAVFilters#580
Except unlike previous sample which only contained non-IDR I-frames marked as keyframes, this video still has proper IDR I-frames placed periodically, so it doesn't corrupt.

Source (fragment to reproduce. Cropped with ffmpeg from very beginning of the file):
https://drive.google.com/file/d/1DquRhTVLkG30A5-7lOq9JdqAP6uleF0R/view?usp=sharing

Transcoded with parameters that do not trigger bug:
https://drive.google.com/file/d/1SwGuj2c1G1X8to66c5Ile16-luj5QciM/view?usp=sharing

Transcoded with parameters that cause bug to happen:
https://drive.google.com/file/d/1yfVErVyEpkyxedp6x5Mt7esHMN50drGp/view?usp=sharing

Transcoded with TranscodeHW - has multiple issues: [Including offset by 5 frames and completely whacky seek table where audio seeks fine, but video skips HUGE chunks...]
https://drive.google.com/file/d/1tFR6o7RMPhCre7HTN4_ik0wFCYs1Wxlw/view?usp=sharing

[Encode of larger fragment with TranscodeHW also results in curious case when after performing a seek framerate can go to 144 fps for some time and then slows down to below intended value. (this particular one seems to be specific to MPC-HC for some reason).
Encoding full source makes it even worse, and you won't be able to seek with arrow keys, as video won't continue playing. And seeking by cursor will make it so 144 fps period will last for a WHILE (i counted about 40-50 seconds of sped up playback after seek)]

...

What i could find out within day of testing.

1. Issue definitely is easily reproduceably with VCEEnc, and it is not tied to VCEEnc version (tried on old 8.17 and latest 8.37 versions to confirm).
2. Issue also is reproduceable on all drivers since 25.3.1 (as it is oldest i can test with 9070XT)
3. Issue is specific to source. Other sources still may produce some issues with frame-to-frame synchronisation (which actually is an issue, as seeking same exact frame on source and output won't actually show you same frame in some positions)
4. Issue is NOT specific to decoder. It manifests either way, no matter if i use hardware decoder, or software one.
5. Issue is specific to HEVC encoder, as i tried AVC and AV1 with same parameters and it does not produce such issue.
6. Issue is specific to --codec hevc --pa lookahead=X,ltr=true, where X must be 10 or higher for issue to be present (lookahead=9 or lower will encode normally)
7. Issue is very similar to how encoding with TranscodeHW produces outputs with corrupted beginnings, except missing fragment with TranscodeHW is at 0:00 to 0:10 (first frame or two are still there), and not at 10-20 seconds interval.
   There are at least 2 problems which prevent me from pinning issue further.
8. I cannot really set up same exact parameters in TranscodeHW... I do not really understand how i can set up automatic LTR during preanalysis properly.
9. For some reason no matter what i try to encode with TranscodeHW, everything loses it's beginning in some way. This way analysing PSNR or SSIM of outputs from TranscodeHW becomes very problematic and using reference for comparison is not really viable unless issue is global throughout whole output.

To Reproduce
Used commands:
VCEEnc:

::Condition testing:
%~dp0\VCEEncC64.exe -i %1 -o "%~n1_VCEEnc_no_bug1%~x1" --avsw --codec hevc --preset slow --vbr 10000 --max-bitrate 30000
%~dp0\VCEEncC64.exe -i %1 -o "%~n1_VCEEnc_no_bug2%~x1" --avsw --codec hevc --preset slow --vbr 10000 --max-bitrate 30000 --pa ltr=true
%~dp0\VCEEncC64.exe -i %1 -o "%~n1_VCEEnc_no_bug3%~x1" --avsw --codec hevc --preset slow --vbr 10000 --max-bitrate 30000 --pa lookahead=41

::Limitation testing:
::Does not trigger bug:
%~dp0\VCEEncC64.exe -i %1 -o "%~n1_VCEEnc_no_bug4%~x1" --avsw --codec hevc --preset slow --vbr 10000 --max-bitrate 30000 --pa lookahead=9,ltr=true
::Triggers bug:
%~dp0\VCEEncC64.exe -i %1 -o "%~n1_VCEEnc_bug_threshold%~x1" --avsw --codec hevc --preset slow --vbr 10000 --max-bitrate 30000 --pa lookahead=10,ltr=true

::Bug reproduction:
%~dp0\VCEEncC64.exe -i %1 -o "%~n1_VCEEnc_bugged%~x1" --avsw --codec hevc --preset slow --vbr 10000 --max-bitrate 30000 --pa lookahead=41,ltr=true

Attempt to reproduce with TranscodeHW, even though not sure if i should call it success or failure...

%~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_nopa%~x1" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 10000000 -HevcPeakBitrate 30000000 -HevcEnablePreAnalysis false
%~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_pa%~x1" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 10000000 -HevcPeakBitrate 30000000  -HevcEnablePreAnalysis -PALookAheadBufferDepth 41

Setup (please complete the following information):

• OS: Windows 11 23H2, 22631.5624
• Driver Version: 25.6.3 (can reproduce all the way back to 25.3.1)
• GPU: 9700XT
• Which component has the issue: Encoder?

Debug Log (please upload or paste):
Couldn't see anything wrong there, sadly. But here is log from creating problematic output.
VCEEncC_log.zip

Expected behavior
I would assume that such situation should not happen?
Would also be nice if TranscodeHW will stop garbling start of outputs from a lot of sources.

Screenshots

...

Additional context
This part is more of a preliminary question of "is it a bug?" type... [Aka should i format it as separate issue?]
Above i spoke about some frame to frame synchronisation issue. It is very peculiar, and i currently am not very keen on conditions. It happens both in TranscodeHW and in VCEEnc, but for each source results will vary.

UPD: For TranscodeHW it happens if source had it's first few seconds corrupted for some reason (depends on source, but common). While for VCEEnc it is global, and seems to be a separate issue...
...
After some additional testing, found out that for TranscodeHW when they get offset by about 4-5 frames for some reason, if i seeking a frame and they do not align, i need to go back frame by frame to find where they do align [aka 5073 frame in source = 5068 frame in output, or 10135==>10131]. I think it has some relation to that many sources are getting their beginnings corrupted. At least i came to this conclusion due to corellation observed.

Meanwhile it seems that issue with by-frame seek desync out of VCEEnc i also noticed while testing is slightly different. It just misses a "seek" mark by single frame, for some reason. Maybe some sort of doubling? Basically, if i seek, let's say 5960 frame on both source and output, then for source i will get actual 5960 frame, but for output i will get 5959 frame marked as if it was 5960. Then doing "next step", i get actual 5960 frame, while counter for "seek" window does not change and still shows 5960.
If i understand correctly it should not do that, so something is going on here? So i will probably report that to VCEEnc developer...

[MikhailAMD]

1. VQ Analyzer cannot read the input file.
2. AMF TranscodeHW is using FFmpeg for demuxing and muxing. AMF tries to preserve input timestamps. FFmpeg muxer reports 4 errors and drops 4 frames complaining that tmiestamps are not monotonic with error like this:
   _2025-07-16 13:16:11.035 7D3C [matroska] Error: D:\develop\transccode_vulkan\drivers\amf\stable\public\src\components\ComponentsFFMPEG\UtilsFFMPEG.cpp(293):Application provided invalid, non monotonically increasing dts to muxer in stream 0: 167>= 0
3. If elementary stream is extracted with annex B, TranscodeHW works OK (ffmpeg.exe -i %1 -c:v copy -bsf h264_mp4toannexb -an %1.h264)
   Conclusion: there is something wrong with container in this file

[DimkaTsv]

Hmm, i see. Even though it is weird...

2. Most of the times TranscodeHW fails happen on fragments that i crop fragments with following ffmpeg command:
   %~dp0\ffmpeg -ss %Time_1% -to %Time_2% -i %1 -map 0 -c:v copy -c:a copy -c:s copy "%~n1_fragmented%~x1"
   Is there better way to properly crop out fragments on demand?

3. That is probably what goes wrong... Thanks for hinting on other options how i can make TranscodeHW better understand outputs cropped by ffmpeg which do bug out... But are there any arguments that can make it work in one step (crop), or do i just need to always extract video stream and remux output after crop/encode?

Hmm... If it is container issue, let me try to do raw .h264 -> .h265 video stream encode...
Yup, you are right, no issues with TranscodeHW output at beginning.
Lesson learned. Always check on elementary streams first...

But there is still a point that i don't know how i can recreate HEVC, Preanalysis, Lookahead>10 and Automatic LTR frames (PA) = true with TranscodeHW arguments. Specifically Preanalysis, Lookahead and Automatic LTR. I try to set up arguments, but i don't really see them working, at least not on level of encoder performance. And with Automatic LTR i don't even know which argument i should use to toggle... Can you hint me on proper arguments for these?

---

[Also for some reason FFMetrics cannot properly compare elementary streams? Should keep in mind.
I need to use .mkv as origin file, and not just an .h264 stream from it, otherwise PSNR/SSIM graphs basically go nuts.]

But VCEEnc still loses 13 second fragment. ... Aaand i found why. Will report to him

...
Even when i encode elementary stream. That is something i did not anticipate.
...
Hmm, let me try to use your extract command instead [i used extractor of streams from MKV before that].
Nope, same result... TranscodeHW works fine, VCEEnc loses 13 seconds or so.

...
And this problem is throughout whole source, even before cropping.
And now it doesn't even matter what settings i use. It always does that, no matter which arguments i pass...
...
Aaand i found why.

Video: MPEG4 Video (H264) 1920x1080 25fps [V: h264 high L4.1, yuv420p, 1920x1080]
Frame rate : 23.976 (24000/1001) FPS
So VCEEnc encoded it at 25 fps for some reason. So yeah, i definitely will report that one.

Weirdly elementary streams seem to always show 25 fps in details, and MPC-HC plays them at this frame rate (but actual fps like 23.976 fps is still reported in MediaInfo).

...
P.S. Oh my, i now also need to adjust my working scripts to properly process elementary streams by adding some extension processing... Well, it shouldn't take much.

[DimkaTsv]

UPD: I tried with elementary stream encode as well (granted on VCEEnc again)
It still loses fragment close to beginning after i go above lookahead=9 (in other words set it to be >=10).
So this one is definitely not something that container was affecting.

And, again, based on testing issue only affects HEVC with specific set of arguments [HEVC, Preanalysis, automatic LTR = true // lookahead>=10].
[Elementary streams with different codecs cannot be properly 1:1 analysed with FFMetrics, so i muxed every output into .mkv after encode].
Encoder also reports encoding same amount of frames for every option, be it bugged or non-bugged.
So perhaps something is happening with playback of encoded stream?

[MikhailAMD]

TranscodeHW gets all encoder parameters in form of string identical to property ID strings in AMF header files. For example:
for HEVC: VideoEncoderHEVC.h -HevcEnablePreAnalysis true -HevcLTRMode 1
For PA: PreAnalysis.h -PALookAheadBufferDepth 10 -PALongTermReferenceEnable true
etc

[DimkaTsv]

Thanks for information.
Hmm... If they all work properly, then i somehow couldn't actually reproduce in TranscodeHW same issue that i observe with VCEEnc
Currently i tried using these commands:

::Should be unaffected
%~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_nopa.hevc" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 10000000 -HevcPeakBitrate 30000000
::Below threshold
%~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_pa9.hevc" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 10000000 -HevcPeakBitrate 30000000 -HevcLTRMode 1 -HevcEnablePreAnalysis true -PALookAheadBufferDepth 9 -PALongTermReferenceEnable true
::Threshold
%~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_pa10.hevc" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 10000000 -HevcPeakBitrate 30000000 -HevcLTRMode 1 -HevcEnablePreAnalysis true -PALookAheadBufferDepth 10 -PALongTermReferenceEnable true
::Should be bugged
%~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_pa41.hevc" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 10000000 -HevcPeakBitrate 30000000 -HevcLTRMode 1 -HevcEnablePreAnalysis true -PALookAheadBufferDepth 41 -PALongTermReferenceEnable true

So unless i was doing something wrong that impiles that issue is not on side of AMF.
Then what could go wrong with VCEEnc... It basically only calls out AMF options.
And why this particular setup of arguments? Why it only happens with HEVC and lookahead>9? Feels way too specific, especially as AVC and AV1 do not expose this problem...

...
...

Aaand i now rememebered that i could also try to use ffmpeg for reference.
Hmm, it seems like behaviour here is also weird. It does encode through threshold properly.
It encodes up to lookahead=15, then stops encoding starting with lookahead=16. Encoder speed is also atrocious comparatively (about 32-33 fps) when -preanalysis true is set up.
Which is kinda completely separate issue at this point...
...
...
I also remembered that i could use ffmpeg to check videos for corruption. And there is something.
error.log

In log from bugged output there are these errors for 238 frames in total.
That explains how 10 seconds are missing from output. Frames are there, but reference somehow is missing.

[hevc @ 000002b47f10f980] Zero refs for a frame with P or B slices.
[hevc @ 000002b47f5a0c40] Could not find ref with POC 1
[hevc @ 000002b47f5a0c40] Error constructing the frame RPS.
[hevc @ 000002b47f5a1800] Could not find ref with POC 2
[hevc @ 000002b47f5a1800] Error constructing the frame RPS.
[hevc @ 000002b47f69cf40] Could not find ref with POC 3
[hevc @ 000002b47f69cf40] Error constructing the frame RPS.

But what could cause this to happen? It does not happen on settings which encode properly.
It seems like issue appears exactly on second 240 frame GOP interval. So, in theory only single frame can be "damaged" to cause such result.

I gathered logs from such encode, could they clear out things, maybe?
bugged_logs(debug_trace).zip

---

UPD: I managed to shift place where frames are lost by adjusting GOP length (to 60 in this case).
And again, exactly one GOP is missing... But i don't understand why. This time it happened at 420 frame (which does not align to original 24 frame GOP, as 420/24=17.5)

So is it somehow is related to GOP and LTR?

UPD2:
24 frame GOP -- missing 1 second [Frames 720-743]
48 frame GOP -- missing 2 seconds [Frames 720-767]
120 frame GOP -- missing 5 seconds [Frames 240-359]
240 frame GOP -- missing 10 seconds [Frames 240-479]

Well, on technicality it seems like only 1 frame has issues, but whole GOP interval cannot decode because of it.

Granted, TranscodeHW and VCEEnc do write elementary stream slightly different from each other.
But main difference is only that TranscodeHW writes "Access Delimiter Units" before each frame, and that VCEEnc writes full set of VPS, SPS and PPS before each frame...
...
Can such level of difference during writing even affect decode of specific frame and breaking references?

[DimkaTsv]

Hmm... I found some way to investigate even deeper.
And it seems like i now have better clue on why said GOP is missing.

On corrupted GOP, while IDR frame encodes properly, on following P-frame num_long_term_pics value is somehow set to 0, while it should be at least 1 if i understand properly?. Maybe something else going on with flags/markers (i am directed to NumPicTotalCurr, but not really know where to look for it).
My assumption is that in this case decoder assumes there are no frames to reference, and decodes P frame as if it would've been an IDR? And as every other frame in GOP references previous one, this corruption chains until next GOP.
That also may explain why issue is specific to automatic LTR placement? Not sure...

[Edit: TranscodeHW behaviour for manual LTR limit is same]

---

@MikhailAMD Are these frame specific parameters written by AMF encoder or by applications that use AMF SDK?

Hmm... I tried to go through set of options in TranscodeHW, i don't think i saw any LTR frame actually being set. Even when i tried -HevcMaxOfLTRFrames 13 (which is limit that does not corrupt output), every frame was marked as short-term reference.
Automatic LTR management does work properly, though. Thus i can assume that something else needs to be set so encoder would start marking frames as LTR under normal circumstances? Or is this only possible by manually inserting LTR frames via -MarkCurrentWithLTRIndex argument (even though not sure how it supposed to look)?

Speaking of which, for TrancodeHW -Av1MaxOfLTRFrames does not work.
It throws this error instead: Parameter AV1MAXOFLTRFRAMES is unknown

UPD: Hmm, i found similar behaviour to what i encounter in this if i try to use -HevcMaxOfLTRFrames 14 (which is "out of bounds", i know), TranscodeHW throws an error, but still writes output, and in this output every GOP is corrupt in similar way... But on second glance while in original issue first frame after IDR becomes actual LTR, so remaining frames in gop refer to that one, in case of corruption due to max LTR=14 not a single frame becomes a reference.

[MikhailAMD]

num_long_term_pics = 0 just means there is no long-term reference frames. It could be short term references. If you have an elementary stream or a file that looks corrupted, I can take a look. But still, better reproduce with TranscodeHW.

[DimkaTsv]

Sure, i believe i sent links to files in original report, but just in case i will reencode them with even more control and upload result.

Source:
https://drive.google.com/file/d/1DquRhTVLkG30A5-7lOq9JdqAP6uleF0R/view?usp=drive_link

VCEEnc - Corrupted sample (Corrupted frames are 239/240, in other words start of second GOP):
https://drive.google.com/file/d/1JbfcM3CBgJR0NRrgkZhjx3shwiGhS-Gn/view?usp=drive_link
Used command line - %~dp0\VCEEncC64.exe -i %1 -o "%~n1_[HEVC_LTR_PA41]%~x1" --codec hevc --vbr 5000 --max-bitrate 15000 --preset balanced --gop-len 240 --ref 1 --pa lookahead=41,ltr=true

TranscodeHW - reference (this one has no issues):
https://drive.google.com/file/d/1hMF-Nk_4uf_5dylcdz488k9mKawccrx3/view?usp=drive_link
Used command line: %~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_[HEVC_LTR_PA41].mkv" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 5000000 -HevcPeakBitrate 15000000 -HevcEnablePreAnalysis true -PALookAheadBufferDepth 41 -PALongTermReferenceEnable true

HEVC is only codec where currently there is some difference in outputs between VCEEnc and HEVC, with very high chance it is because SPS,PPS,VPS are written for each frame by VCEEnc (i already wrote report on this one and waiting for response/result).

For AVC and AV1 i found argument setup that produces pixel by pixel identical video streams (which basically came down to amount of reference frames and GOP size as only differences). So... Maybe that slight bitrate difference due to excessive headers matters for VCEEnc output?

---

Ah, yeah, there is also sort of similar thing happening when you set up HEVC with LTR=14 encode. Except for every single P-frame and not only first one after IDR.
Yes, TranscodeHW throws error, but file still encodes, except only I-frames are encoded properly. After some digging for information, i found out that it probably goes above DPB limit or slot limit or something like that? Even though i pretty much don't see even single frame marked as LT (even IDR frames) unless i use preanalysis with automatic LTR mode. I may be misinterpreting results, though.
Not sure if this has any relation to issue on hand, but i mention it as this has somewhat similar looking corruption.

TranscodeHW - corrupted sample (Basically every P-frame is corrupted. LTR=14 without preanalysis):
https://drive.google.com/file/d/1BEcUwapQk007PyBFqNtZE9etVrEgJaIX/view?usp=sharing
Used command line: %~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_[HEVC_LTR14].mkv" -codec HEVC -HevcRateControlMethod vbr -HevcTargetBitrate 5000000 -HevcPeakBitrate 15000000 -HevcMaxOfLTRFrames 14

...
P.S. I also just found out that for some reason tool i have does not really like mkvtoolnix muxed videos (it is unable to see video stream, just header). Can mitigate it by doing .mkv to .mkv remux (or repair) via ffmpeg or mkclean... But that is still extra step. Granted it is still much better than not having such tools at all, and this is best i can get. Perhaps this happens because of that second global EBLM Void element after Tracks section.

Sorry for bit of rant here, i know that one is completely outside of scope (i was just ranting), but because of that fact also did pass of ffmpeg "muxing" for samples [%~dp0\ffmpeg -i %1 -c copy "%~n1_muxed.mkv"], so they would have same structure.

[MikhailAMD]

Three points:

1. I already mentioned that input file has PTS issues and cannot be open in VQ analyzer.
2. I checked VCEEnc code: it sets some parameters regardless of command line, meaning it provides own default for these parameters. It may explain differences between VCEENc and TranscodeHW. See vce_code.cpp line 2688 etc.
3. TranscodeHW with "-HevcMaxOfLTRFrames 14" produces P-frames without references: I can repro and will open an internal ticket.

[DimkaTsv]

I already mentioned that input file has PTS issues and cannot be open in VQ analyzer.

You mean source? Ah, right. It also was muxed via mkvtoolnix, one second.
I don't really know why VQ Analyzer cannot read .mkv files muxed via mkvtoolnix, but just remuxing them via ffmpeg (aka copy all into .mkv file) helps.
Here is remuxed mkv->mkv source (via ffmpeg): https://drive.google.com/file/d/1hilsDSvtwkFnvycKyVSB2Ynf4PYxt1ti/view?usp=sharing
Actually i can now see that it is far from being perfect. There are a lot of HRD compliance warnings.

2. Hmm, you have a point about preanalysis settings. While i was able to figure out normal settings for at least AVC and AV1 (that is how i caught issue with ffmpeg-master improperly measuring PSNR/SSIM/VMAF scores for videos with implicit colorspace), i hadn't yet locked up preanalysis configuration. Will try to do it now. It will take a bit of time, though.

3. Is was an actual issue? I thought it wasn't supposed to encode as it threw an error during process. Or... Wait, is HEVC limit supposed to be same as AVC one, then? 15 frames due to DPB buffer size?

[MikhailAMD]

2. It is just a guess but I cannot compare these two tools with such diferences.
3. If sample app + encoder produce corrupted stream, it is an issue regardless why. I will let codec team figure out why this happens and how it should work.

[DimkaTsv]

2. Reasonable. Thanks for spending your time on looking through code and hinting at differences in PA defaults (even though by documentation i currently cannot see what specifically is different).
   I tried to duplicate parameters that i can see in preanalysis documentation, but to no success. Not sure why. Can there be some hidden parameter set?
   [UPD: i kinda figured out differences by checking defaults in [vce_param.cpp :: line 142], but outputs still are not same for some reason... There should be something else but i don't know what, neither i know i can even change whatever that is]

3. If so, there is also potential error with HRD smoothing buffer overflow on AV1. Reproducible in TranscodeHW. But i don't think it has any impact on actual playback or decoding, so i cannot call it a "corrupted stream". I believe this one is not even source specific, as well as it can happen on basically any argument list, even with most basic ones, like this for example:
   %~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_av1_nopa.obu" -codec AV1 -Av1RateControlMethod vbr -Av1TargetBitrate 10000000 -Av1PeakBitrate 30000000
   TranscodeHW output (muxed to .mkv by ffmpeg): https://drive.google.com/file/d/1OzScXwvLf485sZlayOpZ8feJphIp5weL/view?usp=sharing