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

[burek]

[01:57:21 CET] <cirdan> evening all
[01:58:01 CET] <cirdan> if I have a multi-part show each part having subs, how can I combine the parts and subs so it all works?
[03:16:57 CET] <quint> I am playing with the HLS format currently, and I am able to successfully stream a video file via my web server using this command:
[03:17:48 CET] <quint> ffmpeg -re -i file.mp4 -map 0:0 -map 0:1 -c:v copy -c:a aac -f hls -hls_flags delete_segments -hls_segment_filename 'chunk%04d.ts' stream.m3u8
[03:18:31 CET] <quint> If I close the stream playing from ffplay, shortly after waiting I can no longer view the video stream (ffmpeg is still happily encoding)
[03:20:06 CET] <quint> these are the errors I start receiving with ffplay: https://paste.linux.community/view/raw/b0f1667b
[03:20:48 CET] <quint> after exiting, then waiting a moment to re play the path of the m3u8 over http
[03:24:07 CET] <quint> Has anyone any idea what I've done wrong? I'm trying to play a video file live as an "event"
[03:25:57 CET] <quint> The video file is H.264
[07:42:40 CET] <leonardus> can the input file be overwritten by the output file with ffmpeg?
[07:46:09 CET] <c_14> ffmpeg doesn't ensure it doesn't do that, but you if you do you'll corrupt your file
[08:40:37 CET] <realies> i suspect ffmpeg died mid transcoding and left a semi-corrupted file that's missing some tags, the node app that spawned it failed the call with "spawn ENOMEM" while the system never had less than 800mb free memory, is it possible that ffmpeg really wanted more memory than the available at the sudden?
[09:31:34 CET] <Keshl> I just wanna run this by someone else because it's 3:30 AM and I might be missing something obvious.. I have "Stream #0:0: Video: h264 (High), yuv420p(tv, bt709/unknown/unknown, progressive), 1280x720 [SAR 1:1 DAR 16:9], 1k fps, 60 tbr, 1k tbn, 120 tbc (default)". -- Is that stream *REALLY* encoded at 1,000 frames per second, or does "fps" mean something else in this context?
[09:35:00 CET] <furq> Keshl: that's 1,000 fps
[09:35:23 CET] <furq> you can doublecheck it with something like mediainfo
[09:36:50 CET] <Keshl> Okay, then something's wonky somewhere. I used ffmpeg to encode this, and told it -r 60.
[09:37:25 CET] <furq> yeah those timebases don't look right for 1k fps
[09:37:33 CET] <furq> i guess it's possible that ffmpeg is misdetecting it
[09:37:58 CET] <Keshl> Well, to be honest, I /assume/ I told it -r 60. It comes from OBS, which uses ffmpeg to do almost all of the heavy lifting. There's a guano-ton of oddities with the files that've been kinda evolving over time.
[09:38:52 CET] <Keshl> For example, if I stream to Twitch and record to disk at the same time, after telling OBS to "use stream encoder" for the disk recording, /I don't get identical output/.
[09:39:17 CET] <Keshl> I don't mean "I redownloaded the video and it's different" -- Of course Twitch is going to encode that. It's more dramatic.
[09:39:57 CET] <Keshl> So, on the live stream, everything's totally fine. No issues anywhere. Disk, once per second, there's like a solid ten dropped frames.
[09:40:20 CET] <furq> that sounds like fun
[09:40:39 CET] <Keshl> It's not "Oh, my player can't keep up" -- If I do ffmpeg -i video.mkv frame_%04d.png, seriously, frame_0001.png through Frmae_0010.png are dupicated.
[09:41:00 CET] <Keshl> (And doing the same to the downloaded video, it's totally fine.)
[09:41:22 CET] <furq> ironically the ffmpeg tee muxer will do exactly that and it seems to work fine
[09:41:29 CET] <furq> so presumably they've duplicated that functionality and broken it
[09:41:33 CET] <Keshl> HEH.
[09:41:54 CET] <furq> i assume this is a cfr video
[09:42:15 CET] <Keshl> ...Come to think of it, this broke around the time I switched to CBR.
[09:42:21 CET] <furq> cfr, not cbr
[09:42:25 CET] <furq> constant framerate
[09:42:38 CET] <Keshl> I was using CRF before, but that kept doing different, but equally weird, things.
[09:42:45 CET] <Keshl> Oh. "Sort of".
[09:42:56 CET] <furq> i mean you've not told obs to record vfr
[09:43:08 CET] <furq> if you have then i guess that might explain the framerate misdetection
[09:43:13 CET] <Keshl> The video output to the stream and to disk is expected to be a constant frame rate of 60 FPS, yes. The input may not always by 60 FPS, but if it goes under, I expect duplicate frames, and if it goes over, dropped frames.
[09:43:19 CET] <furq> yeah, that's cfr
[09:43:30 CET] <furq> vfr would just delay the next actual frame instead of duplicating one
[09:43:43 CET] <Keshl> ...You can /do/ that? o_o?
[09:43:54 CET] <furq> for a given definition of do
[09:44:02 CET] <furq> a lot of things really don't like it
[09:44:11 CET] <Keshl> Okay, that makes sense.
[09:44:36 CET] <furq> you can look at the actual frame timestamps and whatnot with ffprobe -show_frames
[09:44:56 CET] <furq> probably piped into head or less or something if you don't want a million lines spammed into your terminal
[09:44:56 CET] Action: Keshl does that on a 12 second video, not his 15 hour video..
[09:45:04 CET] <furq> or that
[09:45:45 CET] <Keshl> ...That's a lot of info.
[09:46:33 CET] <Keshl> Anyway. Sorry for the tangents. Lemme just ask my actual pressing question..
[09:48:11 CET] <Keshl> So, I've obviously recoreded an utter poopton of video. We're at like 400 hours now. 400 hours of 720p60 video is *big* when you record at 4,500 bits per second. I'm running out of storage space, clearly, and would like to not have this problem anymore. I've been re-encoding my videos with x265 and a relitavely low quality, and it's helping massively, but I still want things to, 'yaknow, /play/, in the future. It all plays fine /right
[09:48:12 CET] <Keshl> now/, but is appearing to have 1,000 FPS going to break anything down the line with future video players?
[09:48:44 CET] <furq> if it plays now it'll probably be fine
[09:48:48 CET] <Keshl> I still have the originals right now, but I can't for much longer, so I kinda need to sort out weirdo encoding issues before I start deleting the originals.
[09:48:50 CET] <Keshl> Okay, thank'ye.
[09:49:34 CET] <furq> i'll leave it to other people go off about the importance of archiving the originals
[09:49:38 CET] <furq> to
[09:50:01 CET] <Keshl> I'm aware, and normally I do, but this is a special case where it just doesn't matter. I actually considered downscaling to 360p on top of all this.
[09:51:44 CET] <Keshl> I'm not planning to actually upload these anywhere, or share them with anyone outside of a select few people, and I'm only really holding on to them because it just feels a little weird not to. I'm doing a full run at default resource rates in a notoriously difficult survival game, and I mostly just want some vague evidence that I actually did it, if in 20 years from now I'm like "was that all a dream?".
[09:54:35 CET] <Keshl> Said game's also notoriously poorly optimized, and I'm on a Sabertooth X79 motherboard, which only supports up to PCIe2. I've had to get a second GPU to handle any sort of recording since my first GPU's busy trying to run the game, and the physics calculations are actually thrown off rather dramtically if I encode on my CPU. PCIe2 is also causing issues; I actually legitinimately do not have the bandwidth to encode 60 FPS above 720p, and
[09:54:37 CET] <Keshl> I have to keep the bitrate under a certain threshold, else I get tons of frames that just go utterly missing. None of this is ffmpeg's fault; it's just all circumstances that mean I already have somewhat crummy video to start with, and I actually don't notice much of a decrease in quality when I re-encode since everything's already kinda weird-looking in the original.
[09:59:30 CET] <Keshl> I actually would be recording at 360p right off the bat if I wasn't streaming online, but people don't seem to appreicate 360p video that much for some reason, and when I tried to downscale the video in real-time in the recording without doing that over the stream, apparently OBS actually made two instances of ffmpeg and genuinely encoded each frame twice from scratch. That was obviously far, far too much of a load for my system, so I
[09:59:32 CET] <Keshl> had to just copy the network's encoder (even though it's clearly not actually a copy, somehow) and then encode it again later. My choices were downscale to 360p or try x265, and they actually give pretty comprable results in terms of filesize, but x265 looks a heck of a lot better, so I've gone with that and no downscaling. I figure if I need to save even more space later, I can downscale that and I ain't going to care that I encoded
[09:59:33 CET] <Keshl> three times, considereing the amount of downscaling it'd be.
[10:00:57 CET] <Keshl> Anyway, thank'ye for the help. I wish I could return the favor, but I only have about half an idea of what I'm doing with ffmpeg. x.x
[10:52:56 CET] <Keshl> Not urgent. Just curious: Why does ffprobe mis-detect things like this, but everything's still okay? I figure there has to be a good and probably interesting reason; obviously with such a good project and so many contributors, it seems silly that there'd be a problem as critical as "ffmpeg can't figure out what a frameerate is and just makes absurdely big numbers to compensate", so I assume that that isn't an actual problem and there's
[10:52:58 CET] <Keshl> something deeper to it. I'd like a general idea of what that might be. Now and then, I try to learn more about how modern videos work, but it tends to go right over my head. This seems like something I might be able to grasp.
[10:55:26 CET] <Mavrik> The reason is probably the fact that static framerate isn't something that's a thing in modern video formats :)
[11:16:05 CET] <Keshl> Thank'ye. That is interesting. o_o
[11:42:04 CET] <myhau> hi, I have a question: should I expect dash demuxer in standard ffmpeg distribution for macos ?
[11:43:30 CET] <myhau> I'm asking, because web documentation lists (https://www.ffmpeg.org/ffmpeg-formats.html#dash-1) it as a provided demuxer, but on my machine ffmpeg -demuxers does not contain it
[11:43:49 CET] <myhau> (ffmpeg version 4.1)
[11:55:24 CET] <chinasaur> myhau: I don't think so
[11:55:37 CET] <chinasaur> https://evermeet.cx/ffmpeg/ lists the compile flags
[11:55:58 CET] <chinasaur> enable-libxml2 is not present which is required for dash support
[12:25:49 CET] <azaki> is ffmpeg going to use dav1d or are the devs working on their own decoder?
[12:26:28 CET] <azaki> for av1 decoding
[12:27:55 CET] <furq> azaki: a bunch of the dav1d contributors are also ffmpeg contributors
[12:28:01 CET] <furq> so it'll probably just get folded in at some point
[12:28:26 CET] <azaki> furq, ah, nice.
[14:15:16 CET] <sur3> I'm trying to use vaapi for encoding but ffmpeg gives me "libva info: va_getDriverName() returns -1" even though when invoking vainfo directly it finds my amd driver
[14:20:47 CET] <sur3> ok seems i needed: LIBVA_DRIVER_NAME=radeonsi
[14:20:57 CET] <sur3> but now there is still a problem..
[14:21:07 CET] <sur3> [h264_vaapi @ 0x55d3d114b720] B frames are not supported (0x1).
[14:21:17 CET] <sur3> how to solve that?
[14:28:00 CET] <sur3> ok found option -profile:v 578 to solve the b frame problem, but what does it do?
[15:31:06 CET] <relaxed> sur3: I believe it sets constrained_baseline, look at ffmpeg -h encoder=h264_vaapi
[15:31:30 CET] <relaxed> -profile:v constrained_baseline would work too
[15:34:03 CET] <Mavrik> That will look awful tho O.o
[16:33:46 CET] <toli> guys, I need help on converting video files without audio in them
[16:34:33 CET] <toli> so, the goal is to convert 720p to 1080p, but I want to conserve the bitrate, which changes from 720p 10000kbps to 498kbps
[16:34:49 CET] <toli> the video sources are in h264
[16:35:21 CET] <toli> even if I use -minrate 12000k -maxrate 12000k -bufsize 12000k it keeps the output file in 480 bps
[16:48:49 CET] <Blacker47> <toli> so, the goal is to convert 720p to 1080p <-- the pulled apart pixels are crying.
[16:50:49 CET] <toli> Blacker47, the resolution will stay the same at the end I know, just need this as we are using a software which is limiting the media files, it checks the details of the file before displaying it
[16:51:21 CET] <toli> it will not show you the files in 720p, but in 1080p :)
[16:52:17 CET] <toli> now we are making all the medias in 1080p, but we still use files since 10 years ago, where we only made 720p, and we don't have the sources to encode them in 1080
[17:04:30 CET] <sur3> I'm just trying to compile ffmpeg with amf now, but configure says "ERROR: amf requested but not found" what exactly is it missing?
[17:05:11 CET] <sur3> when trying to use omx it at least says "ERROR: OMX_Core.h not found"
[17:08:32 CET] <BtbN> check config.log
[17:10:35 CET] <kepstin> toli: please share your complete command line.
[17:11:39 CET] <kepstin> toli: main thing to note is that unless you specify a target bitrate (-b:v), x264 uses crf mode by default, and I'm not sure that -minrate really does anything in that case.
[17:29:55 CET] <toli> kepstin, This is my command ..\bin\ffmpeg.exe -i 201811281410349938-EPC_PROMO_12_decembre2018_photoderm_dperarls.mp4 -vcodec libx264 -b 750000 -vf scale=1920:1080 out\test.mp4
[17:30:32 CET] <toli> this is the only way that the exported file is 4000-5000 pbs
[17:30:36 CET] <toli> bps
[17:33:45 CET] <kepstin> toli: you're setting -b 750000 (750kbps) and no other options there.
[17:34:43 CET] <toli> and it says max bitrate
[17:34:56 CET] <kepstin> you didn't set a max bitrate in that command line
[17:35:38 CET] <kepstin> the -b option just sets a target average bitrate, and it's possible x264 might undershoot that on non-complex video (or overshoot it on short video)
[17:35:40 CET] <toli> how to set the cpb?
[17:36:00 CET] <kepstin> sorry, what's cpb?
[17:36:23 CET] <toli> cpb: bitrate max/min/avg: 0/0/76800000 buffer size: 0 vbv_delay: -1
[17:37:15 CET] <kepstin> hmm. adding the -minrate, -maxrate, and -bufsize options should tell x264 to fill in those values, I think...
[17:37:54 CET] <kepstin> (you probably need to choose values that make sense, i'd expect x264 will behave strangely if -b is lower than -minrate for example)
[17:38:27 CET] <kepstin> also, I don't think x264 does padding? (or if it does, it needs additional options), so you might still see undershoots.
[17:47:26 CET] <q3cpma> Hello, does anyone know how to remove the side data from mp3 files? I'm using the volume=replaygain audio filter so I don't want to keep replaygain data.
[17:50:37 CET] <kepstin> q3cpma: the volume filter should be dropping the side data as it applies the gain
[17:51:12 CET] <durandal_1707> -af asidedata=mode=delete:...
[17:51:51 CET] <q3cpma> kepstin: Well, it doesn't
[17:52:26 CET] <kepstin> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/af_volume.c;h=b106ed8cf4aa82999d1c3eeaf12aeda2b9550dae;hb=HEAD#l387 it's right there in the code :/
[17:52:32 CET] <q3cpma> durandal_1707: Didn't work. Tried "-af volume=replaygain=drop,asidedata=mode=delete"
[17:52:51 CET] <kepstin> note that that removes the side data, but it's possible that you have some replaygain *metadata* tags which ffmpeg isn't removing
[17:53:55 CET] <q3cpma> It looks like the side data I'm talking about is carried from flac to mp3
[17:54:26 CET] <kepstin> q3cpma: it's probably metadata rather than side data. can you pastebin the complete ffmpeg output?
[17:57:55 CET] <q3cpma> Here: https://dpaste.de/URaE
[17:59:02 CET] <kepstin> can you pastebin the complete ffmpeg with the *default* log level?
[17:59:08 CET] <kepstin> that removed all the good stuff :/
[17:59:15 CET] <q3cpma> Oh yeah, whoops
[18:04:23 CET] <q3cpma> Here, sorry for the slowness https://dpaste.de/sEjW
[18:06:15 CET] <kepstin> huh, that's really weird
[18:06:25 CET] <kepstin> also weird, your ffmpeg isn't showing the version banner. what version is it?
[18:06:38 CET] <q3cpma> Yeah, I aliased it for this
[18:06:52 CET] <q3cpma> It's 4.0.3 on gentoo
[18:08:04 CET] <q3cpma> So what's strange is that's it's removed when writing to flac, but not mp3
[18:08:09 CET] <kepstin> hmm, i'm pretty there's no changes to the volume filter since 4.0, really weird that the side data is still showing up on the output
[18:08:56 CET] <q3cpma> Forgot to include `ffprobe test2.flac` but the side data is indeed no here for this one
[18:09:24 CET] <kepstin> at this point, all I can say is you might want to file a bug report, and if you do so please actually include the complete output (no aliases that hide output or changes to loglevel), and consider trying a build from git (it's pretty quick/easy to do that).
[18:09:51 CET] <q3cpma> I'll do.
[18:10:48 CET] <kepstin> does this happen on all your mp3 files or just some of them?
[18:10:54 CET] <kepstin> er, flac files*
[18:11:24 CET] <kepstin> that said, the metadata looks fairly normal (the reference level stuff is a bit unusual, but those are ignored/removed)
[18:11:45 CET] <q3cpma> All the files, here
[18:12:19 CET] <q3cpma> Looks like it's only for libmp3lame, libvorbis/libopus have no problem
[18:12:37 CET] <kepstin> lets see if I can reproduce this.
[18:15:45 CET] <kepstin> weird, it's happening for me with all output formats i've tested with 4.1
[18:17:48 CET] <q3cpma> I thinks I'll use flac -> asidedata -> flac -> mp3 for now
[18:19:01 CET] <kepstin> the weird thing is that in my 4.1 build, it doesn't remove the replaygain side data with flac either
[18:19:20 CET] <q3cpma> Wait no, asidedata doesn't work too
[18:19:32 CET] <q3cpma> I'll emerge 4.1 and try again the whole stuff
[18:20:01 CET] <kepstin> the workaround is to use an audio file tag editing software on the mp3 result to remove the replaygain tags :/
[18:20:38 CET] <q3cpma> What kind of software? Since this isn't at the container level, right?
[18:21:03 CET] <kepstin> the replaygain info is stored in id3v2 tags (TXXX:REPLAYGAIN_ALBUM_GAIN, etc.)
[18:21:12 CET] <kepstin> container level, yeah
[18:21:13 CET] <q3cpma> Well, but not the side data, right?
[18:21:32 CET] <kepstin> the side data is an ffmpeg internal concept, has nothing to do with how it's stored in the file
[18:21:57 CET] <kepstin> in most formats, ffmpeg reads from the metadata tags to fill in sidedata, then saves sidedata by writing to metadata tags.
[18:21:58 CET] <q3cpma> Oh, I see
[18:23:06 CET] <q3cpma> I updated to 4.1, and encoding to flac still strips the replaygain data
[18:26:22 CET] <q3cpma> Strange, but the software I used didn't find any tag
[18:27:39 CET] <kepstin> hmm. I might not have time to look at it until later, but if you could encode a sample mp3 (use -t 1 so it's just 1 second long or something) i can check what's stored in there.
[18:28:21 CET] <kepstin> although since I can reproduce the issue here that's probably unneccessary actually
[18:28:52 CET] <q3cpma> Yeah, but strange that id3tool and id3ted can't find anything
[18:29:01 CET] <q3cpma> As I said, it's probably not store in the container
[18:29:50 CET] <kepstin> there's no where else it could be stored other than extra container headers to the mp3 data
[18:30:05 CET] <q3cpma> Well, it could be store in the actual frames, like for flac
[18:30:26 CET] <kepstin> that's not how mp3 works :)
[18:30:39 CET] <q3cpma> Well, I don't see any other explanantion
[18:30:47 CET] <kepstin> hmm. looks like ffmpeg is writing a xing header, i wonder if it's filling that in.
[18:30:48 CET] <q3cpma> ffplay/mpv find the information, but all the id3 tools don't
[18:32:29 CET] <q3cpma> kepstin: Here's the test file (1s): https://pomf.pyonpyon.moe/hyozvh.mp3
[18:32:45 CET] <kepstin> yeah, I've already made one and i'm seeing the same behaviour
[18:33:44 CET] <q3cpma> I see.
[18:34:12 CET] Action: kepstin is busy at work right now, but will definitely look into this more in the evening.
[18:35:00 CET] <q3cpma> kepstin: Should I still make a bug report,
[18:35:59 CET] <kepstin> yeah, go ahead.
[18:36:03 CET] <q3cpma> Okay
[18:36:09 CET] Action: kepstin should test some input formats other than flac, too
[18:37:06 CET] <kepstin> hmm, it seems specific to flac input files
[18:37:17 CET] <kepstin> i don't see the same thing with e.g. opus input
[18:37:50 CET] <kepstin> oh, nvm, it's not reading the replaygain from this opus file at all
[18:37:54 CET] Action: kepstin tries more format
[18:38:06 CET] <q3cpma> Yeah, I tried wv, same story
[18:38:28 CET] <q3cpma> The main difference is that ffprobe prints "Side data: track gain..." only for flac, here
[19:25:18 CET] <SpeakerToMeat> Hello All.
[19:25:27 CET] <SpeakerToMeat> Question, do DPX files have a metadata place for fps setting?
[19:28:12 CET] <durandal_1707> yes
[19:28:21 CET] <SpeakerToMeat> I want to export a 23.976 prores to DPX which I'll reinterpret at 24 (constant frame reencoding), but the text says it'll output at 23.98, I know single dpx can't be 23.98 as they're discrete, but I wonder if some metadata is being set in them that might confuse some NLEs/encoders. If so, is there any way I can tell ffmpeg to out the dpx at 24 without doing a time constant reencode?
[19:28:46 CET] <durandal_1707> that is not implemented
[19:28:51 CET] <SpeakerToMeat> hmm
[19:29:22 CET] <SpeakerToMeat> Maybe I can export them as it is, and run a batch change with exif-tool or a library (and python or similar) and tell them all they're 24
[19:29:25 CET] <SpeakerToMeat> thanks
[19:32:06 CET] <SpeakerToMeat> Btw if I have video and multiple audios, I can use map to output each on a file, right? like: "-map 0:0 -c:v dpx files%06d.dpx -map 0:1 -c:a copy file.wav" no?
[19:39:59 CET] <SpeakerToMeat> Btw does ffmpeg for conversion use all possible cores (when possible)?
[20:43:49 CET] <kepstin> SpeakerToMeat: individual encoders/decoders may be multithreaded, but the ffmpeg cli tool otherwise only uses a single cpu
[20:47:25 CET] <SpeakerToMeat> I wonder if prores->dpx will multithread, it should be able to.
[20:47:56 CET] <SpeakerToMeat> Yes, it's multithreading. thanks
[22:14:45 CET] <SpeakerToMeat> for going from 23.976 to 24 without frameblending I need to do setpts=0.999 right?
[22:15:55 CET] <SpeakerToMeat> ffmpeg -i my_23.976.mov -vf "setpts=0.999*PTS" -r 24 my_24.mov no?
[22:16:45 CET] <Keshl> Quick comment on my issue from last night: Okay, things got weirder. If I set the bitrate to 8,000 instead of 4,500, magically it reads everything as 60 (fps, tbn, and tbc all report 60), the duplicated frames in the recording are gone from their usual spots, and dumping the frames to PNG files shows them all individually unique. MPC reports it as playing at 60 just fine. Everything's happy. ... What the *heck*? o_o'
[22:16:56 CET] <Keshl>  /Literally/ the only thing I changed was bitrate.
[22:17:20 CET] <JEEB> Keshl: some encoders drop frames if they can't compress
[22:17:23 CET] <JEEB> theora for example did that
[22:17:33 CET] <JEEB> so depending on your encoder used it might be doing that
[22:17:43 CET] <Keshl> My encoder was nvenc. Does that one do that?
[22:18:00 CET] <JEEB> no idea, I think that's mostly controlled by the driver
[22:18:02 CET] <Keshl> Oh right, wait, you weren't here last night for the weirdness.
[22:18:05 CET] <JEEB> ASIC encoders yay
[22:20:17 CET] <Keshl> Quick summary: I'm recording my gameplay footage because I'm trying to beat a long and difficult game, and down the road, if I start wondering if it was all a dream, I'll be able to show myself that I actually did it. Quality doesn't matter too much here since it's just for my own use and I just want a gentle little "You did it!" reminder, not a frame-by-frame analysis of my tactics. I was going to record at 360p and encode with h264 on
[22:20:19 CET] <Keshl> CPU, using a CRF of like 28 or maybe 33, but due to various hardware issues and people wanting to watch me play in real-time, I had to settle for nvenc at 720 instead.
[22:20:21 CET] <Keshl> Now, here's the weirdness.
[22:22:33 CET] <Keshl> I'm using OBS to do all the streaming and recording, which is basically just a GUI frontend for ffmpeg with some extras thrown on top, primarily aimed at streamers who just want to click "Go" and forget about it. I have it set to use the same encoder to stream to the network and to record to disk, so logically it's only encoding once but has two outputs. /Somehow, these outputs are not equal/. The network stream magically doesn't have
[22:22:34 CET] <Keshl> dropped frames anywhere, but on-disk recording does.. And weirder still, the on-disk recording somehow claims it's been recorded at 1,000 FPS (60 tbn, 120 tbc). The recording plays totally fine, thank goodness, but I came here asking is the fact that ffmpeg thinks it's 1,000 fps might cause issues with playback down the line.
[22:23:03 CET] <Keshl> I was recording and streaming at 4,500 bps back then. Today I tried 8,000 just for kicks, and that change alone seems to have magically solved the fps detecition(?) issues.
[22:23:26 CET] <JEEB> the "1000fps" stuff is FLV output, right?
[22:23:47 CET] <JEEB> (the time base for FLV is 1000Hz)
[22:23:47 CET] <Keshl> I'm recording to an MKV container, but if you're basically asking "Is that directly from OBS", then yeah.
[22:24:16 CET] <JEEB> ok that's interesting then because I would have thought matroska has a somewhat larger time base than that
[22:24:25 CET] <Keshl> MKV because I have four audio streams (One for just game audio, one for just my mic, one for just Skype, one for everything combined for compatbility purposes.)
[22:24:46 CET] <Keshl> ...Oh my gosh, that makes sense suddenly.
[22:26:28 CET] <Keshl> Twitch it's self can only handle one audio stream. I'm recording to disk with four, but sending to the network with one. I remember reading somewhere that you can't just magically add or remove audio streams; adding or removing streams requires a re-encode. If that's all accurate, then that'd explain how the two outputs aren't identical. Additionally, if ffmpeg is taking audioo stream bitrates into consideration, then logically the disk'
[22:26:29 CET] <Keshl> s output is getting less bits on it's video stream since I have almost 1,000 extra bits of audio being sent there, while the network stream only has 1/4th of the audio bandwidth being used up.
[22:27:23 CET] Action: Keshl checks his really old recordings to see if those are identical, since they only have one audio and one video stream.
[22:27:34 CET] <JEEB> yes, FLV lets you only put a single audio and video track
[22:27:43 CET] <JEEB> twitch takes in FLV
[22:28:37 CET] <Keshl> Yep. Totally fine.
[22:28:47 CET] <Keshl> Problem started when I started adding more audio tracks.
[22:29:34 CET] <JEEB> well that's a single difference at least
[22:29:49 CET] <Keshl> Am I right in assuming that, locally, if I want the four audio tracks, and I want to stream to Twitch at the same time, I absoutely have to encode twice? Once for MKV locally and once for FLV to send to Twitch?
[22:30:12 CET] <BtbN> that's up to the software
[22:30:23 CET] <JEEB> technically nothing stops you from pushing an AVPacket into multiple muxers
[22:30:34 CET] <JEEB> AVPAcket being something an encoder throws out
[22:30:43 CET] <JEEB> (while AVFrames are decoded raw samples=
[22:30:57 CET] <Keshl> Please excuse my ignorance here.. Muxing is a seporate step after encoding and what actually stuffs the output from an encoder into a file container, right?
[22:30:57 CET] <furq> even the ffmpeg cli can deal with that
[22:31:00 CET] <kepstin> in fact, ffmpeg includes a muxer that lets you send the same packets to multiple muxers, and can be used to for this purpose
[22:31:07 CET] <furq> muxing puts the elementary streams into a container, yeah
[22:31:45 CET] <furq> but yeah if OBS actually does this then it sucks really badly
[22:31:49 CET] <Keshl> Okay, nifty. I can try that. It lets me put albitrary command line stuff in a box somewhere, though I don't actually know what it does with it all. Is there documentation on how to achieve what you guys are talking about?
[22:32:04 CET] <furq> https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs#Teepseudo-muxer
[22:32:07 CET] <Keshl> (Like, with just straight ffmpeg on a command line.)
[22:32:15 CET] <furq> that's how you'd do it with just ffmpeg
[22:32:17 CET] <JEEB> did the tee muxer let you limit the streams?
[22:32:19 CET] <Keshl> Thank'ye!
[22:32:23 CET] <furq> i obviously wouldn't recommend capturing with ffmpeg though
[22:32:26 CET] <JEEB> if this guy wants one video and audio into FLV
[22:32:33 CET] <Keshl> "Obviously"? Why not? XD
[22:32:36 CET] <JEEB> and then all tracks into something else
[22:32:38 CET] <furq> JEEB: yeah it does
[22:32:41 CET] <JEEB> cool
[22:32:58 CET] <JEEB> I will probably still implement something similar in my stuff instead though
[22:33:15 CET] <JEEB> because I'd rather re-init at failures if possible instead of killing all
[22:33:20 CET] <kepstin> Keshl: ffmpeg doesn't include a high performance screen capture for windows suitable for capturing games
[22:33:27 CET] <JEEB> yea
[22:33:29 CET] <kepstin> Keshl: obs has its own screen capture
[22:33:44 CET] <JEEB> the win8+ APIs would be a good addition but you'd have to get it async somehow
[22:33:55 CET] <furq> Keshl: i guess you'd want -f tee "[select=\'v:0,a\']local0.mkv|[select=\'v:0,a:3\':f=flv]rtmp://server0/app/instance/playpath"
[22:33:59 CET] <JEEB> virtualdub is funny enough the least bad "normie" app that does that API stuff
[22:33:59 CET] <Keshl> ...Ho boy. Okay, this went over my head in like two seconds, mostly due to my complete failure to understand what -map actually does. I've read the manual on it, but it assumes I have a lot of knowledge about videos that I don't actually have. I don't think this is ffmpeg's fault, considering that most typical people won't ever need to mess with that option, but yeah, it's beyond me. <É<'
[22:34:12 CET] <furq> you can ignore the -map stuff in that command
[22:34:29 CET] <furq> that command has a bunch of filters that complicate the example
[22:35:38 CET] <furq> also yeah like JEEB mentioned, the tee muxer will stop outputting all streams if one of them dies
[22:35:47 CET] <Keshl> But I have to use -map myself for my own streams, and I'm not sure how that mixes in with this. See, OBS is doing /something/ to only send the "combined audio" channel to Twitch with my video, but locally, when I re-encode stuff to downscale it and whatnot, I have to do "-map 0" to actually preserve all the independant audio channels. Since I have more than one audio channel, wouldn't I have to use -map at some point with teemux to tell
[22:35:48 CET] <furq> so in this case if the rtmp connection drops then it'll stop writing to disk
[22:35:49 CET] <Keshl> it to preserve all the channels locally, but only send one over the network?
[22:35:51 CET] <JEEB> it has an option for that at least
[22:36:05 CET] <JEEB> either it keeps on with the left-around outputs
[22:36:07 CET] <JEEB> or it all dies
[22:36:15 CET] <furq> oh ok
[22:36:35 CET] <furq> it won't attempt to reconnect to rtmp though which i assume OBS will
[22:36:52 CET] <Keshl> (OBS does reconnect and re-start encoders, yes. When I d -- Hey, it uses teemux!)
[22:37:11 CET] <furq> i don't think you'll need -map if you use tee directly
[22:37:14 CET] <Keshl> (I was just about to type "When I drop connection, the disk recording stops too, until things are reconnected and stuff.")
[22:37:29 CET] <furq> the select= stuff in the tee outputs are doing the same job
[22:37:50 CET] <furq> select=a selects all audio streams for that output, but select=a:3 only selects the fourth stream
[22:39:00 CET] <Keshl> Okay, I think this only leaves one question, and this'll be the nail in the coffin if you guys say yes.
[22:39:22 CET] <Keshl> Suppose that I actually am using teemux and stuff, and the audio streams are correctly sent to where they're supposed to go, and everything's happy.
[22:41:29 CET] <Keshl> This logically means that, when I tell OBS to limit it's self to 4,500 bps, it's /somehow/ telling that to ffmpeg. As far as I know, you have to specify the audio and the video bitrate seporately, with -b:a and -b:v. Suppose it does that, with -b:a 320 and -b:v 4180 (To account for the audio's rate). Obviously this works fine for one audio channel, but what happens when I have four? Does ffmpeg figure out what's going on and lower the
[22:41:31 CET] <Keshl> video's bitrate to compensate for the increased audio streams?
[22:41:56 CET] <furq> it doesn't figure anything out
[22:42:01 CET] <furq> it just passes the bitrates you provide to the encoder
[22:42:03 CET] <JEEB> the bit rates match what you set them for
[22:42:11 CET] <JEEB> -b:a is "bit rate, (all) audio"
[22:42:16 CET] <JEEB> so each audio encoder gets that bit rate
[22:42:18 CET] <Keshl> Dangit. I mean, that's great, I prefer that, but dangit, this means now I have to go ask the OPBS guys what the heck they're doing. XD
[22:42:20 CET] <Keshl> *OBS
[22:42:32 CET] <JEEB> if they're doing FLV then...
[22:42:36 CET] <JEEB> they have a single audio track?
[22:42:44 CET] <JEEB> but generally speaking they just set AVCodecContext.bit_rate
[22:42:49 CET] <furq> i've seen smart people recommending obs, so something about this doesn't seem right
[22:42:52 CET] <JEEB> or whatever is the least retarded rate control mode for an encoder
[22:42:54 CET] <furq> because this sounds pretty amateur hour
[22:43:04 CET] <JEEB> OBS worked for me "OK" when I tested nvidia lossless output
[22:43:13 CET] <Keshl> Oh, OBS is great, in my opinion. I'm just doing really weird stuff that almost no typical OBS user does, so I expect I might break something.
[22:43:18 CET] <furq> maybe
[22:43:46 CET] <JEEB> but then OBS seemed to be unable to write off that lossless video to my SSD well enough
[22:43:55 CET] <JEEB> so when I stopped recording it would just flush its buffers for quite a while
[22:44:00 CET] <Keshl> Oh my gosh. Yeah. I have no idea why, but thank you for telling me it's not just me.
[22:44:47 CET] <Keshl> I have no idea why, but a few years ago I was trying to record a video just to disk (No network stuff), and whenever I wrote to a hard drive, nothing weird happened. SSD, constant massive frame drops for no conceivable reason, despite the obviously increased bandwidth. I was recording losslessely, so I thought for sure the HDD would be causing that, not the SSD.
[22:45:36 CET] <Keshl> I still have the originals if you guys get curious or anything, but considering they're lossless 1080p at 60 FPS, they're, er, huge.
[22:47:12 CET] <JEEB> my short test http://up-cat.net/p/a864aa70
[22:47:15 CET] <Keshl> https://www.youtube.com/watch?v=A7Njjy3Twhs if you wanna see the general output on YouTube. Again, recorded losslessely, but for some reason it only bugs out whenever there's a "complicated" series of frames that would be hard to encode with anything else.
[22:47:28 CET] <Keshl> (I know this won't suffice for actual debugging, but still.)
[22:47:28 CET] <JEEB> (I still find it funny that nvidia can encode this, but not decode)
[22:50:48 CET] <Keshl> 2:38 in my video, great example of things going progressively wrong as the complexity increases. (Sorry for slowness, was looking for that.)
[22:51:20 CET] <Keshl> JEEB: ...Is that one gigabit per second?
[22:52:06 CET] <JEEB> 2 897 564 060 bytes for 23.47 seconds
[22:52:37 CET] <furq> that looks about right for lossless 4k
[22:52:57 CET] <furq> does nvdec not support 4:4:4 at all
[22:53:05 CET] <JEEB> seemingly not
[22:53:12 CET] <furq> that's pretty lame
[22:55:19 CET] <Keshl> JEEB: That's.. that's a big number.
[22:56:55 CET] <Keshl> ...Curiousity. I'm aware of what things like "4:4:4" refer to, but when you have an actual "4:4:4" metric, why don't you just call it "1:1:1"? Or "1::"? Isn't it just a ratio?
[22:57:51 CET] <furq> https://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios
[22:58:01 CET] <furq> i couldn't tell you why that system was chosen
[22:58:05 CET] <furq> i assume it's just convention
[22:58:10 CET] <JEEB> it's a convention, yea
[22:58:25 CET] <JEEB> I have the book circles of confusion - might explain it
[22:59:03 CET] <furq> To calculate required bandwidth factor relative to 4:4:4 (or 4:4:4:4), one needs to sum all the factors and divide the result by 12 (or 16, if alpha is present).
[22:59:10 CET] <furq> i didn't actually realise that
[22:59:18 CET] <furq> i guess that's a useful property you might not get otherwise
[23:00:46 CET] <Keshl> ...This is thr most helpful diagram I've seen in a while. o_o
[00:00:00 CET] --- Fri Dec 14 2018