L-SMASH Source

[Selur]

thanks, added the info to the first post.

[Brazil2]

thanks, added the info to the first post.
Maybe you should add the URL tags to your URLs to make them clickable ;)

But I thought L-Smash muxer.exe was now able to mux HEVC into MP4 but I can't make it working with rev786 while it works with the same source and MP4box rev4868. Am I missing anything ?
Example of source file: https://x265.cc/builds/Samples/bigbuckbunny.hevc

[VFR maniac]

But I thought L-Smash muxer.exe was now able to mux HEVC into MP4 but I can't make it working with rev786 while it works with the same source and MP4box rev4868. Am I missing anything ?
Example of source file: https://x265.cc/builds/Samples/bigbuckbunny.hevc

http://repo.or.cz/w/L-SMASH.git/commitdiff/153572b12eed094fbf68c6770c753810d49e5a3a

HEVC muxing is testing and experimental purposes only at present since the specification is not finalized and published yet.

I don't want you to mux HEVC for archival and distribution purposes since there is no guarantee that the file is demuxed and decoded correctly in the future.
At least, L-SMASH will reject files based on the draft versions.
Be patient, please.

If compiled with the latest ffmpeg (which can output POCs of HEVC), L-SMASH Works can seek raw Annex B HEVC stream.
So, you can play avs importing the raw stream and audio stream as if AVI.

[Brazil2]

HEVC muxing is testing and experimental purposes only at present since the specification is not finalized and published yet.

I don't want you to mux HEVC for archival and distribution purposes since there is no guarantee that the file is demuxed and decoded correctly in the future.
At least, L-SMASH will reject files based on the draft versions.
OK, thanks for clarification :)

Be patient, please.
No! :D :p ;)

[LigH]

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

Confirming. L-SMASH Source (which I'm using as AviSynth plugin) needs a sanity check of the index file to rebuild it when outdated.

(Confirmed with r688-2; not yet tested with most recent r693)

[Music Fan]

LWLibavVideoSource seems to have a problem with big ts files (I tested 2 files ; 4,70 GB and 6,02 GB) in interlaced h264 : the framerate is doubled, even when repeat=true is added. It happens on rev 693, 688 and 662.
With a short extract of one of these files (5 minutes, 230 MB cut with TSMuxer), there is no problem, even when repeat=true is not added (with rev693).
I don't know which is the size limit to allow a good working, I guess 4 GB.

[StainlessS]

Try cutting out 2 clips, one about 1.75GB and other about 3.75GB.

[Lenmaer]

It's not bound to file size.
I've noticed this error since the beginning with LWLibavVideoSource.
I noticed also that it affects MBAFF m2ts files, whatever their length or size.
And FFMS2 has that bug too.

[Music Fan]

Try cutting out 2 clips, one about 1.75GB and other about 3.75GB.
Ok, but that won't help me for big files. Or I should cut them in several parts, then re-encode and merge them.

[Music Fan]

It's not bound to file size.
I've noticed this error since the beginning with LWLibavVideoSource.
I noticed also that it affects MBAFF m2ts files, whatever their length or size.
And FFMS2 has that bug too.
In this case, why does it work with an extract of the big file ?

[StainlessS]

Ok, but that won't help me for big files. Or I should cut them in several parts, then re-encode and merge them.

Was intended to ascertain whether problem over 2GB (signed int)
or 4GB (unsigned int), but as Lenmaer says unrelated to size, then of no use.

In this case, why does it work with an extract of the big file ?

perhaps because of remux, try remux whole thing.

[Lenmaer]

In this case, why does it work with an extract of the big file ?

That I can't say, perhaps TS muxer does something that corrects it?

[LigH]

Especially transport streams from DVB [-S2] may always contain transmission errors. They should never be used without cleaning.

And even if direct handling of TS sources is more or less supported by FFMS2 (with the required Haali splitter) or L-SMASH Source, handling a source remultiplexed to MKV is certainly more reliable.

[Music Fan]

Especially transport streams from DVB [-S2] may always contain transmission errors. They should never be used without cleaning.
I did it with TSDoctor.

And even if direct handling of TS sources is more or less supported by FFMS2 (with the required Haali splitter) or L-SMASH Source, handling a source remultiplexed to MKV is certainly more reliable.
Ok, I will try it.

[Music Fan]

Tried in MKV, does not work either with 4,70 GB file ; still have to try 2,5 and 3,5 GB sized files.

[Music Fan]

Tried a 2,5 GB ts : strange behavior (with rev693) : Virtual Dub detects now 25 fps -whatever I specify repeat=true or not-, but in both cases all frames are doubled anyway and the file length too, and it is played at half speed.:scared:

edit : same problem with a 1,64 GB TS cut with TSMuxer.

edit : different problem when the 2,5 and 1,64 GB files are put in MKV : file length is good but all frames are also doubled -whatever I specify repeat=true or not- and Virtual Dub detects 50 fps (I demuxed streams with TSMuxer, opened them in MKVMerge and specified 50i as framerate).

Even below 2 GB, there are problems.

[LigH]

If it also fails for a cut of a few seconds, then please provide a sample...

[Music Fan]

As I said 2 days ago, it works with a 5 minutes extract (230 MB), otherwise I wouldn't have made all these tests.

[Music Fan]

r702 is online ;
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing

[Music Fan]

I can't make it work, I get this error message : "unable to load dll, error=0x7e". :scared:

[Music Fan]

Thanks, works with dll in system32 folder ;)

But I still have the problem described above with big interlaced h264 files.:(

[real.finder]

about interlaced h264 and double FPS, you can use Select Even or Select Odd, try to see which one is best suited to your video

and about MS C++, can you back it to old one? I think that the 2012 update 4 is suitable in order to unite with avs+

[the_weirdo]

You can just install VC++ 2013 Redist. It doesn't harm anything.

[turbojet]

I'm getting crc32 errors when using this with 2 pass decimate.

1st pass
LWLibavvideosource("source",cache=false,dr=true)
TFM(clip2=nnedi3(),mode=3).sorathread().TDecimate(mode=4,output="metrics.txt",rate=25)

2nd pass
LWLibavvideosource("source",cache=false,dr=true)
TFM(clip2=nnedi3(),mode=3).sorathread().TDecimate(mode=2,input="metrics.txt",rate=25)

When it starts the second pass it throws:
TDecimate: crc32 in input file does not match that of the current clip (0x95a26115 vs 0xc40c874d)!

When I use DSS/DSS2 for both passes it works fine. I haven't tested other source filters yet but any idea what could be going on?
Changing lw back to defaults had no effect.

When dr=true there's corrupt lines on the bottom, it really sticks out with this clip http://www.sendspace.com/file/qiqta1. It's unfortunate because it's a nice speed increase.

[turbojet]

That sample was for the corrupt bottom lines but I figured out it only effects 1080 sources. It's expanding to 1088 to make it a multiple of 16. Wouldn't it make sense to either automatically crop the added lines that were added when dr=true?

It was a different source (4GB) that was throwing the tdecimate error. I tried cutting it but couldn't reproduce the issue that way. Just finished redoing first pass and about half the time the second pass loads okay, other times it throws an ntdll error. Haven't seen a tdecimate error this time. DSS2 second pass always loads. I can upload the whole source if you want otherwise maybe the index file can help find a problematic part to cut. http://www.sendspace.com/file/1gpmpv

[Lenchik]

sample 10 bit RGB DPX file (https://archive.org/details/Sample10BitRgbDpxFile)
ImageMagick identify verbose output attached
After ImageMagick manipulation convert Sample10BitRgbDpxFile_00255.dpx ( -clone 0 -evaluate and 65280 ) ^ ( -clone 0 -evaluate and 255 -evaluate leftshift 8 ) -delete 0 -append Sample10BitRgbDpxFile_00255.bmp
I get stack16 bmp (https://docs.google.com/file/d/0Bzb8ahHlm9BBS1lDOWdiWFVFQWM).

While
img = img_fldr + "Sample10BitRgbDpxFile_00255.dpx"
LWLibavVideoSource(img, cache=false, stacked = true)
gives me "gbrp10le is not supported".

LWLibavVideoSource(img, cache=false, format="YUV444P16", stacked = true)
gives me some stack16 output which is not identical to ImageMagick's. Too many differences. YUV444P16 output is much brighter (brighter than pc-tv difference) and bottom part of image is completely different in colors of "garbage" (not like 601-709 difference).

How can i get out of LWLibavVideoSource (+ maybe some additional manipulations) the same as from ImageMagick's to-stack16-bmp-conversion?
Or this is some bug in L-Smash Source?
Maybe i am doing something wrong with ImageMagick?

p. s. Avisynth 2.6 latest MT build by Set

[wOxxOm]

Lenchik, XnView and Photoshop don't agree with you and show the picture almost the same as LWLibavVideoSource, so the bmp produced by imagemagick is too dark. However, the white balance of LWLibavVideoSource output differs from both Photoshop and XnView, it's a little too warm.

[Lenchik]

Lenchik, XnView and Photoshop don't agree with you and show the picture almost the same as LWLibavVideoSource, so the bmp produced by imagemagick is too dark.
Maybe this has something to do with log colorspace (that is reported by imagemagick's identify) and some conversions applied (or not applied)? I didn't understand fully info at pages that i have found recently: http://galannicolas.com/mediawiki-1.13.3/index.php?title=Color_Space_101
http://www.qvolabs.com/Digital_Images_ColorSpace_Log_vs_Linear.html

[Dogway]

Maybe this has something to do with log colorspace (that is reported by imagemagick's identify) and some conversions applied (or not applied)? I didn't understand fully info at pages that i have found recently: http://galannicolas.com/mediawiki-1.13.3/index.php?title=Color_Space_101
http://www.qvolabs.com/Digital_Images_ColorSpace_Log_vs_Linear.html

Log files look always that pale, without any type of proofing or real time LUT viewer.
cretindesalpes created (http://forum.doom9.org/showthread.php?p=1532300#post1532300)a function for that.
It will convert log space to gamma encoded space such as ITU601.

[MeteorRain]

I experienced memory overflow on indexing bluray remux'd mkv file using core.lsmas.LWLibavSource().

The file is about 11GB big, 1 hour in length.

The memory usage continuously increases from 100MB to ～2GB and then python (or whatever other process) crashes, leaving the lwi file at ～80% progress or so.

Did anyone experience the same problem before?

I'm on the latest version (r708), Windows Server 2012.

[LigH]

Current binary (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) = r708: git-c7cc104 [2013-12-08]

[Music Fan]

Thanks, I copy here a part of the changelog for those who wonder what changed.

r708: git-c7cc104 [2013-12-08] lwlibav_video: Retry seek when corrected frame_number greater than rap_number.
r707: git-32c1ff2 [2013-12-08] lwlibav_audio: Fix possible infinite loop.
r706: git-0b66edf [2013-12-07] common/audio: Remove unused variable audio_frame_count.
r705: git-dc8bd80 [2013-12-07] libavsmash: Fix free() -> lsmash_free() to prevent crash on different C runtime.
r704: git-8eb5a8f [2013-12-01] lwindex: Generate or interpolate DTS if any invalid DTS for WMV/VC-1.
r703: git-ed370d7 [2013-11-30] Use av_frame_alloc() instead of deprecated avcodec_alloc_frame().
r702: git-f9b2b46 [2013-11-29] lsmashsource: Add x64 configuration to VC10/11/12 solution.
r701: git-a3d6d20 [2013-11-29] lsmashsource: Fix compilation on x64.
r700: git-acc739a [2013-11-23] lwinput: Remove redundant cleanup operations at closing file.
r699: git-2ea3cae [2013-11-10] lwmuxer: Fix the dialog box title.
r698: git-409bb24 [2013-11-10] lwdumper: Fix the dialog box title.
r697: git-b0fea24 [2013-11-10] AviUtl/progress_dlg: Cosmetics.
r696: git-a198bea [2013-11-10] lwinput: Fix the dialog box title.
r695: git-1e84230 [2013-11-03] lsmashsource: Add VC12 support.
r694: git-0eb40a4 [2013-11-02] lwindex: The maximum max_num_reorder_pics is equal to 15 for HEVC ver.1.
r693: git-2c9602f [2013-11-01] libavsmash: Try to get codec_id from summaries when getting track if unknown.
r692: git-a193e98 [2013-11-01] lwindex: Generate PTSs from POCs for HEVC stream if incomplete.
r691: git-0c7b2f4 [2013-11-01] libavsmash: Support High Efficiency Video Coding.
r690: git-490544b [2013-10-31] lwindex: Construct frame from pair of field coded picture automatically if any.
r689: git-26686fe [2013-10-31] Update VapourSynth.h to synchronize with R21.

[LigH]

Available on Google Drive. Changelog:

r713: git-dd17b77 [2014-02-14] video: Fix 10L introduced in 2aa7ba260d .
r712: git-1612126 [2014-02-14] video: Improve average framerate calculation more.
r711: git-4f027a7 [2014-02-14] Use av_frame_free() instead of deprecated avcodec_free_frame().
r710: git-7ed15b3 [2014-02-14] Remove avcodec_get_frame_defaults().
r709: git-2aa7ba2 [2014-02-14] video: Improve average framerate calculation.

[turbojet]

This was working well for months but now all of a sudden I'm getting error=0x7e. Any ideas on how to fix?

Edit: nevermind, moving msvcr120 worked like it did for Music Fan. Wonder why this all of a sudden started happening.

[LigH]

In general, you should prefer installing MSVC 2013 runtimes over copying a DLL into the possibly wrong directory (because there are 32-bit and 64-bit variants of it, and intermixing causes crashes).

[LigH]

In contrast to FFMS2, L-SMASH Source for AviSynth does not decode Apple ProRes correctly ... or at least, "usably":

Coastguard_ProRes.mov (http://hwcdn.net/j9t9v3v5/cds/Coastguard_ProRes.mov) (750 MB, Elemental Technologies 4K test sequences (http://www.elementaltechnologies.com/resources/4k-test-sequences)) — MediaInfo full report (http://paste.frubar.net/15937)

It returns a YV16 video with twice the width (7680x2160 px), which is displayed with vertical color stripes, probably due to an enhanced color depth. I have to use the following addition to have L-SMASH source convert it to YV12:

LSMASHVideoSource("Coastguard_ProRes.mov", format="YUV420P8")

[sneaker_ger]

http://forum.doom9.org/showthread.php?p=1636993#post1636993

[LigH]

Verdamp lang her :D

OK, checking with "stacked=true" ... no; mainly green above, "fantastic colors" below (but at least a hint that it may be high bitdepth). Mapping to 8 bit per component (format="YUV...P8") is required.

[sneaker_ger]

Choose a P16 format if you need high bit depth 8 bits msb + 2 bits lsb + 6 bits zero, the decoder uses 6 bits zero + 2 bits msb + 8 bits lsb by default for P10.

[Music Fan]

Good news, LWLibavVideoSource seems to handle correctly now the framerate of big interlaced h264 TS files (with rev 713), even without adding repeat=true.:)
I recall that until rev693 (and maybe more recent versions, I didn't test those between 693 and 713), the framerate was doubled with some files, even when repeat=true was added.
http://forum.doom9.org/showthread.php?p=1652889#post1652889

But for some reasons, when I open my avs script in Virtual Dub, nothing happens when I click on next frame, I have to move Virtual Dub's GUI with the mouse to see the refresh and thus the next frame.
I don't know if this is linked to LWLibavVideoSource, Virtual Dub or my pc.:confused:
Something else : when I open this script, the picture is green in the left window (input video pane), not in the right window (output video pane), while ffdshow is not used. I also have to move Virtual Dub's GUI to see the real picture instead the green one.
I don't have this problem when I open an avi in Virtual Dub (without avisynth). :confused:

[cretindesalpes]

Hi,

I have reading problems with LWLibavVideoSource, 10-bit input and stack mode.
L-Smash r714
Avisynth 2.6 alpha 5 and Avisynth+ MT r1689
CPU: i7 Haswell

http://s30.postimg.org/dzicgspy5/bad_stack16_lwlibavvideosource.jpg (http://postimg.org/image/dzicgspy5/)

Video sample (12 MB) (http://www.mediafire.com/download/r4hfullc4tsy6da/bad-stack16.mkv)LWLibavVideoSource ("bad-stack16.mkv", format="YUV420P16", stacked=true)
Note: it works correctly with the default parameters (interleaved bytes)

[wOxxOm]

cretindesalpes, apparently I can't reproduce with just the code above here on avs+ r1576 x86, avs2.6a5 x86, avs+ MT r1689 x86: pic (http://i.imgur.com/CiD9SQg.png)

Edit: oic, my ivy bridge i7 has AVX, not AVX2.

[VFR maniac]

Hi,

I have reading problems with LWLibavVideoSource, 10-bit input and stack mode.
L-Smash r714
Avisynth 2.6 alpha 5 and Avisynth+ MT r1689
CPU: i7 Haswell

http://s30.postimg.org/dzicgspy5/bad_stack16_lwlibavvideosource.jpg (http://postimg.org/image/dzicgspy5/)

Video sample (12 MB) (http://www.mediafire.com/download/r4hfullc4tsy6da/bad-stack16.mkv)LWLibavVideoSource ("bad-stack16.mkv", format="YUV420P16", stacked=true)
Note: it works correctly with the default parameters (interleaved bytes)

Maybe the bug was fixed at rev715.
https://github.com/VFR-maniac/L-SMASH-Works/commit/4ada105018cb848b475d1ff8092ee4455e40c1cf

[burfadel]

Hmmm, couldn't download r715 via the icon:
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU

I had to manually get it.

[Music Fan]

Hmmm, couldn't download r715 via the icon:
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU

I had to manually get it.
How did you do ? I can't get it.

[burfadel]

How did you do ? I can't get it.

This is where the icon is meant to take you:
https://docs.google.com/file/d/0BwV03nn6LPd9Y21BSHJUblVQRHc/edit?usp\u003ddrive_web

[Music Fan]

Thanks !

[wOxxOm]

VFR maniac, r715 produces blocks and ugly artifacts on i7 ivy bridge in p16 stacked mode, r714 is ok.

[VFR maniac]

What!?
The fix should not affect Ivy Bridge since it has no AVX2 support.
I'm using i5 3570 Ivy Bridge but can't replicate the issue.

[wOxxOm]

What!?
Exactly my words after seeing this (http://screenshotcomparison.com/comparison/69311) using whatever format/stacked combination, some of them are more broken though.

Maybe the code (https://github.com/VFR-maniac/L-SMASH-Works/blob/4ada105018cb848b475d1ff8092ee4455e40c1cf/AviSynth/video_output.cpp#L206) should have an explicit if (avx2_available) branch?

Edit: the updated r715 works. Thanks.