Does DGIndexNV not support h264 lossless format?!

[asarian]

I encoded a video, losslessly (for a multi-part encode), with:

x264 --qp 0 -o <output> <input>

As per the x264 documentation. It would seem DGIndexNV can't do anything useful with it, though:

DGAVCIndexFileNV20 DGIndexNV 2053.0.0.162 X32
C:\Program Files (x86)\dgdecnv\

f:\video\toys_top_l.mkv 20163556746

DEVICE 0
DECODE_MODES 0,0,0,0,0
STREAM 2 0
CLIP 0 20 0 8
RANGE 0 0 18446744073709551615 0
DEMUX
DEPTH 8
ASPECT 0 0
COLORIMETRY 2 2 2

SIZ 944 x 528
FPS 25 / 1
CODED 0
PLAYBACK 0
0.00% FILM
ORDER -1


Feeding this to VSEditor makes it crash immediately (probably because there's nothing to process, I reckon).

This is bad. I really needed the intermediate lossless format (as multiple parts will be assembled later).

[WorBry]

You have the options of FFMS2 or L-Smash (LWLibavSource) though.

[asarian]

You have the options of FFMS2 or L-Smash (LWLibavSource) though.

Yes, fortunately, it would appear LWLibavSource can do it. :)

[DJATOM]

For lossless intermediates I recommend you to encode into mp4 container and use LSMASHSource() for decoding. First of all, It will not create index, so you don't need to wait for ages for opening lossless intermediates.

[asarian]

For lossless intermediates I recommend you to encode into mp4 container and use LSMASHSource() for decoding. First of all, It will not create index, so you don't need to wait for ages for opening lossless intermediates.

I tried:

toys_top_l = core.lsmas.LWLibavSource ("f:/video/toys_top_l.mkv")


And the index was created lightning fast, actually (a few secs, for a 20G file). My ffmsindex.exe appears to be from 2015, though, so I should probably upgrade it too (I already upgraded to the recently posted L-SMASH-Works-r935-3edd194-win64).

[DJATOM]

Ah, 20G is not that much. Usually I've got 35-50 GB files (depending on bitness and compression), and indexing of those is not that fast thing. Anyway now you know how to avoid indexing in the workflow.

[asarian]

Ah, 20G is not that much. Usually I've got 35-50 GB files (depending on bitness and compression), and indexing of those is not that fast thing. Anyway now you know how to avoid indexing in the workflow.

Thanks.

I don't even know how to directly encode to mp4, btw (unless done with ffmpeg). I always use x264, and it supports .mkv container only (albeit that I normally just have it output to raw .264).

Usually, when stuff needs to be temporally denoised and such, I'd like a frame-accurate input filter, so I kinda like an index. :) But even more usual than that, I use DGIndexNV (which, after a fashion, also creates an index, of course).

[sneaker_ger]

x264cli can be compiled with support for mp4 output but not all builds have it.

x264 --help
x264 core:157 r2969 d4099dd
Syntax: x264 [options] -o outfile infile

Infile can be raw (in which case resolution is required),
or YUV4MPEG (*.y4m),
or Avisynth if compiled with support (yes).
or libav* formats if compiled with lavf support (yes) or
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.flv -> Flash Video
.mp4 -> MP4 if compiled with GPAC or L-SMASH support (no)
Output bit depth: 8/10
...

[asarian]

Seems mine actually does have it:

Infile can be raw (in which case resolution is required),
or YUV4MPEG (*.y4m),
or Avisynth if compiled with support (yes).
or libav* formats if compiled with lavf support (yes) or ffms support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.flv -> Flash Video
.mp4 -> MP4 if compiled with GPAC or L-SMASH support (lsmash)
Output bit depth: 8/10

So, I don't get it. This is L-SMASH without needing an index?!

[StainlessS]

So, I don't get it. This is L-SMASH without needing an index?!

So far as I remember, LSMASHVideoSource(vFN) does not require index for ISO container.

Function IsISOFileName(String s) {
s=RT_GetFileExtension(s) Return(s==".mov"||s==".mp4"||s==".m4v"||s==".3gp"||s==".3g2"||s==".mj2"||s==".dvb"||s==".dcf"||s==".m21")}


Whereas LWLibavVideoSource(vFN) does.

EDIT: You would also likely use LSMASHAudioSource(vFN) for ISO type, rather than LWLibavAudioSource(vFN).

[asarian]

Thanks. :)

[poisondeathray]

lsmash when compiled with x264 is a muxer for MP4 container , that enabled direct MP4 export (instead of MKV or ES)

lsmash is also a standalone muxer.exe (and has boxdumper.exe, remuxer.exe, timelineeditor.exe)

lsmash is also a set of plugins for avisynth, vapoursynth, aviutl

The vapoursynth version for MP4/MOV/ iso base media formats (that do not require indexing) is called with lsmas.LibavSMASHSource . (Avisynth syntax is different; it's called with LSmashVideoSource) . The file doesn't have to been muxed with lsmash . GPAC/MP4box or anything else could have been used

The vapoursynth version for non MP4/MOV formats is called with lsmas.LWLibavSource , and requires indexing

[asarian]

lsmash when compiled with x264 is a muxer for MP4 container , that enabled direct MP4 export (instead of MKV or ES)

lsmash is also a standalone muxer.exe (and has boxdumper.exe, remuxer.exe, timelineeditor.exe)

lsmash is also a set of plugins for avisynth, vapoursynth, aviutl

The vapoursynth version for MP4/MOV/ iso base media formats (that do not require indexing) is called with lsmas.LibavSMASHSource . (Avisynth syntax is different; it's called with LSmashVideoSource) . The file doesn't have to been muxed with lsmash . GPAC/MP4box or anything else could have been used

The vapoursynth version for non MP4/MOV formats is called with lsmas.LWLibavSource , and requires indexing


:thanks: It's perfectly clear now.

[asarian]

The vapoursynth version for MP4/MOV/ iso base media formats (that do not require indexing) is called with lsmas.LibavSMASHSource


I did notice, btw, that I can't 'preview' a file when I let x264 encode to .mp4, though: seems I can only play it when the entire process is done (contrary to, say, raw .264 output). I suppose that's normal?

[ChaosKing]

I did notice, btw, that I can't 'preview' a file when I let x264 encode to .mp4, though: seems I can only play it when the entire process is done (contrary to, say, raw .264 output). I suppose that's normal?

Yes, because the mp4 index is written after the encode is finished.
The mkv can be played while the file is still encoding BUT the "final" mkv has no index (or not a proper one). I noticed that with several 40-60gb lossless h264 files. Seeking takes very long if you don't remux the mkv that was produced by x264.

[asarian]

Yes, because the mp4 index is written after the encode is finished.
The mkv can be played while the file is still encoding BUT the "final" mkv has no index (or not a proper one). I noticed that with several 40-60gb lossless h264 files. Seeking takes very long if you don't remux the mkv that was produced by x264.

:thanks:

[AzraelNewtype]

For lossless intermediates I recommend you to encode into mp4 container and use LSMASHSource() for decoding. First of all, It will not create index, so you don't need to wait for ages for opening lossless intermediates.

Every time I've actually tested, no matter how long the indexing takes, it takes less total time to generate an index and run the script than to use LSMASHSource to run the script. If you have to touch the same lossless file more than once, it only compounds.