Presets pointless with lossless?

[DoomNlNE]

I want to compress lossless so I use this:
x264 --preset placebo --crf 0 --threads 8 "in.avi" -o "output.mkv"

But will using placebo actually increase quality? I thought lossless was the same quality of the source.

In this case couldn't I use a faster preset and still attain the same quality?

Or are the presets only related to the file size and not the quality?

[sneaker_ger]

All lossless encodes have the exact same quality, i.e. they are truly lossless. The difference is indeed the file size.

[LoRd_MuldeR]

Lossless is lossless. So quality-wise the preset cannot make a difference - obviously ;)

However this doesn't mean that using a slower preset cannot improve the compression efficiency, even with lossless mode.

Indeed, this means you could get a smaller file size by using a slower preset...

(Though the "placebo" preset, as the name implies, may not be worth the extra encoding time, compared to "veryslow")

sneaker_ger was faster :p

[gyth]

What is your source?
If you are starting with compressed video, you might be better off remuxing rather than encoding to lossless.

[DoomNlNE]

What is your source?
If you are starting with compressed video, you might be better off remuxing rather than encoding to lossless.
My source is a computer game (an emulator running on PC that captures all frames at 60FPS). I capture lossless (camstudio codec).

I'm quite new to this so I'm unsure what you mean by 'remuxing' and how it can be better than encoding to lossless?

Also, is there a way to make x264 use all logical cores (8: i7). At the moment I'm only seeing 30-40% usage.

[J_Darnley]

If you're capturing in lossless, you can ignore what he said. He was suggesting that if you had compressed video, such as MPEG2, that the lossless output from x264 would almost certainly be larger.

The remuxing would be taking this existing video and putting it into the container you want, e.g. MPEG TS into Matroska.

x264 uses all cores by default, including hyper-threading. You are probably limited by the speed at which you can read or write from disk or decode and process the video.

[DoomNlNE]

x264 uses all cores by default, including hyper-threading. You are probably limited by the speed at which you can read or write from disk or decode and process the video.
I think my disk is fast. I can hit atleast sustained 180MB/s read or write.

Which is the fastest lossless codec to decode? Could I find this out?

Also, I'm using a version of x264 that contains built-in audio options, but what audio codec/format is it defaulting to? Gspot doesn't give me any information.

My last question: Is there a way to skip 'indexing input file'. It often takes a long time (longer than the time it takes to encode!!!). It is especially slow on large files. I'd like to skip it if possible. Please let me know!

[Dark Shikari]

--demuxer lavf doesn't require indexing.

[DoomNlNE]

--demuxer lavf doesn't require indexing.
thanks, so what benefit does indexing give?

[amtm]

It's for if you need frame-accurate seeking. From the ffms2 documentation:

Indexing and You
Before opening a media file with FFMS2, you must index it. This is to ensure that keyframe positions, timecode data and other interesting things are known so that frame-accurate seeking is easily possible.

There are two ways to index a media file. The first one is really a backwards compatibility thing and uses FFMS_MakeIndex. You call the function with the source filename, a binary mask representing which audio tracks you want to index (all video tracks are always automatically indexed since the operation can't fail and takes no additional time), another binary mask representing which audio tracks you want to dump to Wave64 files on disk, an optional progress reporting callback and a likewise optional audio dump filename generation callback; and it will create an index object. With this method there is no way of telling ahead of time how many tracks the file has and hence the only two masks that are useful in practice are 0 (index nothing) and -1 (index everything). If you want to index only certain tracks you will have to redo the indexing after examining the index. This indexing method may be used if you only want to index video tracks, or if you want all the audio tracks regardless of how many they are, or if you already know the track layout of the file you're going to open.

The other method is a bit more sophisticated. First, you create an indexer object using FFMS_CreateIndexer and the source filename. You can then examine the indexer using FFMS_GetNumTracksI, FFMS_GetTrackTypeI and FFMS_GetCodecNameI to determine how many tracks there are and what their respective types are. When you have done so, you call FFMS_DoIndexing, which is exactly like FFMS_MakeIndex except you pass it the indexer object instead of the source filename. Since you now know the track layout, you are free to pass a more restrictive track mask to index only the tracks relevant to your interests. As with FFMS_MakeIndex, all video tracks are always indexed; the trackmask only applies to audio tracks. If you change your mind and decide there are no tracks interesting to you in the file, call FFMS_CancelIndexing. Both FFMS_DoIndexing and FFMS_CancelIndexing destroys the indexer object and frees its memory.

When you have indexed the file you can write the index object to a disk file using FFMS_WriteIndex, which is useful if you expect to open the same file more than once, since it saves you from reindexing it every time. It can be particularly time-saving with very large files or files with a lot of audio tracks, since both of those can take quite some time to index.

To create an index object from a saved disk file, use FFMS_ReadIndex. Note that the index file written has an internal version number; if you have a version of FFMS2 that isn't the same as the one that created the index, it will most likely not accept the index at all (the read function will fail). If you want to verify that a given index file actually is an index of the source file you think it is, use FFMS_IndexBelongsToFile.

[roozhou]

It's for if you need frame-accurate seeking. From the ffms2 documentation:
Indexing benefits only when you require seeking and multiple passes of encoding. If you need to seek to some place but runs a one-pass encoding, the encoder can start from the beginning and skip frames until it reaches the seek position.

Actually indexing can be done simultaneously during the first pass of encoding, so an extra indexing pass is not needed. Unfortunately ffms2 was not wise enough to do such thing.

[DoomNlNE]

thanks for the info.

x264 --preset fast --crf 0 --demuxer lavf --threads 8 "in.avi" -o "output.mkv"

If the source is 60FPS will this command result in a 60fps encode?

[amtm]

Barring the presence of any bugs, yes, the output fps will match the source fps.

[CruNcher]

If you're capturing in lossless, you can ignore what he said. He was suggesting that if you had compressed video, such as MPEG2, that the lossless output from x264 would almost certainly be larger.

The remuxing would be taking this existing video and putting it into the container you want, e.g. MPEG TS into Matroska.

x264 uses all cores by default, including hyper-threading. You are probably limited by the speed at which you can read or write from disk or decode and process the video.

Though this isn't easy @ all depending on the input in terms of playback interoperability, see this strange remuxing behavior with plain mkvmerge and dshow supplied DVB-S2 Transport Stream http://forum.doom9.org/showthread.php?t=163478 and how mpc-hcs parser seems to fail completely ;)

[J_Darnley]

So what? It was an example. I don't care what problems you have with BS, strike that, TS. Nor does this guy it would seem. But I will remember to not use this particular example again!