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

[burek]

[00:00:33 CEST] <thebombzen> CFS-MP3: consider the setsar or setdar filter
[00:00:39 CEST] <furq> he is using setdar
[00:00:46 CEST] <thebombzen> ah you are, I didn't read that
[00:01:07 CEST] <furq> fyi you can still chain filters together in filter_complex
[00:01:13 CEST] <furq> you don't need labelled outputs for every single filter
[00:01:32 CEST] <relaxed> he probably needs setsar too
[00:01:36 CEST] <CFS-MP3> furq I do that a bit for clarity (for myself)
[00:02:00 CEST] <furq> [0:v][0:s]overlay,scale=416:-1:flags=lanczos,setdar=dar=16/9,split=2[in1][in2]
[00:02:04 CEST] <CFS-MP3> setdar seems to only apply for the ouput video, but is ignored for the output .jpg (apparently)
[00:02:06 CEST] <furq> maybe it's just me but that reads much more clearly
[00:02:09 CEST] <relaxed> fir non-square pixels
[00:03:26 CEST] <thebombzen> CFS-MP3, that's not a surprise. Consider take your final output (I will call it [out] here for clarity) and then use "[out]split[out1][tempout2];[tempout2]fps=1/10[out2]"
[00:03:40 CEST] <thebombzen> then map [out1] and map [out2] as appropriate
[00:03:50 CEST] <furq> i don't think setdar will do anything for images
[00:04:03 CEST] <thebombzen> This is also the case, yea. JPEG images don't understand DAR
[00:04:18 CEST] <thebombzen> you will have to insert a scale filter if you really want to do that
[00:04:30 CEST] <furq> setdar just sets a flag in the bitstream iirc
[00:04:36 CEST] <furq> so if the codec doesn't have that, it won't do anything
[00:04:36 CEST] <relaxed> he said the video is different- "but the size in the player is different"  setsar=sar=1/1,setdar=dar=16/9
[00:04:41 CEST] <CFS-MP3> I figured that... so how to do emulate the behavior (i.e. create a image that will look as a video frame)?
[00:05:07 CEST] <furq> relaxed: 23:02:04 ( CFS-MP3) setdar seems to only apply for the ouput video, but is ignored for the output .jpg (apparently)
[00:07:59 CEST] <furq> you'd probably need to scale the second split output relative to ih
[00:08:29 CEST] <furq> scale=ih*(16/9):ih
[00:08:45 CEST] <furq> except you'll probably have to make it mod2
[00:09:41 CEST] <nicolas17> what the heck is is_avc in h264 anyway?
[00:10:31 CEST] <CFS-MP3> mod2?
[00:10:34 CEST] <CFS-MP3> ah yes
[00:11:10 CEST] <thebombzen> nicolas17: AVC is another name for H.264
[00:11:37 CEST] <thebombzen> so is_avc is most likely "is this thing even h264?" although I'm not sure what "is" means in this case
[00:11:49 CEST] <nicolas17> typedef struct H264Context {
[00:11:50 CEST] <nicolas17>     /** Used to parse AVC variant of H.264 */
[00:11:52 CEST] <nicolas17>     int is_avc;           ///< this flag is != 0 if codec is avc1
[00:12:11 CEST] <nicolas17> (not actually the first member, I trimmed a hundred things)
[00:12:19 CEST] <thebombzen> well that's weird cause the full name of the codec is H.264 / MPEG-4 AVC.
[00:12:39 CEST] <nicolas17> looks like is_avc is set differently depending on nal_length_size
[00:12:41 CEST] <thebombzen> although avc1 is not the same thing as avc
[00:13:00 CEST] <furq> isn't that start code prefixed
[00:13:00 CEST] <thebombzen> avc1 IIRC is a special subset of H.264, but you should get a second opinion on that
[00:13:03 CEST] <furq> as opposed to annex b
[00:13:27 CEST] <nicolas17> so focusing on nal_length_size instead: I wonder why ffmpeg-generated video has it set to 4 and my code ends up with 0
[00:13:35 CEST] <nicolas17> ffmpeg = command line tool
[00:21:57 CEST] <Nicolas_> thebombzen: no. that didn't work. just as slow as before. maybe I made a mistake when compiling the codec?
[00:22:34 CEST] <thebombzen> I don't know at this point without delving deeper
[00:22:43 CEST] <Nicolas_> sigh
[00:22:49 CEST] <Nicolas_> thx anyways
[00:22:58 CEST] <thebombzen> Someone else might know, but I don't use macOS so you're reaching the end of my knowledge
[00:23:16 CEST] <Nicolas_> sure
[00:23:18 CEST] <thebombzen> nicolas17: for future reference, often we use the term "ffmpeg.c" to refer to the CLI tool as opposed to the FFmpeg project
[00:23:33 CEST] <nicolas17> great
[00:24:19 CEST] <CFS-MP3> furq, can this resize be optimized? [overlaid]scale=iw*sar:ih[scale1];[scale1]scale=416:-1:flags=lanczos[resized];[resized]setdar=dar=16/9[vdar];
[00:24:42 CEST] <CFS-MP3> I tried the obvious thing but it complained about width not being divisible by 2
[00:25:00 CEST] <CFS-MP3> however that is doing what I need
[00:25:02 CEST] <nicolas17> looks like furq is right, that is_avc thing is indeed for annex-b vs... not
[00:25:06 CEST] <CFS-MP3> Got the topic here: https://lists.ffmpeg.org/pipermail/ffmpeg-user/2011-November/003203.html
[00:25:49 CEST] <Nicolas_> CFS: try scale=416:-2?
[00:28:06 CEST] <CFS-MP3> Nicolas: Tried that, doesn't help...
[00:28:21 CEST] <CFS-MP3> basically what I'd like now obviously is to have one scale, not two
[00:28:43 CEST] <Nicolas_> CFS: k. sorry.
[00:29:30 CEST] <AndrewMock> Can ffmpeg downmix DTS-HD-MA or TrueHD to 2.0 using the embededd coefficients?
[00:32:54 CEST] <CFS-MP3> OK I think this could work: 416:ih*416/iw*sar
[00:37:44 CEST] <CFS-MP3> Nah... height not divisible by 2 (416x495)
[00:45:32 CEST] <nicolas17> urgh this makes no sense
[00:49:15 CEST] <CFS-MP3> Solved the division thing which is as trivial as doing a trunc(.../2)*2
[00:49:30 CEST] <CFS-MP3> but definitely I didn't solve the height correctly, now I have a square
[00:49:53 CEST] <CFS-MP3> anyway I'm on the right track, just need to do the math properly :-)
[00:50:22 CEST] <CFS-MP3> Ah wait I think I know that it is
[00:55:09 CEST] <nicolas17> https://paste.kde.org/phoqw9x9n D:
[00:59:34 CEST] <CFS-MP3> This is doing a good job: scale=416:trunc ((ih*416/(iw*sar))/2)*2:flags=lanczos
[00:59:43 CEST] <furq> CFS-MP3: you should just need one scale=416:234
[00:59:55 CEST] <furq> if you just want 16:9 output
[01:00:29 CEST] <CFS-MP3> furq the problem with that is that the .jpg and the .mp4 have different real (by this I mean as displayed) sizes
[01:00:58 CEST] <furq> you mean they do now or you want them to
[01:01:22 CEST] <CFS-MP3> that was what happened with a trivial resize like 416:-1, or -2, or 234
[01:01:41 CEST] <CFS-MP3> however "converting to square pixels" solves the problem apparently
[01:04:50 CEST] <relaxed> furq: I win ?
[01:40:05 CEST] <nicolas17> furq: any idea why my program could be producing much bigger files than ffmpeg.c, if it's using the same x264 parameters? https://paste.kde.org/phoqw9x9n
[01:40:21 CEST] <nicolas17> I need to get rid of all my C++ wrappers and go back to plain C and post the source
[01:52:17 CEST] <dystopia_> diff framerate and diff bitrate
[01:52:31 CEST] <dystopia_> what were your ffmpeg commands?
[01:53:00 CEST] <dystopia_> i think the decimation screwed things up to get weird framerate
[01:53:10 CEST] <dystopia_> but that wouldnt really affect the bitrate
[01:56:40 CEST] <nicolas17> I'm using crf 23
[01:56:45 CEST] <nicolas17> in both
[01:57:24 CEST] <nicolas17> ffmpeg.c command line: ffmpeg -y -f image2 -pattern_type glob -framerate 30 -i "168GOPRO/G00187*.JPG" -r 30 -s 640x480 -vcodec libx264 -crf 23 -preset fast -pix_fmt yuv420p ffmpeg.mp4
[01:58:39 CEST] <dystopia_> is source video already 4:2:0 ?
[01:59:24 CEST] <nicolas17> source is yuvj422p
[01:59:30 CEST] <dystopia_> ahh ok
[02:00:03 CEST] <nicolas17> in my encoder I'm passing it through a SwsContext with AV_PIX_FMT_YUV420P output
[02:00:05 CEST] <dystopia_> well the ffmpeg command ^ seems to be working
[02:00:27 CEST] <dystopia_> your app has the higher bitrate and the 30.15fps
[02:00:40 CEST] <dystopia_> so somthing funky is going on in it's input settings
[02:01:17 CEST] <nicolas17> would bitrate matter if I'm using crf?
[02:02:37 CEST] <dystopia_> crf would lead to diff bitrates, but both are crf23 so i think it's somthing else
[02:02:57 CEST] <nicolas17> and if I was using bitrate, a bad framerate would affect file size (since bitrate is set per second, not per frame), but since I'm using crf that shouldn't matter either
[02:04:13 CEST] <dystopia_> yeah
[02:04:32 CEST] <dystopia_> but somthing is causing your apps bitrate to be 5x ffmpeg.c's
[02:05:25 CEST] <nicolas17> I just tried setting AVStream.avg_frame_rate={30,1}, it made no difference in either file size or ffprobe's reported fps
[02:06:03 CEST] <dystopia_> hmmm
[02:06:47 CEST] <dystopia_> ffmpeg.c = is_avc=true | your app = is_avc=false
[02:06:50 CEST] <dystopia_> very weird
[02:07:01 CEST] <dystopia_> cuz both have x264 header
[02:07:22 CEST] <nicolas17> dystopia_: apparently is_avc is related to the extradata
[02:08:01 CEST] <dystopia_> ahh
[02:08:17 CEST] <dystopia_> yeah im out of ideas :| hopefully someone else can help you
[02:08:19 CEST] <nicolas17> http://aviadr1.blogspot.com/2010/05/h264-extradata-partially-explained-for.html
[02:08:25 CEST] <The_8472> is there a way to seek a stream and then get the current frame number it has seeked to? most things refer to timestamps, but that doesn't take VFR into account.
[02:09:39 CEST] <The_8472> in libav*
[02:09:56 CEST] <nicolas17> dystopia_: "why is one using avcc extradata and the other using annex-b extradata" *is* another question though
[02:10:03 CEST] <nicolas17> but that shouldn't affect bitrate either
[06:33:06 CEST] <hiihiii> hello
[06:33:33 CEST] <hiihiii> I'm trying to run ffmpeg through a server but I'm facing issues
[06:34:32 CEST] <hiihiii> here's my command
[06:34:33 CEST] <hiihiii> -f lavfi -i testsrc=duration=15:size=480x360:rate=30 -c:v libx264 -vf "format=yuv420p" -movflags +faststart testsrc.mp4
[06:34:46 CEST] <hiihiii> here's my output
[06:35:29 CEST] <hiihiii> https://thepasteb.in/p/RghnZjmW8OVFz
[06:36:15 CEST] <nicolas17> dystopia_: I found one difference, ffmpeg.c was using bicubic resizing and I was using bilinear... but using bicubic myself made the difference in bitrate even bigger!
[06:36:59 CEST] <furq> hiihiii: ulimit -u
[06:37:46 CEST] <hiihiii> furq: sorry wut???
[06:38:00 CEST] <furq> what's the output of ulimit -u
[06:41:30 CEST] <hiihiii> 1400
[06:41:47 CEST] <kepstin> The_8472: the only way to get frame numbers in general is to demux each frame from the start and count them. If you seek, you have no idea how many frames you skipped over, that information's not stored in the container index.
[06:42:26 CEST] <kepstin> (if you know that the video is CFR, you can calculate which frame you ought to be on given the timestamp)
[06:46:20 CEST] <furq> hiihiii: try increasing that
[06:46:25 CEST] <furq> e.g. ulimit -u 8192
[06:46:56 CEST] <furq> failing that, try adding -threads 1
[06:47:18 CEST] <furq> if that doesn't work then you probably want to break out strace
[06:49:11 CEST] <hiihiii> fruq : https://thepasteb.in/p/y8h6VqXx8jBIO
[06:51:28 CEST] <hiihiii> -threads did work
[07:00:41 CEST] <hiihiii> not sure what you meant by your last sentence though
[07:12:59 CEST] Action: nicolas17 throws in the towel
[07:23:26 CEST] <Tatsh> how come ffmpeg takes a while when using -ss ?
[07:23:30 CEST] <Tatsh> doesn't seem like it should be that slow
[07:23:45 CEST] <Tatsh> i'm skipping ahead like an hour
[07:24:01 CEST] <hiihiii> put -ss before input
[07:26:02 CEST] <Tatsh> wow, way faster
[07:35:40 CEST] <hiihiii> how can you upload to a server with ftp(host+user+pw info) or any other way?
[07:38:00 CEST] <hiihiii> I read about this
[07:38:02 CEST] <hiihiii> ftp://[user[:password]@]server[:port]/path/to/remote/resource.mpeg
[07:38:41 CEST] <hiihiii> but I wonder will there be any issues of timeout
[07:46:07 CEST] <tdr>  most sane admins disable ftp though
[07:46:18 CEST] <tdr> scp or sftp or rsync or ...
[10:49:45 CEST] <hiihiii> I am trying to output directly to a remote server via ftp
[10:50:59 CEST] <hiihiii> my input is located on a server too
[10:51:54 CEST] <hiihiii> and I'm running my commands through a server
[10:53:35 CEST] <hiihiii> -i input.mp4 -c copy "ftp://USERNAME:PASSWORD@HOST:PORT/path/output.mp4"
[10:56:26 CEST] <hiihiii> https://thepasteb.in/p/k5hYG8PVY6MtE
[11:00:32 CEST] <hiihiii> I tried setting ftp-write-seekable to 1 but still no results
[11:01:57 CEST] <hiihiii> the final line I get from this command is :
[11:01:58 CEST] <hiihiii> video:2890kB audio:1226kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[11:03:12 CEST] <hiihiii> that tells me it had done its job, however, I can't find the output
[11:04:46 CEST] <hiihiii> ah solved
[11:05:01 CEST] <hiihiii> I forgot to set my permissions
[20:54:36 CEST] <hiru> there is something wrong with my ffmpeg conversion. I'm converting a mkv to mp4 but the resulting file has not thumbnail and makes premiere pro crash
[20:55:11 CEST] <hiru> this is the command I used: ffmpeg -i "input" -ss 9.250 -to 16 -c:v libx264 -b:v 12000K -vf "crop=500:300:700:350" "output"
[20:57:51 CEST] <hiru> the input source is a obs recording and it is using this config: color i444, yuv 709, yuv range partial, 12mbps cbr, cpu preset ultrafast
[20:58:27 CEST] <hiru> webm conversions are totally fine, the only problem is with the libx264
[21:00:01 CEST] <BtbN> "has no thumbnail"?
[21:00:11 CEST] <BtbN> I don't think mp4 has an embedded thumbnail in general.
[21:00:24 CEST] <hiru> well I thought it was weird so I mentioned it
[21:00:41 CEST] <hiru> I'm talking about the windows file explorer btw
[21:00:57 CEST] <hiru> the video plays fine but if I try to import in a premiere pro project the whole thing crashes
[21:00:58 CEST] <BtbN> did you interrupt ffmpeg while creating the mp4?
[21:01:09 CEST] <hiru> nope
[21:01:19 CEST] <hiru> when I convert the same file with handbrake it works fine
[21:01:39 CEST] <hiru> and the file shows a thumbnail
[21:02:00 CEST] <BtbN> try forcing yuv420p
[21:02:05 CEST] <hiru> I'm mentioning file thumbnails becasue generally videos without thumbnails are corrupted
[21:02:07 CEST] <BtbN> 444 isn't exactly well supported
[21:03:28 CEST] <hiru> oh it worked :O forcing yuv420p generated a working file
[21:04:53 CEST] <BtbN> the old file was working fine just as well
[21:05:02 CEST] <BtbN> Just broken software crashing at the sight of yuv444
[21:05:46 CEST] <hiru> uhm actually ffmpeg converted it without errors
[21:05:58 CEST] <BtbN> ffmpeg is not the broken part here.
[21:06:02 CEST] <hiru> oh
[21:06:06 CEST] <BtbN> The software that crashed is.
[21:06:22 CEST] <hiru> but it's not just the software I think
[21:06:29 CEST] <hiru> otherwise the file won't look corrupted
[21:06:42 CEST] <hiru> speaking of how it is showed in the file explorer
[21:06:45 CEST] <BtbN> The Windows-Thumbnailer aparently also does not support yuv444
[21:06:53 CEST] <BtbN> That does not make the file corrupted
[21:07:08 CEST] <hiru> not using that thumbnailer tho
[21:07:12 CEST] <hiru> how it is called again
[21:07:30 CEST] <hiru> icaros
[21:07:37 CEST] <hiru> using that
[21:07:45 CEST] <BtbN> You are using Windows Explorer. So you are using Windows capabilities to generate thumbnails of various filetypes
[21:07:51 CEST] <BtbN> yuv444 is seemingly not on that list
[21:08:13 CEST] <hiru> icaros generates the thumbnails windows explorer can't generate tho
[21:08:28 CEST] <BtbN> Well, doesn't seem to work too well for yuv444 either.
[21:09:11 CEST] <hiru> I can't tell unfortunately
[21:09:24 CEST] <hiru> anyway thanks for pointing me in the right direction
[21:09:32 CEST] <hiru> now I know what it was not working
[21:09:53 CEST] <furq> i'm surprised premiere can't handle yuv444p
[21:10:00 CEST] <furq> not too surprised though
[21:11:30 CEST] <hiru> I'll record a mp4 file with yuv444p
[21:11:33 CEST] <hiru> I'll tell you what happens
[21:11:49 CEST] <JEEB> adobe things tend to use mainconcept's decoder for AVC, which means it will work up to 4:2:2, 10bit
[21:11:53 CEST] <JEEB> not 4:4:4 as far as I know
[21:12:06 CEST] <furq> yeah i'd have been more surprised if it didn't do 4:2:2
[21:12:17 CEST] <JEEB> most corporate decoders don't
[21:12:22 CEST] <furq> that's a lot more common for editing isn't it
[21:12:32 CEST] <JEEB> for editors I'd probably recommend ut video since it has modules for most of those closed source frameworks
[21:12:47 CEST] <JEEB> it's huge because it's not made for high compression or !lossless
[21:12:53 CEST] <furq> is premiere still using quicktime/vfw
[21:13:11 CEST] <JEEB> yea, for AVI it uses VFW as far as I know, and on macs it's QT based I bet
[21:13:32 CEST] <JEEB> I'd recommend ffv1 if someone made those modules for it, but alas that's not the case :P
[21:13:35 CEST] <furq> yeah
[21:13:51 CEST] <furq> ut is quite good anyway isn't it
[21:14:18 CEST] <JEEB> as a lossless format it does what you'd usually require. it's just simple huffman coding so it's not exactly good at compression ratios
[21:14:33 CEST] <furq> oh i thought it was fancier than that
[21:14:42 CEST] <furq> i've not really messed with it since ffmpeg got an encoder for it
[21:14:53 CEST] <hiru> so. I generated a mp4 file with the 444 color scheme and icaros can't generate a thumbnail for it and premiere pro can't open it, crashing as well
[21:14:58 CEST] <hiru> so it isn't a ffmpeg problem
[21:15:02 CEST] <JEEB> furq: I wrote the initial version of the FFmpeg encoder :D
[21:15:16 CEST] <furq> this was so long ago that i was probably using the vfw codec with fraps
[21:15:32 CEST] <JEEB> yea, umezawa's done an alright job with it
[21:15:50 CEST] <JEEB> it's just GPL so no code from it can be utilized unless he relicenses it for your use
[21:16:59 CEST] <furq> speaking of licensing lossy codecs
[21:17:09 CEST] <furq> s/y/less/
[21:17:13 CEST] <furq> does anyone use those stupid closed source lossless codecs like magicyuv
[21:17:34 CEST] <JEEB> I bet someone does. durandal_1707 seems to have been reverse engineering them for decoding purposes
[21:17:40 CEST] <furq> neat
[21:18:10 CEST] <furq> i assume someone is using them for video because i've seen more than one TAK album in the wild
[21:18:20 CEST] <furq> and why would you ever do that
[21:18:38 CEST] <JEEB> same as for APE
[21:18:51 CEST] <JEEB> "zomg this format gives me X per cent better compression ratio"
[21:19:46 CEST] <furq> ape is actually open source though isn't it
[21:19:53 CEST] <furq> it's just gpl incompatible because the author's an idiot
[21:19:58 CEST] <JEEB> I don't remember exactly :P
[21:20:08 CEST] <JEEB> but if the license is what it is then it has to be more or less RE'd
[21:20:25 CEST] <durandal_1707> im writing magicyuv encoder
[21:20:34 CEST] <furq> apparently it's open source, it has a clause in the license that says you can use it in gpl projects, but then the rest of the license is gpl incompatible
[21:20:45 CEST] <JEEB> durandal_1707: lol
[21:20:52 CEST] <furq> durandal_1707: is it any good
[21:21:05 CEST] <furq> the codec, i mean
[21:21:34 CEST] <durandal_1707> its very fast lossless codec
[21:21:37 CEST] <furq> the guy who wrote it is incredibly bullish about it but i've never tried it
[21:46:25 CEST] <leif> Does the mp4 codec require a header/footer beyond just what av_write_trailer does?
[21:46:54 CEST] <leif> I ask because videos I create (using the C API) seem to play in VLC but not mplayer.
[21:47:34 CEST] <DHE> container?
[21:49:12 CEST] <leif> DHE: WOops ya, the mp4 container.
[21:49:18 CEST] <leif> h264 video codec and aac audio codec.
[21:49:26 CEST] <leif> (ffprobe can handle the output just fine)
[21:50:29 CEST] <leif> Oh, also, woops, I meant quicktime player can't play it.
[21:50:34 CEST] <leif> VLC and mplayer can play it just fine.
[21:51:19 CEST] <JEEB> what sort of colorspace are you using for AVC? are you using fragments or not for the container?
[21:51:46 CEST] <DHE> that is very likely. quicktime and a lot of vendor decoders only handle yuv420
[21:51:58 CEST] <leif> yuv420p
[21:52:12 CEST] <leif> I'll paste the output of ffprobe
[21:52:26 CEST] <holgersson> thebombzen_: Hi, just as an info: VLC did play this awfully corrupted files suprisingly well - and transcoding with it worked. Dunno why ffmpeg works in this case though.
[21:52:37 CEST] <holgersson> *these
[21:54:44 CEST] <leif> JEEB: DHE Here is the output of ffprobe: https://gist.github.com/LeifAndersen/81f3dcd5f3e4bd69955afbcf127b23e5
[21:55:48 CEST] <JEEB> oh, mpeg-4 part 2 video? I'm actually not sure if QT supports that one
[21:55:57 CEST] <JEEB> try with AVC with libx264 for shits and giggles
[22:00:41 CEST] <leif> Testing.
[22:01:02 CEST] <leif> (It'll take a bit because I was linking against a build of ffmpeg that didn't have x264)
[22:01:32 CEST] <leif> JEEB: HA, nice. It worked.
[22:01:55 CEST] <leif> Thank you.
[22:02:00 CEST] <JEEB> np
[22:02:09 CEST] <leif> I presume ffmpeg needs x264 to output h264 then?
[22:02:40 CEST] <JEEB> there are some other encoders if you cannot comply to the GPL as well
[22:02:43 CEST] <JEEB> such as openh264
[22:03:08 CEST] <JEEB> but generally the best quality/perf is gotten from libx264
[22:03:17 CEST] <JEEB> but it is GPL of course
[22:04:11 CEST] <leif> Its more that I am trying to bundle the libs with my application.
[22:04:21 CEST] <leif> (currently apache, but I don't mind  making it gpl)
[22:04:45 CEST] <leif> But that just means I have a whole other dependency chain to go down for x264. :)
[22:04:53 CEST] <leif> Anyway, thank you again. That was extremely helpful.
[22:05:00 CEST] <JEEB> x264 should be pretty self-contained :)
[22:05:37 CEST] <JEEB> (you don't need the command line app which might link to FFmpeg as well)
[22:06:12 CEST] <leif> That makes sense. Thanks a bunch, ths has ben extremely helpful.
[23:35:39 CEST] <buu> Why does ffmpeg occasionally output 'File 'clone.mkv' already exists. Overwrite ? [y/N] Not overwriting - exiting' without ever asking for input?
[23:36:07 CEST] <nicolas17> maybe you have stdin redirected to something else
[23:37:01 CEST] <buu> I actually don't
[23:37:10 CEST] <buu> My terminal might be slightly busted though
[23:37:52 CEST] <thebombzen_> Fenrirthviti: I didn't figure out what software H.264 encoder it's using. The MP4 metadata didn't say. It's not x264 though. (Unless they're doing dubiously legal things and stripping the SCSI so nobody knows... but that's unlikely.)
[23:38:29 CEST] <Fenrirthviti> huh, weird.
[23:38:42 CEST] <thebombzen> The WebM encoder is vp8/vorbis regardless of the resolution. They should be using Opus, although they already had libvorbis linked probably
[23:38:42 CEST] <Fenrirthviti> thanks for the info though
[23:39:32 CEST] <thebombzen> given that the game audio assets are vorbis-in-ogg, It's unsurprising that the audio is Vorbis and not Opus, but the bitrate was high (128k) so it doesn't really matter tbh
[23:40:04 CEST] <thebombzen> vp8 makes sense because vp9 is slow af, although in some ways none of it really makes sense other than the H.264 hardware encoder
[23:40:39 CEST] <thebombzen> I took *ages* to software encode the 4k video as vp8. I went to get a snack. The hardware encoder I just sat and watched the progress bar
[23:41:20 CEST] <thebombzen> Given that every single highlight has the Overwatch logo at the end of it, you're most likely going to be temporally truncating it and re-encoding with x264 anyway if you care about that stuff
[23:42:22 CEST] <thebombzen> which means that there isn't much reason to use any options other than 4k at 60 fps, 3x supersample, "Ultra Quality," hardware encoded MP4
[23:42:48 CEST] <thebombzen> Even if you want 1080p, or 720p, might as well render in 4k, so when you zscale it down to 1080 or 720 you get an antialiasing effect.
[23:43:54 CEST] <thebombzen> Also, because it renders in yuv420p, afaik if you use -vf zscale=1920x1080,format=yuv420p10le, it'll actually scale to 10-bit directly and correctly without scaling to 8bit and then deepening to 10. I think zscale does that
[23:44:29 CEST] <thebombzen> Also, if you care about 4:4:4, rendering in 4k will produces 1080p chroma planes, so you can use -vf zscale=1920x1080,format=yuv444p (or yuv444p10le) and the chroma planes won't be scaled.
[23:44:55 CEST] <thebombzen> Fenrirthviti: is that enough of an infodump lol
[23:45:35 CEST] <Fenrirthviti> well it's just using nvenc for hardware if you have it, right?
[23:45:44 CEST] <Fenrirthviti> wonder if it'll use quicksync/vce/amf as well
[23:45:55 CEST] <thebombzen> It says "hardware encoder." It didn't specify. However NVENC is my only hardware encoder, so it definitely used that
[23:46:29 CEST] <thebombzen> I tried enabling my iGPU in the bios to try that out, but it ended up screwing with my X server. I'd have to do a bit of extra configuration to figure out how to do that.
[23:47:21 CEST] <thebombzen> My monitor is plugged into my 1070 and my bios has PCI1 as the primary graphics card and GRUB and Win10 work fine, but enabling the iGPU causes my X server to fail. Frustrating.
[23:47:54 CEST] <thebombzen> I'd have to diagnose that but in the meantime I just leave it disabled seeing as it's not all that useful. I have no idea how good the i7-6700k's integrated GPU is but I assume "way worse than the 1070"
[00:00:00 CEST] --- Sun Jul  9 2017