[Ffmpeg-devel-irc] ffmpeg.log.20190912

[burek]

[00:51:34 CEST] <furq> KodiakIT[m]: it's the same as the format for passing options to filters
[00:51:45 CEST] <furq> -of json=c=1
[00:56:42 CEST] <KodiakIT[m]> furq, someone in ##linux pointed me in the right direction earlier. Coulda sworn I'd tried that one of the first couple iterations of trying to pin down the syntax, but I guess not /shrug
[01:29:09 CEST] <Henry151> hiya
[01:29:24 CEST] <Henry151> i'm-a-lookin at https://forum.videohelp.com/threads/341308-DVD-ISO-to-MKV-using-ffmpeg this thing and i don't wanna use some other program
[01:29:32 CEST] <Henry151> i wanna use ffmpeg cause i love it
[01:30:02 CEST] <Henry151> what kind of options might i need to specify to tell ffmpeg to keep all the audio,video,andsubtitle tracks from my iso in the outputted mkv?
[01:46:13 CEST] <kepstin> Henry151: ffmpeg doesn't know how to read dvds. use some other program.
[01:53:07 CEST] <Henry151> kepstin: thanks for the blunt truth, just what i needed
[02:39:23 CEST] <AiNA_TE> is there someway to merge .srt subtitle files without them going out of sync?
[02:40:16 CEST] <AiNA_TE> because the time stamps in the .srt only define the start of a subtitle. and not the duration of the segment it belongs to
[03:43:33 CEST] <KodiakIT[m]> So here's something I don't quite understand: why is it that lossless encoding results in enormous file sizes when the input file itself is lossy?
[03:46:06 CEST] <KodiakIT[m]> Or not even necessarily lossless encoding, attempting to transcode with CQ0 will also produce larger files than the input
[03:48:12 CEST] <DHE> but the encoder doesn't know the cause of the lossyness and must encode it exactly as it sees it
[03:55:28 CEST] <KodiakIT[m]> DHE: So, to follow on that, I take it there's no particularly sane way to transcode said files not-quite-lossless-ly besides trial-and-error with setting the values of q{min/max} and bitrate?
[03:56:39 CEST] <furq> something like that, yeah
[03:59:04 CEST] <KodiakIT[m]> Lovely.
[04:01:10 CEST] <KodiakIT[m]> Following on *that* I don't suppose anyone knows of any tools to compare a pair of video files to check for artifacts from downconverting? It'd be one thing if I just needed to compare one or two files, but 220 (22eps x 5 seasons, in & out) 45-ish min long videos is a bit more than I can reasonably compare by hand
[04:13:07 CEST] <KodiakIT[m]> If not I s'pose I've got another project lined up once I get the music library management scripts all in working order.
[04:25:11 CEST] <DHE> while algorithms exist like measuring the PSNR, those are mathematical measurements and can be optimized for, whereas these algorithms are generally tuned to fool the human eye and that's harder to quantify.
[04:47:18 CEST] <taniey> can  the amix filter make audio tracks mix synchronized?
[04:49:58 CEST] <taniey> for instance, auido A with track: ##########---------#########, B with track : #####################
[04:49:58 CEST] <taniey> the ' # ' represent have audio data at time,  the ' - ', represent no have audio data at time.
[04:51:27 CEST] <taniey> and, can the amix filter mix the A and B tracks at right time?
[04:52:30 CEST] <KodiakIT[m]> DHE: Would iterating through the frames with something like pHash be able to detect artifacting, maybe?
[04:57:36 CEST] <KodiakIT[m]> (I've never actually used pHash or anything of the sort myself, just recall overhearing SE's at my old company chattering about using it for dupe/close to dupe image detection)
[05:14:16 CEST] <KodiakIT[m]> I mean I don't really care about minor artifacts that are like 10px * 10px, more just making sure that there's nothing that looks like it belongs on r/brokengifs
[09:45:38 CEST] <LigH> Hi.
[09:46:35 CEST] <LigH> Which parameter would you recommend to ensure that a headerless input format (e.g. TS) is scanned deeply for late appearing streams (subtitles)?
[09:47:07 CEST] <furq> probesize and/or analyzeduration
[09:47:22 CEST] <furq> they do the same thing but probesize is in bytes and analyzeduration is in microseconds
[09:47:42 CEST] <furq> iirc it stops at whichever is lower so you'll probably need to set both
[09:47:59 CEST] <furq> or whichever is reached first, rather
[09:52:48 CEST] <LigH> Thanks
[09:56:51 CEST] <LigH> PS: Does ffmpeg support M/G/T suffixes for large numbers here?
[10:00:07 CEST] <snooky> moin
[10:01:14 CEST] <LigH> auch
[10:01:36 CEST] <LigH> But the rest will be preferred in English here, I guess
[10:04:24 CEST] <LigH> OK, web documentation reports support for SI unit "prefixes" to be appended (but when they are appended, they are a suffix, right?).
[10:05:31 CEST] <barg> I have a video file that is 6GB and I want to extract about 500MB from it, it takes a while. Is there any fast way to do it that is within a $150 budget?
[10:10:49 CEST] <LigH> Well, ffmpeg can do that pretty fast, if you configure it to copy all content streams.
[10:11:08 CEST] <LigH> Instead of recoding.
[10:11:35 CEST] <LigH> The rest is the speed of your drives as bottleneck.
[10:13:13 CEST] <barg> what do you call pretty fast?
[10:13:29 CEST] <furq> pretty fast as in as fast as you can write to disk
[10:13:42 CEST] <barg> one hour
[10:13:46 CEST] <LigH> So, some parameters will be: "-codec copy" along with e.g. "-ss (start time) -to (end time)" - with limited accuracy due to GOP lengths, and a possible undecodable start of the result
[10:14:10 CEST] <furq> the video will always start from the subsequent gop
[10:14:23 CEST] <furq> it just might look broken if the audio timestamps start earlier
[10:14:26 CEST] <barg> would it normally take one hour on a typical computer? or 10 minutes?
[10:14:30 CEST] <furq> uh
[10:14:33 CEST] <furq> it would take a few seconds
[10:14:52 CEST] <barg> i'm reencoding.. should I do the copdec copy first then reencode the result? or would it make no difference?
[10:14:55 CEST] <LigH> Except for very slow laptop harddisks...
[10:15:05 CEST] <furq> it would make a negative difference
[10:15:12 CEST] <furq> if you're reencoding anyway you should do it straight from the source
[10:15:20 CEST] <furq> otherwise the cut points will probably be wrong
[10:15:30 CEST] <barg> this has been running for maybe 20 minutes
[10:15:40 CEST] <furq> what encoder are you using
[10:15:46 CEST] <LigH> The encoding speed will depend on your selected encoder options
[10:16:01 CEST] <furq> if it's x264 then set -preset superfast
[10:16:09 CEST] <furq> if it's libvpx then...good luck
[10:16:29 CEST] <barg> libx264  libmp3lame  -ss 1:28:00 -to 1:55:00
[10:16:38 CEST] <furq> yeah just use a faster preset
[10:16:48 CEST] <barg> and I did the -ss before the -i
[10:17:02 CEST] <LigH> And convenient quality (-q should be equivalent to CRF)
[10:17:04 CEST] <furq> no cpu from the last 10 years will take an hour to encode 30 minutes unless it's 4k120 or something
[10:17:13 CEST] <furq> and no it's -crf for x264
[10:17:19 CEST] <LigH> OK
[10:17:20 CEST] <barg> what does it mean use a faster preset?  and this is core i5
[10:17:28 CEST] <furq> 09:16:01 ( furq) if it's x264 then set -preset superfast
[10:17:35 CEST] <LigH> Read about "x264opts"
[10:17:56 CEST] <furq> https://gitlab.com/qruf/x264settings/blob/master/settings.md
[10:18:10 CEST] <furq> if you really wanted to know
[10:18:33 CEST] <furq> there is also ultrafast but you really shouldn't use that
[10:21:38 CEST] <LigH> I would not recommend very fast presets without generous quality level (indirectly, bitrate). Possibly not a CRF >20. Rather 15-18.
[10:23:25 CEST] <furq> also there's probably no need to reencode the audio
[10:23:33 CEST] <furq> and you should be using aac for compatibility (and quality) anyway
[10:24:01 CEST] <barg> ok trying -preset superfast.  The hard drive in the laptop is Toshiba MK5061GSYN  it looks like 7200RPM  So far over 3min have passed and it is still going.
[10:24:11 CEST] <furq> well yeah the disk is irrelevant if you're reencoding
[10:24:22 CEST] <LigH> Audio streams usually have a short granularity, can be easily cut at any position.
[10:24:41 CEST] <LigH> With respect to their frames.
[10:24:54 CEST] <furq> you can work out how long it's going to take from the progressbar
[10:26:29 CEST] <barg> I can't see a progress bar
[10:26:31 CEST] <LigH> Bye
[10:26:53 CEST] <LigH> Not even running numbers?
[10:26:56 CEST] <barg> this is a screenshot of what I see, current laptop is windows based https://i.imgur.com/0ydPbfX.png
[10:27:01 CEST] <barg> yeah i see running numbers
[10:27:04 CEST] <furq> "speed=5.75x"
[10:27:20 CEST] <furq> also yeah don't reencode the audio
[10:28:43 CEST] <LigH> And the default CRF 23 may be coarse.
[10:29:45 CEST] <furq> oh
[10:30:14 CEST] <furq> you can't use -to after -i if -ss is before -i
[10:30:20 CEST] <furq> it'll keep encoding until the output file is 1:58 long
[10:31:29 CEST] <barg> the output file was 800MB and the source was 6GB but you suggest it still encoded the whole source file and taht's why it took so long?
[10:31:51 CEST] <furq> no it skipped the first 1:28
[10:32:19 CEST] <barg> ok so I will try moving the -to , before the -i ? so -ss ___ -to ___ -i ..
[10:32:34 CEST] <furq> that should work
[10:32:51 CEST] <furq> or -t 26:34 after -i
[10:33:01 CEST] <furq> also yeah you should copy the audio
[10:33:42 CEST] <barg> okay, it says frame=  949 fps=188 q=21.0 size=    5120kB time=00:00:31.74 bitrate=1321.4kbits/s speed=6.29x
[10:33:47 CEST] <barg> does that indicate how long it will take?
[10:33:54 CEST] <furq> speed=6.29x
[10:33:59 CEST] <furq> so it'll take roughly 26 minutes / 6.29
[10:34:09 CEST] <furq> so like five minutes
[10:34:36 CEST] <barg> how do you calculate how many minutes from 6.29x ?
[10:35:02 CEST] <barg> also is 5 minutes a bit slow? what is the limiting factor? hard drive? or cpu?
[10:35:47 CEST] <furq> cpu
[10:36:53 CEST] <barg> is core i5 ancient? how fast would a modern cpu be?
[10:41:36 CEST] <bencoh> there has been like ~10 generations of corei5, so ...
[10:43:15 CEST] <barg> ok thanks, bbiab
[10:43:25 CEST] <barg> a few hours.
[13:12:57 CEST] <classsic> hi
[14:11:52 CEST] <_aeris_> hello here :)
[14:11:59 CEST] <_aeris_> i have trouble with video concat
[14:12:20 CEST] <_aeris_> i have 2 parts, a 5s part generated from image + /dev/zero for sound
[14:12:28 CEST] <_aeris_> and another part for the content
[14:12:39 CEST] <_aeris_> when i concat them, i have a delay on sound
[14:13:25 CEST] <_aeris_> content part sound is in sync, but after concat, it's like if the sound was swift from 2-3s
[14:14:00 CEST] <_aeris_> here is an example : the 2 parts http://data.passageenseine.org/2019/tmp/, the result : http://data.passageenseine.org/2019/codeur-se-s_tous_pays_unissez_vous.mp4
[14:14:19 CEST] <_aeris_> concat is done this way : https://git.passageenseine.fr/pses/video/src/branch/master/converter.rb#L188-L192
[14:24:16 CEST] <_aeris_> seems like the sound of the 2nd part start during the 1st part video
[17:10:29 CEST] <mlok> Hello, could somebody explain to me what the following command does please?
[17:10:30 CEST] <mlok> https://pastebin.com/B2simT0q
[17:10:43 CEST] <mlok> I am especially interested in what mbuffer does
[17:10:58 CEST] <mlok> and pipe:0
[17:11:25 CEST] <DHE> "x | mbuffer | y"   is functionally equivalent to "x | y" but with an effectively huge buffer in the pipe
[17:12:05 CEST] <DHE> I'm not really sure what the goal is though. Buffering compressed video would make sense but the second ffmpeg instance doesn't use "-c copy"
[17:12:23 CEST] <mlok> DHE: for example, if I have an unstable RTMP source, would this be an effective way of creating a continuous pipe for FFMPEG to transcode so it doesn't quit?
[17:12:41 CEST] <DHE> maybe. but the source is a file on disk
[17:12:43 CEST] <mlok> DHE: e.g. if there is packet loss in the source RTMP
[17:13:03 CEST] <mlok> DHE: yes in this particular example it is an mp4, however I can also add an RTMP or HLS stream
[17:13:14 CEST] <kepstin> mlok: you'd still need something (not ffmpeg cli tool) on the front end of the pipe that can handle dropouts and generate a continuous media stream
[17:13:38 CEST] <kepstin> mlok: if you just use an ffmpeg piped to ffmpeg, then it still has all the problems of ffmpeg.
[17:13:56 CEST] <mlok> kepstin: thanks, could you point me in a direction on how I could make a solution for this?
[17:14:17 CEST] <DHE> well if the source is realtime you could still have a problem since mbuffer doesn't pre-fill its buffer and will just pass input straight to output as long as the output never blocks
[17:14:50 CEST] <DHE> hls is "realtime" but still tends to allow bursts of input and has an inherently big network buffer so I wouldn't worry there
[17:15:12 CEST] <mlok> DHE: what about RTSP and RTMP?
[17:15:24 CEST] <DHE> can't comment on those, but I suspect they have much smaller buffers
[17:15:28 CEST] <kepstin> rtsp and rtmp need sender-side pacing
[17:15:57 CEST] <DHE> sure, but assuming you have it and are using this as a pipeline to convert from one RTMP source to output to another RTMP output, I feel like mbuffer isn't buying you anything
[17:16:32 CEST] <mlok> DHE: thanks for the input, any idea of a better solution?
[17:17:36 CEST] <kepstin> mlok: write a new tool that's designed for realtime and generates output frames at a constant rate to feed to ffmpeg regardless of the state of the inputs (might as well use libav* directly rather than a pipe to ffmpeg cli)
[17:18:21 CEST] <DHE> if it were me I'd have the input program do ALL video processing and transcoding, and then have the second ffmpeg just be a remuxer from source straight to rtmp
[17:18:58 CEST] <mlok> kepstin: thanks, how about creating a looped blank video and mapping the source over it?
[17:19:36 CEST] <mlok> DHE: that's tricky as I have no control over the source, or it's located on a far away continent
[17:19:43 CEST] <kepstin> mlok: that doesn't help if you're using the ffmpeg cli, and is unnecessary if you're writing a new application
[17:20:35 CEST] <mlok> kepstin: thanks, I'll look into using libav
[17:53:33 CEST] <horribleprogram> Yo guys
[17:53:34 CEST] <horribleprogram> http://www.giphy.com/gifs/XH50CFfheZUw2uYySH
[17:54:25 CEST] <horribleprogram> Basically, when I drag a .mp4 into an iTunes database or a VLC playlist, etc, it changes its name to "Udemy Video Asset" for about 90% of my .mp4s
[17:54:51 CEST] <horribleprogram> now, apparently these problems (iTunes, VLC) reads the file's internal metadata to display the name
[17:55:06 CEST] <horribleprogram> s/problems/programs
[18:03:08 CEST] <pink_mist> why are you telling us?
[18:04:23 CEST] <horribleprogram> well nvm I just figured out ffmpeg is a command-line tool that does this
[18:05:31 CEST] <horribleprogram> how do I query a specific .mp4 for its metadata
[18:50:02 CEST] <another> ffprobe
[18:51:33 CEST] <horribleprogram> another: ty
[19:37:56 CEST] <garyserj> how do you calculate how long ffmpeg will take from speed=6.29x? e.g. that it will be 26min?
[19:38:08 CEST] <garyserj> also, Do -ss and -to have to be adjacent to each other?
[19:46:01 CEST] <kepstin> garyserj: if you know what the duration of the output video will be, then you can use the speed to calculate how long ffmpeg will take.
[19:46:40 CEST] <kepstin> garyserj: the position of -ss and -to relative to eachother don't matter, but their position relative to any -i input options does
[19:52:42 CEST] <barg> like duration in minutes / speed = total minutes ?
[19:53:04 CEST] <barg> i mean.   outputduration/speed = minutestoprocess ?
[19:53:39 CEST] <barg> what's the unit of speed?
[19:55:09 CEST] <DHE> multiple of realtime processing
[19:55:28 CEST] <DHE> seconds of video processed / second of wall-clock time taken
[19:57:50 CEST] <KodiakIT[m]> I think I asked here before but I'm not sure that I got an answer. Is it possible to take 2 copies of a video (one widescreen, one letterbox) and use ffmpeg to combine/mux them?
[19:58:16 CEST] <kepstin> KodiakIT[m]: you have to describe what you mean by "combine"
[19:58:34 CEST] <kepstin> KodiakIT[m]: since that can mean multiple different things, which you have to do different things for
[19:59:38 CEST] <barg> say you have frame= 2317 fps=183 q=21.0 size=   14080kB time=00:01:17.34 bitrate=1491.3kbits/s speed=6.12x
[19:59:54 CEST] <barg> output duration is 2min..
[20:00:07 CEST] <barg> and that copy/paste was done after about 15-20 seconds
[20:00:16 CEST] <barg> where is the wall clock?
[20:00:58 CEST] <KodiakIT[m]> kepstin: right, sorry. I mean like encode them into one single file that such that either of the two streams could be played back depending on the video player for whichever format makes more sense (e.g. selecting the widescreen on a newer monitor, or the letterbox for a projector/older one)
[20:01:03 CEST] <kepstin> on your wall. or often people have them on a panel/taskbar on their screen somewhere.
[20:01:44 CEST] <barg> so given that line from ffmpeg I can't tell how long it will take, I have to have started a timer before ffmpeg started?
[20:01:59 CEST] <kepstin> KodiakIT[m]: so, the hard problem there is player support. I have never heard of a player that supports automatically selecting a video stream. And many don't even allow manually selecting the video stream.
[20:02:24 CEST] <barg> the time is 7:02pm I don't see how that fits into anything but that's the wall clock
[20:02:30 CEST] <kepstin> KodiakIT[m]: for best compatibility, you want two separate files. You can put both video tracks into a single file with ffmpeg.
[20:02:51 CEST] <KodiakIT[m]> kepstin: That's what I figured. Oh well.
[20:03:32 CEST] <kepstin> KodiakIT[m]: something like `ffmpeg -i video1.mp4 -i video2.mpv -map 0 -map 1 output.mkv` will copy both video tracks into a single file, but playing them is another matter :)
[20:03:51 CEST] <kepstin> (throw a `-c copy` in there too i guess)
[20:04:02 CEST] <KodiakIT[m]> Well, I suppose I'll give it a try! Can't hurt, right?
[20:04:41 CEST] <kepstin> i'd expect most players will play whichever video happened to be first (or otherwise marked as default), and a few might have an option to allow selecting the other manually.
[20:05:56 CEST] <kepstin> barg: if the speed is 6.12x, then for every 1 second that passes on your realtime clock ("wall clock"), ffmpeg will have encoded 6.12 seconds of video.
[20:06:22 CEST] <barg> ah. thanks
[20:06:23 CEST] <kepstin> barg: if you know what the length of the final encoded video will be, then you can divide by the speed to get the amount of real time that it will take to encode.
[20:07:16 CEST] <barg> so unit is seconds per seconds of encoded video
[20:07:23 CEST] <barg> unit of speed is ^
[20:07:34 CEST] <barg> or rather.. seconds of encoded video pe rsecond
[20:09:12 CEST] <barg> yeah, thanks
[20:09:19 CEST] <barg> that works!
[20:12:57 CEST] <KodiakIT[m]> Kepstin, awesome, that did it! VLC can see both video streams just fine it seems.
[20:16:10 CEST] <KodiakIT[m]> Well, with -c copy anyway, doesn't seem to be terribly happy with me when I try to pass -c:v libvpx et al
[20:16:34 CEST] <KodiakIT[m]> "Subtitle encoding currently only possible from text to text or bitmap to bitmap" is what it complains about with the latter.
[20:46:21 CEST] <kepstin> KodiakIT[m]: to fix that particular error, use "-c:s copy" so ffmpeg doesn't try to transcode the subtitles
[20:46:55 CEST] <kepstin> image subtitles are tricky tho, they're usually designed for a particular video resolution so you need to make sure to pick the ones that match the video track you picked :)
[20:48:08 CEST] <KodiakIT[m]> kepstin: I'll try that now! Since it'll be in mkv format, I could figure out how to work those back in later right?
[20:49:11 CEST] <KodiakIT[m]> Or, never mind, I misunderstood, I was thinking that would drop them ><
[22:02:48 CEST] <classsic> Hi everybody
[22:04:03 CEST] <classsic> I use this command: ffmpeg -i rtmp:... -vcodec copy -an rtmp://server..../noaudio |when test the output stream, still get audio :-O
[22:06:01 CEST] <KodiakIT[m]> kepstin: on the subject of subtitles & MKV's, would I be able to swap out all of the fonts for all the video files with subtitles I have (say with Roboto or Noto Sans, or maybe a monospaced variant of one of those?)
[22:06:28 CEST] <kepstin> KodiakIT[m]: you can't swap out fonts on image subtitles, they're images.
[22:07:09 CEST] <kepstin> changing the fonts on text subtitles would probably require extracting them to a file so you can edit them, then reattaching them to the mkv (possible also attaching the fonts)
[22:07:28 CEST] <kepstin> might be easier to do that with mkvmerge/mmg rather than ffmpeg
[22:10:23 CEST] <KodiakIT[m]> Yeah, I figured it'd be using one of the mkv specific utils. (I picked it specifically in case I needed to do something along the lines of adding/changing subs, like this). When I was using Handbrake to extract the files from the dvdbackup dump of the discs, I noticed some subs were labed VOBSUB and others CC608 (or something like that). I'm guessing/hoping that one of those is text and the other is the bitmap?
[22:24:08 CEST] <KodiakIT[m]> I probably wouldn't have even thought to swap the fonts had I not previewed a couple encodes to make sure I got the subs before deleting the dvdbackup dump, and some of them were positively fugly
[22:28:06 CEST] <kepstin> the CC608 stuff is closed captions, and they are a text based format, but are kinda strange to work with
[22:28:35 CEST] <kepstin> vobsub is image subs, only way to improve them is to use OCR to try to read them :)
[22:32:27 CEST] <KodiakIT[m]> I'll keep that in mind for the future. I think I grabbed both where both were available, but I'm pretty sure most were unfortunately VOBSUB (and set that as the default too). Guess I know better for digitizing any other media in the future at least even if its too late for the ones I've already got heh
[22:32:51 CEST] <kepstin> yes, most dvds will tend to have vobsub only
[22:33:32 CEST] <kepstin> closed captions will sometimes be present for releases of stuff that's e.g. originally from tv broadcast, where it had closed captions in the broadcast.
[22:42:52 CEST] <KodiakIT[m]> At least there are libraries for OCR, so fixing those should be a bit less painful than figuring out how to check some other transcodes to make sure there's no (severe) artifacting from screwy encodes.
[22:46:07 CEST] <KodiakIT[m]> Ack. So much for saving more space with the re-encode with the dual video streams. I was hoping that with them being the widescreen and letterbox versions of the same movie that it would be closer in size to the ~550MB of each of the originals rather than the 1.1GB of the straight copy
[23:40:01 CEST] <analogical_> what do I type so I can convert an mkv-file to an mp4-file if the source file contains two audiostreams?
[23:42:00 CEST] <analogical_> ffmpeg -i filename.mkv -c copy newfilename.mp4 only adds one of the audiostreams to the output file
[23:42:25 CEST] <analogical_> I want the output file to contain both the audiostreams from the source file
[23:42:47 CEST] <pink_mist> lol, I didn't even know mp4 supported more than one audiostream
[23:44:22 CEST] <cehoyos> ffmpeg -i input -map 0:v:0 -map 0:a:0 -map 0:a:1 -c copy out.mp4
[23:44:32 CEST] <cehoyos> To make one video and the first two audio streams
[23:44:46 CEST] <cehoyos> -map 0 to map all streams of the first input file
[23:44:59 CEST] <cehoyos> s/make/map
[23:46:37 CEST] <analogical_> so what should I type to achieve my specific intent?
[23:47:39 CEST] <kepstin> KodiakIT[m]: the video streams are encoded completely independently, just muxed into the container. the size would be the sum of the two sizes.
[23:47:45 CEST] <kepstin> into the same container*
[23:48:35 CEST] <analogical_> cehoyos, could you please be more specific?
[23:48:51 CEST] <cehoyos> No?
[23:48:59 CEST] <cehoyos> Sorry, I don't know how I could be more specific...
[23:49:29 CEST] <cehoyos> What is unclear about what I wrote above?
[23:49:44 CEST] <analogical_> Sorry, I don't know how you could be more confusing...
[23:49:55 CEST] <cehoyos> ok, sorry
[23:50:40 CEST] <pink_mist> analogical_: he literally gave you the exact line you needed, what's confusing about that?
[23:51:18 CEST] <analogical_> sigh!
[23:51:32 CEST] <KodiakIT[m]> kepstin: even so I'd hoped the opts I used would have shrunk each of them a bit more than that. (I'd set handbrake to use CQ0 for all the DVD encodings)
[23:51:56 CEST] <kepstin> "cq0"? what codec are you using?
[23:52:00 CEST] <pink_mist> (I'm still surprised that mp4 can take more than one audiostream)
[23:52:46 CEST] <kepstin> KodiakIT[m]: you certainly could make the result smaller than dvds if you choose appropriate options. dvds are encoded using very inefficient settings with mpeg2, so it's easy to make them smaller without noticably reducing quality.
[23:53:40 CEST] <KodiakIT[m]> VP8, using the Consant Quality setting. They're a whole lot smaller than the DVDs they replaced, but even so, I wouldn't mind shrinking it down a bit more.
[23:54:39 CEST] <KodiakIT[m]> Well, not replaced really, they're still kicking around downstairs somewhere, but I'd rather have copies of stuff that's not at risk of no longer playing from getting too scratched up or otherwise physically damaged.
[23:54:54 CEST] <analogical_> pink_mist, it's unusual that mp4 files have multiple audiostreams and it doesn't work nearly as well as it does with mkv files
[23:55:39 CEST] <analogical_> mp4 is an inferior container compared to mkv imho
[23:55:43 CEST] <KodiakIT[m]> whoops, forgot to tag ya in my reply kepstin: ^^
[23:56:03 CEST] <KodiakIT[m]> As I understand it from a technical perspective, it kinda is
[23:56:11 CEST] <kepstin> KodiakIT[m]: vp8 is a pretty terrible codec, and its "constant quality" mode isn't very good
[23:56:15 CEST] <kepstin> at least use vp9 :/
[23:56:18 CEST] <KodiakIT[m]> (But I could understand incorrectly)
[23:57:45 CEST] <KodiakIT[m]> kepstin: That's the next step actually! The only problem is VP9 seems to be a fair bit slower on my system (even with -row-mt=1) (to put it mildly)
[23:58:11 CEST] <analogical_> cehoyos, I finally understood what you typed. Thanks for the help.
[23:58:22 CEST] <kepstin> KodiakIT[m]: hmm, possibly a bad choice of speed options then
[23:59:27 CEST] <kepstin> KodiakIT[m]: the options I'd recommend (ffmpeg option syntax) for vp9 are "-quality good -speed 1", i dunno how they map in handbrake
[00:00:00 CEST] --- Fri Sep 13 2019