L-SMASH Source

[qyot27]

A few patches that might be useful:

AvxSynth support
https://gist.github.com/qyot27/5794294
(this one is currently broken because it's not creating the function exports correctly under g++ or AvxSynth, or both; it compiles, but that's about it)

Installation rules for the VapourSynth plugin
https://gist.github.com/qyot27/5794299


The third patch is for the case where L-SMASH itself has been patched to install its headers in $(includedir)/lsmash rather than just $(includedir)
https://gist.github.com/qyot27/5794312

Adjusted header search paths
https://gist.github.com/qyot27/5794300
(it does assume that the AvxSynth patch has been applied already)

[qyot27]

I've updated the AvxSynth and VapourSynth install patches slightly (AvxSynth plugin is still broken); the URLs are still the same.

[Selur]

'small' feature request: would be nice if could call LWLibavVideoSource with a list of sources and not just with a single source, since one it a bit of a pain when trying to open a blu-ray that uses a mpls file which links to multiple m2ts files.
LoadPlugin("G:\Hybrid\avisynthPlugins\LSMASHSource.dll")
LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00004.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00109.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00111.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00113.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00115.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00117.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00119.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00121.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00123.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00125.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00127.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00129.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00131.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00133.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00137.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00139.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00141.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00143.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00145.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00147.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00149.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00151.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00153.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00155.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00157.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00159.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00161.m2ts",repeat=true)
return last (using cache=false on this one will crash Avisynth since more than 3.5GB RAM get consumed)

[Music Fan]

I have a strange problem with LWLibavVideoSource (L-SMASH-Works_r629) : when I open a ts file including interlaced h264 (recorded on tv) in 1920.1080 25i, the fields are blended (until there that's normal because I didn't de-interlace video) and the resulting frames are doubled, so the video is seen as 50 fps instead of 25 in Virtual Dub and there is movement only all 2 images.:confused:
The video is considered as interlaced TFF by MediaInfo.
There is only one line in my script ;
LWLibavVideoSource("F:\myvideo.ts")
Sorry if it has been explained earlier, I didn't read all pages.

[Reel.Deel]

@Music Fan

For an explanation read VFR maniac's post in this thread (http://forum.doom9.org/showthread.php?p=1633952#post1633952).

For a solution try remuxing to MKV and set repeat=true.
Like so:
LWLibavVideoSource("Video.mkv", repeat=true)

[Music Fan]

Thanks a lot, repeat=true works with my ts :)
But I'm astonished to note that my ts files are in bff and not tff (I see it clearly by adding separatefields in my script), while I believed tv streams were always in tff.
Is it possible that LWLibavVideoSource does a field inversion ?
Or could it be a difficulty to handle TS container ?
I still had to put these files in MKV container to see if the result is the same.

[LigH]

The field dominance is an attribute of the video stream, not of the container.

If AssumeBFF().Bob() doubtlessly returns smooth motion, whereas AssumeTFF().Bob() returns a forth-and-back jitter, then it is correct, and the material was recorded using a camera with a dominant bottom field.

[VFR maniac]

'small' feature request: would be nice if could call LWLibavVideoSource with a list of sources and not just with a single source, since one it a bit of a pain when trying to open a blu-ray that uses a mpls file which links to multiple m2ts files.
LoadPlugin("G:\Hybrid\avisynthPlugins\LSMASHSource.dll")
LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00004.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00109.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00111.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00113.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00115.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00117.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00119.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00121.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00123.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00125.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00127.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00129.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00131.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00133.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00137.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00139.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00141.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00143.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00145.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00147.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00149.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00151.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00153.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00155.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00157.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00159.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00161.m2ts",repeat=true)
return last (using cache=false on this one will crash Avisynth since more than 3.5GB RAM get consumed)

I don't have enough time.
I say again and again "patches welcome".

Thanks a lot, repeat=true works with my ts :)
But I'm astonished to note that my ts files are in bff and not tff (I see it clearly by adding separatefields in my script), while I believed tv streams were always in tff.
Is it possible that LWLibavVideoSource does a field inversion ?
Or could it be a difficulty to handle TS container ?
I still had to put these files in MKV container to see if the result is the same.

Inversion can be done by 'dominance'.

+ dominance : (default : 0)
Which field, top or bottom, is displayed first.
- 0 : Obey source flags
- 1 : TFF i.e. Top -> Bottom
- 2 : BFF i.e. Bottom -> Top
This option is enabled only if 'repeat' is set to true.

Even if a source file is TFF, If the first frame consists of two PAFF field coded pictures and the first field is missing, it should be treated as BFF.
Libavcodec returns frames by pair of two field coded picture.
You can see the source is TFF but the recorded and decoded stream is BFF.

source: ... T0 B1 T2 B3 T4 B5 T6 B7 T8 B9 ...
recorded: B1 T2 B3 T4 B5 T6 B7 T8 B9 ... (the first field dropped)
decoded: [B1 T2] [B3 T4] [B5 T6] [B7 T8] [B9 X] ...

For PAFF field coded pictures, there is no concept of field order or field dominance.
They only play role being coded as top field or bottom field.

[LigH]

I say again and again "patches welcome".

Believe it or not ... there are people in this world who are not C++ programmers. :o

[VFR maniac]

Believe it or not ... there are people in this world who are not C++ programmers. :o

I'm not a C++ programmer.
Though LSMASHSource is written in C++, most features of C++ is not used :P
And the part of shared codes between AviSynth, VapurSynth and AviUtl is compilable with both C99 and C++.
So, basically it requires knowledge about only C.

[Music Fan]

Inversion can be done by 'dominance'.



Even if a source file is TFF, If the first frame consists of two PAFF field coded pictures and the first field is missing, it should be treated as BFF.
Libavcodec returns frames by pair of two field coded picture.
You can see the source is TFF but the recorded and decoded stream is BFF.

source: ... T0 B1 T2 B3 T4 B5 T6 B7 T8 B9 ...
recorded: B1 T2 B3 T4 B5 T6 B7 T8 B9 ... (the first field dropped)
decoded: [B1 T2] [B3 T4] [B5 T6] [B7 T8] [B9 X] ...

For PAFF field coded pictures, there is no concept of field order or field dominance.
They only play role being coded as top field or bottom field.
Thanks, interesting.
Do you believe that TV channels encode in PAFF ?
I believed it was rare.

[Music Fan]

The field dominance is an attribute of the video stream, not of the container.

If AssumeBFF().Bob() doubtlessly returns smooth motion, whereas AssumeTFF().Bob() returns a forth-and-back jitter, then it is correct, and the material was recorded using a camera with a dominant bottom field.
Not necessarily, tv channels often do field inversion to mix tff and bff sources (as we can do with video editing softwares).
When I used to record in analog, video was always in tff, for years, and on all channels.
I guess they also chose tff in digital.

[LigH]

Do you believe that TV channels encode in PAFF ?
I believed it was rare.

PAFF is probably more suitable for hardware real-time encoders (per-frame "decision" – possibly always "yes, this frame is interlaced" – is faster than per-macroblock decision). Many AVCHD cameras record PAFF.

If there is enough time to encode the material "offline", broadcasters may use more elaborate encoders; results created by x264 have been spotted in TV broadcasts already.
__

Field inversions ... do you mean wrong flagging (motion analysis reveals TFF order but bitstream flags report BFF), or do you mean a correct TFF/BFF conversion by omitting one field?

[Music Fan]

do you mean wrong flagging (motion analysis reveals TFF order but bitstream flags report BFF), or do you mean a correct TFF/BFF conversion by omitting one field?
I mean a correct conversion.
So I meant that TV often do that kind of conversion and we can't know if it was filmed in tff or bff.
And as my analog recordings were in tff and as MediaInfo also detects tff for my digital recordings, I was astonished to note that these digital recordings were in bff for Libavcodec.
But VFR maniac has given a good explanation about this phenomenon.

PAFF is probably more suitable for hardware real-time encoders (per-frame "decision" – possibly always "yes, this frame is interlaced" – is faster than per-macroblock decision). Many AVCHD cameras record PAFF.
Ok, good to know.

results created by x264 have been spotted in TV broadcasts already
Do you mean some typical x264 defects seen on TV, which means they also use x264 (which is free) ?

[LigH]

I mean that there have been broadcasts where the video stream contained metadata revealing x264 as encoder.

Nothing to worry about, x264 has commercial licensing too.

[Music Fan]

Update ;
http://k4095-takuan.blogspot.de/p/blog-page_17.html

[LigH]

There is a report (http://forum.gleitz.info/showthread.php?46487&p=438362#post438362) that Apple ProRes (http://www.clipcanvas.com/a/video-clip-downloads/) 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).

[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.

[Selur]

btw. is there some way to roughly predict the size of the LWLibavVideoSource index.
Since I can't specify where the index should be created, I normally use to let LWLibavVideoSource create the index inside the RAM, problem is on large files the index gets to large for Avisynth to handle, so I would like to predict the size before indexing a file so I can decide whether to use LWLibavVideoSource or not. :)

[VFR maniac]

There is no way to predict the size of the index file.

The index file consists of properties per packet returned by libavformat in the overall stream.
(+plus CODEC specific decoder configurations and libavformat own index entries)
The size doesn't depend on the source file size.

[VFR maniac]

lsmas: exceeded the number of frames.



This message means the subsequent filter requests frame number exceeding the number of output frames from vslsmashsource.
For instance, the number of output frames from vslsmashsource is 239, and the filter requests 240-th frame, then vslsmashsource will return this error message.

I guess mvtools or VapourSynth's AviSynth compatible module causes the problem.

[Myrsloik]

This message means the subsequent filter requests frame number exceeding the number of output frames from vslsmashsource.
For instance, the number of output frames from vslsmashsource is 239, and the filter requests 240-th frame, then vslsmashsource will return this error message.

I guess mvtools or VapourSynth's AviSynth compatible module causes the problem.

Just return the last frame when that happens. Vs allows frames beyond the end to be requested.

[Music Fan]

Hi,
how to configure LWLibavVideoSource to open VFR h264 ?

[VFR maniac]

@ Myrsloik
Should return with error or warning message?

@ Music Fan
I can't get what you mean.

[Music Fan]

@ Music Fan
I can't get what you mean.
I want to open a vfr video with LWLibavVideoSource, is there anything to add at the end of the 1st line of the script ?
For comparison, when it's done with DirectShowSource, one has to add convertfps=true.
Is there anything like this for LWLibavVideoSource ?

[Myrsloik]

@ Myrsloik
Should return with error or warning message?


As I said, filters are allowed to request frames beyond the end. No errors or warnings.

[LigH]

Current versions of L-SMASH Works (http://k4095-takuan.blogspot.de/p/blog-page_17.html) appears to be r662 (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing).

Changelog is probably best read in the Github (https://github.com/VFR-maniac/L-SMASH-Works/commits/master).
__

A user in the german doom9/Gleitz forum is reporting intermittent issues with batch-converted DVB-S2 720p50 movies being encoded twice as long, sometimes repeated, sometimes with green blanks. But before your alarm goes off, we are trying to discover the reason (RAM, resident AV, timing issue of indexing different files with always the same temporary name...). Usually a second run returns a correct conversion.

[wOxxOm]

I added supporting of a hack of high bit-depth input between rev594 and rev603.
For interleaved format (at default), only little endianness output is supported currently i.e. LSB comes at the first byte and MSB comes at the second.
Stacked format is also available but direct rendering is always not available if used.

In order to use LW in avisynth to process 10-bit video files with high-bitdepth plugins (like modded dfttest and mdegrain from the Dither (http://forum.doom9.org/showpost.php?p=1386559&postcount=3) package) the output needs to be converted.

Stacked=true: 950 fps (LWLibavVideoSource only) -> 400 fps drop.
msb = crop(0,0,0,height/2)
lsb = crop(0,height/2,0,0)
stackvertical(mt_lutxy(msb,lsb,"x 8 << y + 2 >>",u=3,v=3),
\ mt_lutxy(msb,lsb,"x 8 << y + 3 &u 6 <<",u=3,v=3))

On default settings it's even slower because of bad avisynth's turn implementation: 110 fps (or 300 fps with FTurn SSE2 (http://forum.doom9.org/showpost.php?p=1638416&postcount=1))
assumebff.turnleft.separatefields.turnright.assumeframebased
stackvertical( mt_lutxy(selectodd, selecteven, "x 8 << y + 2 >>", u=3,v=3),
\ mt_lutxy(selectodd, selecteven, "x 8 << y + 3 &u 6 <<", u=3,v=3))

BTW, the output of FFVideoSource with 10-bit-to-stacked hack can be used directly by the aforementioned plugins...
It'd be nice if the LW output for 10-bit files in avisynth would match that, since it's not as useful otherwise.

[VFR maniac]

I want to open a vfr video with LWLibavVideoSource, is there anything to add at the end of the 1st line of the script ?
For comparison, when it's done with DirectShowSource, one has to add convertfps=true.
Is there anything like this for LWLibavVideoSource ?

LWLibavVideoSource doesn't support VFR->CFR conversion i.e. doesn't pad frames for VFR source.
It just returns frame by frame.
VFR->CFR conversion is "patches welcome".

In order to use LW in avisynth to process 10-bit video files with high-bitdepth plugins (like modded dfttest and mdegrain from the Dither (http://forum.doom9.org/showpost.php?p=1386559&postcount=3) package) the output needs to be converted.

Stacked=true: 950 fps (LWLibavVideoSource only) -> 400 fps drop.
msb = crop(0,0,0,height/2)
lsb = crop(0,height/2,0,0)
stackvertical(mt_lutxy(msb,lsb,"x 8 << y + 2 >>",u=3,v=3),
\ mt_lutxy(msb,lsb,"x 8 << y + 3 &u 6 <<",u=3,v=3))

On default settings it's even slower because of bad avisynth's turn implementation: 110 fps (or 300 fps with FTurn SSE2 (http://forum.doom9.org/showpost.php?p=1638416&postcount=1))
assumebff.turnleft.separatefields.turnright.assumeframebased
stackvertical( mt_lutxy(selectodd, selecteven, "x 8 << y + 2 >>", u=3,v=3),
\ mt_lutxy(selectodd, selecteven, "x 8 << y + 3 &u 6 <<", u=3,v=3))

BTW, the output of FFVideoSource with 10-bit-to-stacked hack can be used directly by the aforementioned plugins...
It'd be nice if the LW output for 10-bit files in avisynth would match that, since it's not as useful otherwise.

Did you try format="YUV4**P16"?
'format' and 'stacked' are not exclusive option each other.
I have not tested speed comparison though.

[wOxxOm]

Did you try format="YUV4**P16"?
'format' and 'stacked' are not exclusive option each other.
I have not tested speed comparison though.
Thank you for the hint, I've totally missed the flexibility of 'format', here's a 1080p-10bit quick test results (the video is different, so fps shouldn't be compared to that in my previous post):
YUV420P10 265 - default mode
YUV420P10stacked 248
YUV420P16 270
YUV420P16stacked 190 - same fps as the old ffms2-mod

Edit: 18 Aug build
YUV420P10 285 - 7% faster
YUV420P10stacked 285 - 15% faster
YUV420P16 285 - 5% faster
YUV420P16stacked 223 - 17% faster than the previous build

[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 (https://www.dropbox.com/s/2o3lmi9io0xu8gx/Test_Corrupt.m2v) sample used to cause the crash.
Don't know if is any help but here's the very same sample uncorrupted (https://www.dropbox.com/s/aeq5piha6rrqzhd/Test_Correct.m2v).

[VFR maniac]

@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 (https://www.dropbox.com/s/2o3lmi9io0xu8gx/Test_Corrupt.m2v) sample used to cause the crash.
Don't know if is any help but here's the very same sample uncorrupted (https://www.dropbox.com/s/aeq5piha6rrqzhd/Test_Correct.m2v).

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]

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 (http://ark.intel.com/products/29765).

[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? :thanks:

[sneaker_ger]

There is a report (http://forum.gleitz.info/showthread.php?46487&p=438362#post438362) that Apple ProRes (http://www.clipcanvas.com/a/video-clip-downloads/) 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).

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]

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]

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]

"This blog is open to invited readers only"

Must of recently happened, I was just there last night. Anyways, here's r688 (https://www.dropbox.com/s/pok2p8kygc06t5d/L-SMASH-Works_r688v2.7z) 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]

trying to access http://k4095-takuan.blogspot.de/p/blog-page_17.html I now get "This blog is open to invited readers only" :(Must of recently happened, I was just there last night. Anyways, here's r688 (https://www.dropbox.com/s/pok2p8kygc06t5d/L-SMASH-Works_r688v2.7z) for anyone looking for it.That is odd...well at least the google drive folder (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) where you can download it is still shared.

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]

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]

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/