LWLibavSource crashes with specific file with VapourSynth

[ChrisK2]

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.

[ChrisK2]

Also happens on Linux (ubuntu). Too bad nobody cares.

[MaverickTse]

I haven't test on Linux yet, but Windows 32bit build works with the VapourSynth R28 pre-built binaries with Python 3.5 (32bit)

[ChrisK2]

Thanks for testing. I used self-compiled 64 bit Binaries built from git HEAD.

[sl1pkn07]

i get this on my archlinux 64bits

vspipe: src/core/vslog.cpp:73: void vsLog(const char*, long int, VSMessageType, const char*, ...): Assertion `false' failed.

VS R30 (from GIT) and lsmashsource r868 (from GIT)

with VSEdit can decode the firts 16 frames, in the frame 17,18 and 19 crash the program. the rest also can decode ok (from 20 to 99)

[dubhater]

@sl1pkn07: The message printed just before that is what matters.

[sl1pkn07]

└───╼  vspipe -y lsmash-test.vpy esee.raw
No frame returned at the end of processing by LWLibavSource
vspipe: src/core/vslog.cpp:73: void vsLog(const char*, long int, VSMessageType, const char*, ...): Assertion `false' failed.
Abortado (`core' generado)

gdb vsedit: http://sl1pkn07.wtf/paste/view/67a77488
gdb vspipe: http://sl1pkn07.wtf/paste/view/9c492a95

[myrsloik]

Try again with the latest lsmashsource. It should at least return a proper error now instead of crashing.

[sl1pkn07]

Error: Failed to retrieve frame 17 with error: lsmas: failed to output a video frame.

in gdb:

[Inferior 1 (process 31105) exited with code 01]

[myrsloik]

And the other obvious question that will probably help me and/or the author. Does it work in avisynth?

[sl1pkn07]

can confirm "works" (decoding without crash) in avsplus r1825 MT and lmashsource r859 (both 32bits) (wine staging 1.9.2)

but the frames 17, 18 and 19 have weird color, and i think corruptions

i think the main problem is in the source instead of lsmashsource

[myrsloik]

Yes, it is. In avisynth it simply returns an uninitialized frame for many of the possible errors. So you get random memory which is usually a recycled previous frame. Definitely not what's expected either. If anything returning the most recent ok frame makes more sense if you want to do error concealing.

[sl1pkn07]

With ffms2 eats that bad frames

lsmashsource (VS)

and same frame whit ffms2 (VS)

same behavior in (avs)

all after removing the index files

[divxmaster]

I have found a workaround for this issue.
My platform is 64 bit windows/64 bit VS, non Linux, but I get the same lsmas: failed to output a video frame error on most m2ts files that I open with vs lsmash - at the same frame, 17-19. It only occurs on m2ts files that have been remuxed with tsmuxer or clownbd. If I open the original 00800.m2ts or whatever, the error does not occur. The workaround is to use BDREBUILDER. If I remux (set to 50gb output), which will direct stream copy with this option, the error does not occur. Although bdrb uses tsmuxer, somehow it is using it differently or specifying different parameters. This doesn't help if you have already created the m2ts remuxes of course. I must also get around to trying a pure 32bit VS environment.

Cheers,
Divxmaster

[divxmaster]

Also found a way to fix m2ts files that you have already processed with tsmuxer or clownbd. In bdrebuilder, use the import -> video files option. This takes a while, but when it finally processes/loads it will have created a new 00000.m2ts file in the working directories. There is no need to tell bdrebuilder to 'save', you can just grab the temporary file. This file works fine with lsmas.