可変解像度読み込みにSIMDコードを対応させるパッチです。

パッチをこちらに。
https://skydrive.live.com/redir?resid=6BDD4375AC8933C6!496

Hi, I just updated L-smash works from rev804(03117ec) to rev877(9828349). And it seemed that the new version has broke something. It worked fine with rev804 but in rev807 an error window will pop up when adding m4a file.

When I add an m4a file in AviUtl 拡張編集, an error window will pop up.
右クリック -> 新規プロジェクトの作成
右クリック -> メディア オブジェクトの追加 -> 音声ファイル -> choose one m4a file

Test build: L-SMASH-Works-r785-20150512
Tested on VapourSynth R27 64bit.
I got corrupted result in one RGB24 bmp image (631x655), and got crash in another RGB24 bmp image (1080x720).

Also test LWLibavVideoSource on AviSynth+ r1825 32bit, the result is correct.

Out of hundreds of times I've used LWLibavVideoSource there were a few occasions when it reindexed the source file which wasn't changed in any way possible - the same date(s), size and contents. I just ran a test encode of a small frame range a few times and - bang! LWLibavVideoSource decides to reindex a 25GB file...

Please add global variables for accessing clip properties:

• currently not supported at runtime, e.g. input file name
• currently not supported by Avisynth at all, e.g. SAR, matrix, TV/PCc range, CFR & VFR time

See http://forum.doom9.org/showthread.php?p=1682097#post1682097.

Thanks,
Francois

vapoursynth/vapoursynth#226

It looks like you return from vs_lwlibavsource_create without calling createFilter and without calling setError. Please always call setError when there is an error. I was going to list all the places where you're not calling it, but there are over 9000 layers and places where you may or may not have called it, and I can't tell anymore.

Bonus: these are not necessary:

• L-SMASH-Works/VapourSynth/lwlibav_source.c

  Line 270 in 9828349

  if( !file_path )

• L-SMASH-Works/VapourSynth/libavsmash_source.c

  Line 319 in 9828349

  if( !file_name )

propGetData will not fail because the "source" parameter is not optional. Its presence is checked before vs_lwlibavsource_create or vs_libavsmashsource_create are called.

Hi, I have hit a problem opening a Quicktime Prores in Avisynth, which has 1 audio track with 10 channels of audio in it. It works with 1 track with 2 audio channels, but with this file that has 10 channels I am getting this error:

LSMASHAudioSource: failed to open resampler.
(C:\Users\me\Desktop\test.avs, line1)

Here is the avs script:

LSMASHAudioSource(source="10_ch_test.mov", track=2)

I am using 'LSMASHSource-AviSynth-plugin-r877-msvc-32bit.7z'.
It doesn't matter if there is 1 track of 10 audio channels, or 10 tracks with 1 channel in each, it still seems sot fail with the same error.
Is there anything I can do to get round this, is it a channel limitation?

Here is a small sample which shows the error:

10_ch_test_1_frame.mov.zip

Mac OS X 10.10.5
ffmpeg git HEAD, vapoursynth git HEAD,
configure output

during make:

../common/libavsmash.c:175:71: error: use of undeclared identifier 'QT_CODEC_TYPE_AP4X_VIDEO'; did you mean 'QT_CODEC_TYPE_AP4H_VIDEO'?
        ELSE_IF_GET_CODEC_ID_FROM_CODEC_TYPE( AV_CODEC_ID_PRORES,     QT_CODEC_TYPE_AP4X_VIDEO );
                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~
                                                                      QT_CODEC_TYPE_AP4H_VIDEO

[...]

../common/libavsmash.c:205:71: error: use of undeclared identifier 'QT_CODEC_TYPE_UQY2_VIDEO'; did you mean 'QT_CODEC_TYPE_ULY2_VIDEO'?
        ELSE_IF_GET_CODEC_ID_FROM_CODEC_TYPE( AV_CODEC_ID_UTVIDEO,    QT_CODEC_TYPE_UQY2_VIDEO );
                                                                      ^~~~~~~~~~~~~~~~~~~~~~~~
                                                                      QT_CODEC_TYPE_ULY2_VIDEO

[...]

../common/libavsmash.c:437:61: error: use of undeclared identifier 'QT_CODEC_TYPE_UQY2_VIDEO'; did you mean 'QT_CODEC_TYPE_ULY2_VIDEO'?
          || lsmash_check_codec_type_identical( codec_type, QT_CODEC_TYPE_UQY2_VIDEO ) )
                                                            ^~~~~~~~~~~~~~~~~~~~~~~~
                                                            QT_CODEC_TYPE_ULY2_VIDEO

Commenting-out the mentioned lines makes it compile again, btw.

LWLibavVideoSource("02.cut.m2ts").Trim(158,159)

fails on the following file:
https://dl.dropboxusercontent.com/u/76042064/02.cut.m2ts

Although frame 158 cannot be decoded when directly seeked, it can be correctly decoded if sequentially accessed.
I'm not sure if this is is the issue on libavformat/libavcodec side or not.
Maybe incorrect decision on the random access points? Simple prerolling might solve this issue.

Otherwise the compiled product cannot be recognized by VS r27 on Mac. Actually on non-Windows platforms the vapoursynth.h should always refer to /path/to/vapoursynth/include

The .lwi index file for a 90 minute movie encoded with 10-bit x264 is 190MB written in hundreds of file system fragments (at least on all windows systems) which makes its initial loading off an HDD quite slow and things get worse in case some applications access this disk in background, just imagine hundreds of mechanical disk seeking operations interleaved with other activity...

On the other hand the HDD access penalty becomes a non-issue with a zip-compressed index file - for the aforementioned 90-minute movie it's only 13MB (7% of original 190MB) at default compression level. I think zlib/gzip/xz/lzma would be even smaller.

So it'd be really helpful if L-SMASH-Works will have a parameter to read/write compressed index files.

Hi, for build in linux need add -fPIC in CFLAGS/LDFLAGS like a VS-TNLMeans filter

greetings

L-SMASH Works(のコード)はバグっていませんが、L-SMASH Worksバグってる報告です。

【概要】
MPEG-2 Transport Streamの先頭に破損GOP扱いとなるMPEG-2 Videoが存在、これを扱う際、
インデックスファイル(.lwi)を正しい情報で生成できていない。

バグ動作： リピート制御有効時に「フレーム数」「平均フレームレート値」が正しくない状態となる

※ 録画したTSデータをそのまま編集しようとする人がこれに遭遇（高確率）
※ 「L-SMASH... はフレームレートが～」と言われた場合はこの現象に該当した物と思われる

[以下、前提]
破損GOP＝MPEG-1/2 VideoのGOP先頭にあるシーケンスヘッダが不足しているPicture部位
（GOP単位で扱うソフトであれば捨てる部分）

【原因】
破損GOP部位に libavformat/libavcodec のパース処理を通しても、（シーケンスヘッダがない為）
AVCodecParserContext上の情報はインデックス生成処理に必要な情報が未解析な状態となる。

具体的には pkt_ctx->ticks_per_frame が初期値(1)のまま。
この値はシーケンスヘッダを解析しMPEG-2 Videoと判定されると(2)に設定される。
(libavcodec/mpegvideo_parser.c 参照)

この為、以下の判定が誤動作し破損GOP部位の repeat_pict の値が正しくない値(+)で出力されている。

lwindex.c(2064-2067)

               if( pkt_ctx->ticks_per_frame == 2 && helper->parser_ctx->repeat_pict != 0 )
                   repeat_pict = helper->parser_ctx->repeat_pict;
               else
                   repeat_pict = 2 * helper->parser_ctx->repeat_pict + 1;

結果、リピート制御有効時にフレーム数が水増しされる事になる。
・リピート制御不要なデータ(60iインターレースフレームonly)はリピート制御をオフに設定すれば回避可能
・RFFを含むデータは回避不可能

現状、GOP単位でカット編集するソフト等で前処理を行い、破損GOPを捨てた状態にしないとバグ回避は難しい。
（※RFFを含むデータをカット編集する時には気を付けた方が良い事がいろいろ存在するが、これは別途どこかで明記しておきたい）

【対策案】
maki-rxrz / fix ブランチを参照。
maki-rxrz@d455411

Workaroundになるが、get_index_helper() 内でMPEG-2 Videoでの初期値設定を追加。
（本対応時には INDEX_FILE_VERSION の更新も忘れずに。）

There seems to be a memory problem with all builds which I have tried (702 to 715 v2). I am using it mainly from within AviSynth+ (r1576) - but have tried also other AviSynth versions. The script will be called from within MeGUI several times (auto crop, deinterlace detection, encoding, ...) and after a while a script cannot be opened anymore with the error "[Fatal]: Failed to avformat_open_input." It can then be noticed that the memory consumption of the MeGUI process is high (up to 2GB) and it will not be freed when the script is closed. I have to close MeGUI and then the last operation can be continued. Also other users have the same problem: http://forum.doom9.org/showthread.php?p=1676500#post1676500
I can reproduce it also when I open/close the avs script with VirtualDub.

With other source filters I do not have the problem (ffms, dgindex, dgindexnv, ...) - only exception is the c-plugin of ffms which also seems to have a memory leak.

I opened and closed a simple script
LWLibavVideoSource("C:\test.mkv.lwi")
pointing to test.mkv - lwi size is ~50 MB. During every open/close cycle the memory increase and will not be freed completly.
I made those tests with r715 v2

Thanks for a great plugin!

こんにちは。えと、体調がよろしい時にでもよろしくお願いします。

パッチはこちらに。
http://skydrive.live.com/?cid=6BDD4375AC8933C6&id=6BDD4375AC8933C6!258

0001: lsmashinput: add faster interlaced yv12 to yuy2 using SSSE3.

インタレYV12->YUY2のSSSE3を使用した高速化と、細かい調整です。

SIMDコードをファイルの後ろに移したのは、

SSE2ヘッダ <emmintrin.h>
SSE2コード
SSSE3ヘッダ <tmmintrin.h>
SSSE3コード

の順番になるようにして、誤ってSSE2コードにSSSE3命令が混ざるのを防ぐためです。(コンパイラーにチェックさせる)

また、GNUmakefileの-msse2を除去しました。

これによりmake時に

error SSE2 instruction set not enabled

error SSSE3 instruction set not enabled

のメッセージが出るようになってしまいます。

しかし、
・SSSE3を使用したことで、コンパイル時のエラーメッセージを黙らせるには-mssse3が必要。
・-mssse3をつけるとgccの最適化により意図しないところでSSSE3命令が使用される恐れがある。(可能性は低いですが)
・万が一意図せぬところで使われると、SSSE3を搭載しないAMD Phenom等で困ったことになってしまう。
上記の理由から、-mssse3を付けないほうがよいと思われるため、このメッセージは無視するしかないのかなと思います。

0002: lsmashinput: show progress bar during index file creation.

インデックスファイル生成中に簡易プログレスバーを表示します。

進捗計算はどうすればいいのか、いまいちよくわからないなりにやってみました。まあだいたいわかればいいのですが。

Analog to ffmpegSource2s ffmsindex, it would be nice if LSMASHSource.dll would also have a separate indexing application which would allow to index a source before using the dll through Avisynth and reuse the source.
(+ it would also allow to create the index file in another location than next to the input file)

_FieldBased should be 1 for BFF and 2 for TFF.

Once an index fle is built, it is assumed to be valid as long as any source file with the original name exists, no matter if the source file has a different content in the meantime, e.g. a video with the same filename but different encoding options was created after the index file was generated.

Comparing if the source file has a newer timestamp than the index file should be a minimal sanity check to rebuild the index file if necessary. Possibly even a checksum of a header portion may be useful in addition.

Reading an RGB24 clip (created with AviSynth+ffmpeg, tested ffvhuff and ffv1 codecs) results in error "LWLibavVideoSource: bgr0 is not supported." Manually setting LWLibavVideoSource to use format="rgb24" works. So my assumption is that it isn't recognizing that bgr0 = RGB24. RGB32/RGBA works as expected.

Cross posted from http://forum.doom9.org/showthread.php?p=1762134#post1762134

When trying to decode sample.m2ts with latest LWLibavSource, it immediately crashes python.
mpv plays the file fine and without decoder errors. FFMS2 also decodes it but discards the first frame (seems to be another bug).

OS X crash report
lwi file

Script:

import sys
from subprocess import Popen, PIPE

import vapoursynth as vs
core = vs.get_core()

file = str("sample.m2ts")

video = core.lsmas.LWLibavSource(source=file)
video = core.std.Trim(clip=video, first=0, last=99)

#video.set_output(0)

cmd = ['x264', '-', '--frames', '100', '--input-csp', 'i420', '--demuxer', 'raw', '--input-depth', '8', '--input-res', '1920x1080', '--fps', '24000/1001', '-o', 'testencode.mp4', '--colorprim', 'bt709', '--colormatrix', 'bt709']

p = Popen(cmd, stdin=PIPE)
video.output(p.stdin)
p.communicate()

Using vspipe also leads to a crash.

Would be nice if LWLibavSource would support .mpls files (Blu-ray Playlist files) an directly load and append the files in the playlist.

While encoding 4 videos from the same source-file, I had LWLibavSource (using VS) report three different frame rates:

Encoding segment 13-00 of 03 to workfiles/video/segments/Ni_13-00_720.mp4
Loading new sourcefile: BDMV/umi07/BDMV/STREAM/00000.m2ts
Source ClipInfo: VideoNode
    Format: YUV420P8
    Width: 1920
    Height: 1080
    Num Frames: 69535
    FPS Num: 2110
    FPS Den: 88
    Flags: Is Cache, No Cache


Encoding segment 13-00 of 03 to workfiles/video/segments/Ni_13-00_1080.mp4
Loading new sourcefile: BDMV/umi07/BDMV/STREAM/00000.m2ts
Source ClipInfo: VideoNode
    Format: YUV420P8
    Width: 1920
    Height: 1080
    Num Frames: 69535
    FPS Num: 24000
    FPS Den: 1001
    Flags: Is Cache, No Cache


Encoding segment 14-00 of 03 to workfiles/video/segments/Ni_14-00_720.mp4
Loading new sourcefile: BDMV/umi07/BDMV/STREAM/00000.m2ts
Source ClipInfo: VideoNode
    Format: YUV420P8
    Width: 1920
    Height: 1080
    Num Frames: 69535
    FPS Num: 1990
    FPS Den: 83
    Flags: Is Cache, No Cache


Encoding segment 14-00 of 03 to workfiles/video/segments/Ni_14-00_1080.mp4
Loading new sourcefile: BDMV/umi07/BDMV/STREAM/00000.m2ts
Source ClipInfo: VideoNode
    Format: YUV420P8
    Width: 1920
    Height: 1080
    Num Frames: 69535
    FPS Num: 1990
    FPS Den: 83
    Flags: Is Cache, No Cache

All clips were encoded in the same script run (python instance), with an LWLibavSource() call in each iteration, in case that might be relevant.
lwi file: http://sva.wakku.to/~chris/temp_stuff/umi07_00000.m2ts.lwi.zip

since a couple of months i'm encountering a bug into lsmash using vapoursynth for m2ts and m2ts muxed in mkv, i tried a lot to reproduce this issues but is impossible, it's random AFAIK.

It happens using lsmash and mdegrain [tried with tr=2] together [only lsmash or using another source filter don't seems to cause the problem] and consist of wrong decoding sequences or duplicated frames [for example ABDCE... or ABBDE...].

I've tried setting threads to 1 thinking it was a race condition but without success.

As i stated, i cannot offer a raw sample because it's random and usually appear on the middle of the encode [even cutting the precise scene in which this happens i was unable to reproduce this].

This is the most i can give you http://www.mediafire.com/watch/2mg9wec9616kvjj/test_lsmash.mkv

Problem description

Copy of: http://forum.doom9.org/showthread.php?p=1738580#post1738580

When decoding FFV1 generated by ffmpeg, LWLibavVideoSource() reports the correct number of frames, but the clip is shifted earlier by one frame. The first frame is lost and an additional frame is added towards the end. What is actually displayed towards the end depends on scrolling: sometimes a green frame is added at the end, sometimes the actual last frame appears twice in succession, sometimes the actual penultimate frame appears twice in succession. Scrolling backwards and forwards may cause any of the last three frames to display differently from before.

Other applications like MPC-HC and ffplay open the FFV1 clips correctly.

Results are the same for clips encoded with the latest ffmpeg version (with FFV1 version 3.4), and with an older 2013 version (with an FFV1 version reported by ffprobe as 0). L-SMASH-Works_r708-gc7cc104 is used.

Some examples below.

clip.avs:

fps = 25
length = 2*500
AudioDub(BlankClip(length=fps*length, width=1280, height=720, pixel_type="YV12", fps=25.0), Tone(length=length)).ShowFrameNumber()

ffmpeg:

ffmpeg -y -i clip.avs -c:v ffv1 -c:a copy clip.avi
ffmpeg version N-75275-gd13a2df Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-l
ibilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --en
able-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --ena
ble-decklink --enable-zlib
libavutil 55. 2.100 / 55. 2.100
libavcodec 57. 1.100 / 57. 1.100
libavformat 57. 0.100 / 57. 0.100
libavdevice 57. 0.100 / 57. 0.100
libavfilter 6. 3.100 / 6. 3.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.100 / 2. 0.100
libpostproc 54. 0.100 / 54. 0.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'clip.avs':
Duration: 00:16:40.00, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, 2 channels, flt, 3072 kb/s
Output #0, avi, to 'clip.avi':
Metadata:
ISFT : Lavf57.0.100
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 1280x720, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc57.1.100 ffv1
Stream #0:1: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, stereo, 3072 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=25000 fps= 40 q=-0.0 Lsize= 1140802kB time=00:16:40.00 bitrate=9345.4kbits/s
video:764277kB audio:375000kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.133785%

LWLibavVideoSource() correctly reports a total of 25000 frames. The first frame displayed is frame 00001, and the last three frames display as described above.

clip.avs:

fps = 25
length = 2
AudioDub(BlankClip(length=fps*length, width=1280, height=720, pixel_type="YV12", fps=25.0), Tone(length=length)).ShowFrameNumber()

ffmpeg:

ffmpeg -y -i clip.avs -c:v ffv1 -c:a copy clip.avi
ffmpeg version N-75275-gd13a2df Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-l
ibilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --en
able-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --ena
ble-decklink --enable-zlib
libavutil 55. 2.100 / 55. 2.100
libavcodec 57. 1.100 / 57. 1.100
libavformat 57. 0.100 / 57. 0.100
libavdevice 57. 0.100 / 57. 0.100
libavfilter 6. 3.100 / 6. 3.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.100 / 2. 0.100
libpostproc 54. 0.100 / 54. 0.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'clip.avs':
Duration: 00:00:02.00, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, 2 channels, flt, 3072 kb/s
Output #0, avi, to 'clip.avi':
Metadata:
ISFT : Lavf57.0.100
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 1280x720, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc57.1.100 ffv1
Stream #0:1: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, stereo, 3072 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 50 fps= 40 q=-0.0 Lsize= 2312kB time=00:00:02.00 bitrate=9469.0kbits/s
video:1550kB audio:750kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.526660%

LWLibavVideoSource() correctly reports a total of 50 frames. The first frame displayed is frame 00001, and the last three frames display as described above.

Work-around

As reported at http://forum.doom9.org/showthread.php?p=1738582#post1738582:

Deleting the index and using threads=1

1. It is impossible to easily rename the file or folder of the file due to .
2. You can't reference the same file using relative or absolute path:
   LWLibavVideoSource("file") puts file into file.lwi
   LWLibavVideoSource("full\path\file") reindexes the same file and puts full\path\file into file.lwi

I think offers no benefits at all and should be removed.

Need the following flow instead of sws_getCachedContext initialization.
sws_alloc_context() -> sws_getCoefficients() -> sws_setColorspaceDetails() -> sws_init_context()

Hello,

similar to what ffms2 does:

FFVideoSource("", cachefile = "")

StaxRip if possible keeps all files in a temp dir.

こんにちは。
細かい話ですが……
progress_dlg.cの

include <Windows.h>

のWを小文字に修正していただけますか。
Linuxでクロスコンパイルするとコンパイルエラーになります。

大改造中すみません。

YC48読みのインタレ対応関連のパッチです。

[PATCH 1] lsmashinput: add interlaced yuv420 to yuv444 conversion for yc48 input.

YC48読み込み時(高ビット深度時)のYUV420->YUV444変換のインタレ対応の追加です。

インタレYUV420->YUV422は8bit時同様の5,3,7,1-補間、YUV422->YUV444はAviutlで一般的(?)なleft originの1,1-補間です。

一応9bit/10bit/16bitに対応しています。ループ内のbit_depthによる分岐は関数内で変わることはないので、強制インライン展開と定数伝播による最適化でコンパイル時に削除するようにします。

[PATCH 2] lsmashinput: add faster sse4.1 interlaced yuv420 to yuv444 conversion for yc48 input.

最初のパッチのSSE4.1を使用した高速化版です。こちらもループ内のbit_depthによる分岐はコンパイル時に削除するようにします。

[PATCH 3] lsmashinput: add faster sse4.1 yuv444 to yc48 conversion.

yuv444(16bit)->YC48変換をさらにSSE4.1を使って若干ですが高速化するものです。"use_sse41"で分岐しているところがSSE2のみからSSE4.1までを使ったもので置き換えた部分になります。

patchはこちらに。
http://cid-6bdd4375ac8933c6.office.live.com/browse.aspx/patches

よろしくお願いします。

Currently, L-SMASH Works has no ReadMe.
I welcome ReadMe-s for each plugins too much.

While trying to build the plugin for AviUtl, the following error comes up:

../common/libavsmash.c:35:36: fatal error: libavutil/audioconvert.h: No such file or directory

Looking at the FFmpeg GitHub repo, indeed that header disappeared.

Got a file problem.mkv (https://drive.google.com/open?id=0B_WxUS1XGCPASUZibG5XZkRfeTg) which isn't properly decoded by LwLibavSource, but works fine with FFmpegSource, DGSource.

vapoursynth/vapoursynth#226

Please use MultiByteToWideChar and _wfopen. VapourSynth always gives you UTF-8.

When using LWLibavSource in Vapoursynth like this:

Imports

import vapoursynth as vs
core = vs.get_core()

Loading Plugins

core.std.LoadPlugin(path="G:/Hybrid/Vapoursynth/vapoursynth64/plugins/SourceFilter/LSmashSource/vslsmashsource.dll")

Loading Source: C:/Users/Selur/Desktop/test2160.mov ProRes 10bit 4196x2160

clip = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/test2160.mov")

Cropping

clip = core.std.CropRel(clip=clip, left=0, right=0, top=224, bottom=224)

Output

clip.set_output()

I notice:
a. it's really slow compared to when using LWLibavSource in an Avisynth script
b. I get an error message when I close the preview:

[mov,mp4,m4a,3gp,3g2,mj2 @ 000001cb3508e060] ignoring 'frma' atom of 'mp4a', stream format is 'mp4a'

is there a way to suppress that error? (not really interested in the audio,..)

Hi

When specify DESTDIR= in 'make install', the symlink set the origin path to DESTDIR, this wrong if use in distro package manager.

example in Arch PKGBUILD script:

make DESTDIR=${pkgdir} install

install -d /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/vapoursynth
install -m 644 libvslsmashsource.so.780 /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/libvslsmashsource.so.780
ln -f -s /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/libvslsmashsource.so.780 /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/vapoursynth/libvslsmashsource.so

This is wrong because when install by package manager, the 'libvslsmashsource.so.780' is installed in '/usr/lib/libvslsmashsource.so.780' (without DESTDIR). but the 'libvslsmashsource.so' (installed in '/usr/lib/vapoursynth/libvslsmashsource.so', without DESTDIR) point the origin to '/home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/libvslsmashsource.so.780'

this behavior is fixed if change the line

$(if $(SONAME), ln -f -s $(DESTDIR)$(libdir)/$(SONAME) $(DESTDIR)$(vsplugindir)/$(SONAME_LN))

to

$(if $(SONAME), ln -f -s $(libdir)/$(SONAME) $(DESTDIR)$(vsplugindir)/$(SONAME_LN))

then:

install -d /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/vapoursynth
install -m 644 libvslsmashsource.so.780 /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/libvslsmashsource.so.780
ln -f -s /usr/lib/libvslsmashsource.so.780 /home/sl1pkn07/aplicaciones/vapoursynth-plugin-lsmashsource-git/pkg/vapoursynth-plugin-lsmashsource-git/usr/lib/vapoursynth/libvslsmashsource.so

'libvslsmashsource.so.780' is installed in '/usr/lib/libvslsmashsource.so.780', and the symlink is installed in '/usr/lib/vapoursynth/libvslsmashsource.so' with the origin point to '/usr/lib/libvslsmashsource.so.780'

EDIT: this is applicable to VapourSynth-FFT3DFilter and VapourSynth-TNLMeans (have the same behavior)
EDIT2: better description, i think (sorry. my english is catastrophic)

greetings

It would be a valuable feature if L-SMASH-Works would print progress to stdout.

I've asked DG how he does it in DGIndexNV, his answer:

void OutputProgress(int progr)
{
    static int lastprogress = -1;

    if (progr != lastprogress)
    {
        char percent[20];
        DWORD written;

        sprintf(percent, "%d\r", progr);
        WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), percent, (DWORD) strlen(percent), &written, NULL);
        lastprogress = progr;
    }
}

This is important too for an implementer:

"Every 30 frames, this function is called to write to stdout"

and

progr is an int 0-100 indicating the percent completed.
The caller determines the percent complete from the ratio
of the current file position and the size of the file.
That way you don't need to know the number of frames in the file.

インタレ用 YUV420(8bit) -> YUY2 変換です。
インタレYUV420->YUV422はいろいろな補間方法があるようなのですが、
1～4lineのうち、2,3line目を補間する方法でやってみました。

パッチをこちらに。
https://skydrive.live.com/#cid=6BDD4375AC8933C6&id=6BDD4375AC8933C6!258
(0001-add-interlaced-yuv420-to-yuy2-convertion.patch)

configureでlibffms2へのリンクを追加する必要があるかと思います。

パッチをこちらにおいておきます。
https://skydrive.live.com/#cid=6BDD4375AC8933C6&id=6BDD4375AC8933C6!258
0001-update-configure-script.patch

LSMASHSource.dll doesn't support high bit depth at all currently.
Only packed RGBA, packed YUV422 and planar YUV420 output is supported.

Hello, thank you for sharing your work!

I've been using LSMASHVideoSource and LWLibavVideoSource with LAV decoders on Windows for comparing video encodes with PSNR, SSIM etc. and have found anomalies which I believe to be due to frame synchronization. I am using the DLLs provided by MeGUI.

Here is my comparison setup:

1. A qp=0 mp4/x264 reference version decoded with LSMASHVideoSource;
2. A 0.072 bpp mp4/x264 version decoded with LSMASHVideoSource;
3. A 0.072 bpp webm/vp8 version decoded with LWLibavVideoSource;
4. A 0.072 bpp avi/xvid version decoded with LWLibavVideoSource;
5. A 0.072 bpp ogv/theora version decoded with LWLibavVideoSource;
6. A 0.072 bpp mp4/x265 version decoded with LSMASHVideoSource;
7. A 0.072 bpp webm/vp9 version decoded with LWLibavVideoSource.

In most versions, I force FPS as such:
LWLibavVideoSource("vp8.webm", fpsnum=24000, fpsden=1001).AssumeFPS(24000,1001)

However, when FPS is forced for webm (either vp8 or vp9) or avi/xvid, something goes horribly wrong and PSNR drops from 42db to 20db; they work well without specifying FPS, though. Inversely, when I don't force FPS for ogv/theora, PSNR drops from 30db to 14db. Whereas LSMASHVideoSource always works correctly with mp4, with or without forcing FPS. DirectShowSource displays the same anomaly for webm, but not for avi.

I was using the build of 2015-10-29. Today I switched to the newer 2016-03-02 (r859). Now, LWLibavVideoSource never works correctly with avi/xvid and I am forced to use DirectShowSource, which for this kind of file works with and without forcing FPS. Before this new issue, I was unsure if the problem was L-Smash or the LAV decoders.

I realize this may be an error on the part of whomever compiles the MeGUI DLLs, but it is my understanding that software is built by experts such as youself, so I think it may be worthwile for you to look into this.

Thank you for your time.

Hello,

I received a file from South Korea which crashes vslsmashsource.

The link is deleted because of X-rated video

ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 0s
Bit rate mode : Constant
Bit rate : 20.4 Mbps
Nominal bit rate : 23.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 59.940 (59940/1000) fps
Original frame rate : 29.970 (30000/1001) fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.164
Stream size : 148 MiB (100%)
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

If mp4/mov has Movie Fragments (moof sections, command line: MP4Box -frag 1000 in.mp4 -out out.mp4) it is scanned sequentially by LSMASHVideoSource, which takes a long time (a few minutes for 10GB mp4 for example). At least this is what I see in procmon - sequential reads of 128KiB (131072 bytes) blocks.

It'd be awesome if there is a possibility to read just the moof's index block in small chunks (512bytes or 4kB, whatever is more effective), calculate/read moof section size, seek to next moof section, repeat the process. This could be 100 or 1000 times faster than sequential scanning...

This makes obviously redundant sample descriptions.
If VBR, don't consider any difference of maxBitrate too.
This is a known issue of lsmashmuxer.auf.

Currently, L-SMASH Works has no interface to use as a library.

http://sl1pkn07.no-ip.com/paste/view/affaa8fe

l-smash rev854.6b82864
ffmpeg 2.1.3

greetings

In some TS files, a stream changes the number of channels on the way.
Currently, lsmashinput.aui and LSMASHSource.dll pick channel layout with the first maximum number of channels for the maximum compatibility.
This is not preferred by people who wants only, for example, stereo part if that stream consists of stereo part and 5.1ch part.

Hi, I am getting "VSPipe.exe has stopped working" when trying to process Quicktime Prores 4444 files.
I am using:
core.lsmas.LibavSMASHSource(source=r"Quicktime_Prores_1_frame_4444.mov")

Here is a small sample file (UPDATED):
New_1_Frame_4444.mov.zip

maki-rxrz wrote patches to add repeat control feature.
https://skydrive.live.com/?cid=8658EC275D9699D5&id=8658EC275D9699D5!236

Currently, LW-Libav modules ignore pulldown/RFF of MPEG-2, H.264 and VC-1 stream.
So, if merged, people who encode materials which interlaced and pulldown are mixed with will be happy.

The first step shall be that a patch for libavcodec is applied on it officially.

Integer version of LW48 -> RGB24 conversion.

• use all bits of LW48 data.
• includes faster conversion using SSE4.1.
• fix problem when width cannot be divided by 4.

というわけで、patchをこちらに。
http://cid-6bdd4375ac8933c6.office.live.com/browse.aspx/patches

よろしくお願いします。

av_read_frame() doesn' return PTSs of WMV9/VC-1 in ASF container at present.
This is an issue of libavformat or spec of ASF container.
I think we can correct this ugly seeking outside of libavformat since it seems WMV9/VC-1 presentation reordering is simple; When encountered any I or P picture, flush B pictures to presentation by decoding order.
Also, we should consider about L-SMASH Works original CODEC parser.