L-SMASH Source

[Reel.Deel]

@VFR maniac

I think I might of found a bug in VS LSmashSource r662.

I don't know how I managed to create it, but I cut a small MPEG2 sample and last frames seem to be corrupted.
When I try opening it in VapourSynth using either VirtualDub or AvsPMod it silently crashes when it gets to frame 499 or beyond. Muxing it into MKV also did not fix the problem.
The very same file does not crash in AviSynth.

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'C:\VapourSynth\LSmashSource\vslsmashsource.dll')

# Source
src = core.lsmas.LWLibavSource(source=r'C:\VapourSynth\LSmashSource\Test_Corrupt.m2v')

# Output
src.set_output()

Here's the corrupted sample used to cause the crash.
Don't know if is any help but here's the very same sample uncorrupted.

[VFR maniac]

Originally Posted by Reel.Deel

@VFR maniac

I think I might of found a bug in VS LSmashSource r662.

I don't know how I managed to create it, but I cut a small MPEG2 sample and last frames seem to be corrupted.
When I try opening it in VapourSynth using either VirtualDub or AvsPMod it silently crashes when it gets to frame 499 or beyond. Muxing it into MKV also did not fix the problem.
The very same file does not crash in AviSynth.

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'C:\VapourSynth\LSmashSource\vslsmashsource.dll')

# Source
src = core.lsmas.LWLibavSource(source=r'C:\VapourSynth\LSmashSource\Test_Corrupt.m2v')

# Output
src.set_output()

Here's the corrupted sample used to cause the crash.
Don't know if is any help but here's the very same sample uncorrupted.

I can't reproduce the crash in r682 though I haven't tested in r662.

[zettai]

I'm trying to build the vapoursynth libs on OSX but I'm not really sure what I'm doing.

I've cloned the git repo but I don't know what options to put into configure. Has anyone done this who could give me some pointers?

edit: nevermind. I hadn't built l-smash first. It's fine now

[Reel.Deel]

Originally Posted by VFR maniac

I can't reproduce the crash in r682 though I haven't tested in r662.

Hmm, just tried with r688 and I still have the same problem.
I have double checked to make sure I'm not doing anything wrong.
Maybe this can be something specific to my system? I'm using 32-bit Windows XP SP3 with a Q6600.

[qupfer]

Hi,

I'm sorry if my question sounds stupid but I have some trouble to understand the "repeat-mode". It could be related to my unawareness(? its a google translation) about the dependigs of fields and frames

Can I say summarized:
If my source is interlaced-flaged (like 1080i HDTV recordings) I set repeat=true and if the source in progressiv (non-interlaced DVD,BD) then repeat=false?
And what happend, if I set repeate=true for a progressiv source?

And why is repeat=true what it is? I mean, i would suppose what with set to true, I will have some/all frames twice and not with the false-option.

Can somebody give me a easy-to-understand explanation?

[sneaker_ger]

Originally Posted by LigH

There is a report that Apple ProRes videos (e.g. clipcanvas_14348_PRORES_HQ.mov) are incorrectly decoded and deskewed by LWLibavVideoSource (LSMASHSource r632), in contrast to FFVideoSource (FFMS2 v2.18 RC1).

Originally Posted by VFR maniac

Apple ProRes?
Haha, I guess the strange output from LWLibavVideoSource is high bit-depth interleaved format.
You may feel FFMS2 outputs correctly but, the fact, the output loses accuracy around 2-bit for each Y'CbCr component.
Try format="YUV422P8" or stacked=true.

Edit and Note: currently libavcodec ProRes decoder supports only Y'CbCr 4:2:2 10-bit and 4:4:4 10-bit format with or without alpha channel.
Therefore, LWLibavVideoSource(source="ProRes") always output in interleaved format unless user specifies output format.
And even if ProRes4444 (12-bit) is input, the default output format will be Y'CbCr 4:4:4 10-bit with alpha.

Did you take a look at the samples? For me it does indeed seem broken instead of a user error. Output is greenish, even if I assume interleaved format. When using the stacked=true parameter the upper half is greenish as well.

LSMASHVideoSource("clipcanvas_14348_ProResHQ_720p50.mov", stacked=true)
#DitherPost()

http://abload.de/img/lsmashvideosource_proisqg8.jpg

[VFR maniac]

Originally Posted by sneaker_ger

Did you take a look at the samples? For me it does indeed seem broken instead of a user error. Output is greenish, even if I assume interleaved format. When using the stacked=true parameter the upper half is greenish as well.

LSMASHVideoSource("clipcanvas_14348_ProResHQ_720p50.mov", stacked=true)
#DitherPost()

http://abload.de/img/lsmashvideosource_proisqg8.jpg

It's not broken because significant bits of the MSB are lower 2 bits only i.e. the values of each Y'CbCr component are almost near by zero.
10 bits = MSB 2 bits + LSB 8 bits
Upper 6 bits of the MSB make no sense.
Therefore, the greenish is normal with 10bit Y'CbCr samples.

[sneaker_ger]

Any reason for choosing this format? Dither/f3kdb/x264 seem to do it the other way, so one would would need to skew those bits over into the MSB to make it compatible with those? Or am I missing something again?

[VFR maniac]

Libavcodec decoders output by such format; [LSB 8 | zero 6 | MSB 2] for 10-bit Y'CbCr.
As the default, the postprocessor after decoding works as just copying data delivered from decoder into the AviSynth video buffer.
Basically I believe that data shall not be modified unless user, decoder or demuxer specifies.
10->16 change may add something of dither instead of simple bit-shifting.

Use format="YUV4**P16" if you need the format [LSB 8 | MSB 8].

[sneaker_ger]

Originally Posted by VFR maniac

10->16 change may add something of dither instead of simple bit-shifting.

"May"?

[zero9999]

does LWLibavVideoSource export useful global variables like FFMS2 (SAR, matrix, tv/pc range, cfr & vfr time) ?

[Selur]

trying to access http://k4095-takuan.blogspot.de/p/blog-page_17.html I now get "This blog is open to invited readers only"

[Reel.Deel]

Originally Posted by Selur

"This blog is open to invited readers only"

Must of recently happened, I was just there last night. Anyways, here's r688 for anyone looking for it.

[Selur]

thanks

[Selur]

is it just me, or isn't LWLibavVideoSource any more reuse the .lwi index file? (iirc it did before)

[l33tmeatwad]

Originally Posted by Reel.Deel

Must of recently happened, I was just there last night. Anyways, here's r688 for anyone looking for it.

That is odd...well at least the google drive folder where you can download it is still shared.

Originally Posted by Selur

is it just me, or isn't LWLibavVideoSource any more reuse the .lwi index file? (iirc it did before)

I haven't noticed it not reusing the index files, have you tried the newest version (r688v2)?

[RTW47]

from my experience latest LWLibavVideoSource do not re-write index file, if it was already created.
and it doesn't seem to (re-index) overwrite index file created by aui_indexer either.

[LigH]

Not even if the timestamp of the source file is newer than the timestamp of the index file (so the source has probably changed since indexing it)?

[the_weirdo]

Originally Posted by LigH

Not even if the timestamp of the source file is newer than the timestamp of the index file (so the source has probably changed since indexing it)?

In my tests, even when you've replaced the source file with a different file, it still re-use the index file.

[VFR maniac]

Originally Posted by Selur

trying to access http://k4095-takuan.blogspot.de/p/blog-page_17.html I now get "This blog is open to invited readers only"

He moved his blog.
It was announced at the top page of the old one.

http://otsukemono.blogspot.jp/