07:40 <noobaroo> Why does mkvtoolnix / mkvmerge or whatever its official name is, create smaller files than ffmpeg?

07:41 <JEEB> you'd have to somehow compare the structures and if all streams etc werek ept

07:41 <JEEB> *were kept

09:44 <nemo_magneet> ?7

15:46 <jasom> I'm trying to encode interlaced NTSC video with "baked in" deinterlacing. Adding "-vf bwdif=mode=1" to the encode process seems to have no effect (but if I "ffplay -vf bwdif=mode=1" the video is visibly deinterlaced). Am I doing something obviously wrong?

15:49 <jasom> full command-line is: ffmpeg -probesize 1G -analyzeduration 1G -i "$IN_FILE" -vf bwdif=mode=1,null -codec:a copy -codec:v libx265 -preset:v slower -crf:v 18 -max_muxing_queue_size 1024 -map 0 -map 0:s\? -c:s copy -f matroska "$OUT_FILE"

15:53 <Marth64> Try to move those 2 -map before the -vf and start there

15:53 <Marth64> Also send full log if still failing

15:53 <Marth64> via a pastebin

16:00 <Marth64> CLI is very forgiving but when debugging unexpected result I recommend to group individiual stream pipelines by their respective -map entry

16:12 <jasom> Marth64: thanks!

16:12 <Marth64> good luck np

19:19 <ePirat> jasom, why do you do the ,null ?

19:19 <ePirat> so you filter it and throw away the result?

19:20 <furq> that's nullsink

19:20 <furq> null does nothing and passes it through

19:20 <furq> but the question is still valid

19:20 <ePirat> oh right

19:21 <ePirat> what a confusing name :D

20:56 <jasom> ePirat: I do it because I build the pipeline in a script and `filters="bwdif,$filters"` is much shorter than `if test -n $filters; then filters="bwdif"; else filters=bwdif,$filters"` starting out with `filters=null` means the comma always works

20:58 <jasom> Also, the problem was between the chair and the keyboard. I was looking at the input file instead of the output file; the filter is working find

21:53 <Unit640> The problem was your cat who had jumped onto the table and walked in front of the keyboard and pressed keys with its little paws?

23:15 <merriweather> LIBVPX DOESN'T MAKE ANY SENSE!@

23:15 <merriweather> I take an h264 video. Libvpx supposedly compresses better. I re-encode it. It's twice as big.

23:15 <merriweather> Is the "more efficient" statement only valid for if I have raw source material?

23:24 <StephenLynx> maybe is something like when you zip a zipped file.

23:36 <jasom> merriweather: "compresses better" doesn't mean "it will always be smaller"; most lossy codecs have a compression curve with quality on one axis and size on the other. Note that you do always lose some quality when recompressing with any lossy codec, so unless the distance between the h264 curve and the libvpx curve is large enough to overcome this (or unless your desired allowed is lower than the

23:36 <jasom> source video), it's not worth recompressing.

23:37 <StephenLynx> after all, if it could compress any further within the given constraints, why wouldn't it do it the first time?

23:44 <jasom> I recompress DVDs (Fairly high bitrate MPEG-2) as fairly high quality H.265 and get a pretty big savings because there's a *lot* of space between those two curves, and the high bitrate of the source means fewer compression artifiacts that libx265 is going to be trying to compress. If it were an h.264 source, or a low-quality source there probably wouldn't be much point to re-encoding.

23:47 <jasom> IIRC libvpx has a 2-pass mode which lets you specify the approximate size of the resulting file, so you can (within reason) pick how big you want the result to be, but will pay the price in quality.