[03:03:00 CET] <Kadigan> So um, yuv422p10le is deprecated? Can the error say in favor of -what- it's deprecated? [03:11:36 CET] <furq> i don't think it is deprecated [03:11:51 CET] <furq> afaik you should only get that warning if you're using yuvj pixel formats [03:21:01 CET] <Kadigan> Unless I'm not understanding the warning I'm getting, I'm getting it for yuv420p10le, yuv422p10le and yuv444p10le. [03:21:37 CET] <furq> is the source pixel format yuvj [03:21:49 CET] <Kadigan> Yes, it is yuvj444p (JPEG files). [03:22:27 CET] <furq> that's probably it then [03:22:38 CET] <furq> it throws the same warning either way [03:22:46 CET] <Kadigan> So what... it's having a problem with the -input- format? (which I have no control over at this stage?) [03:23:00 CET] <furq> it's not having a problem with it, it's just a generic error to let you know that yuvj is deprecated and might be removed [03:23:14 CET] <Kadigan> So ffmpeg will no longer support reading JPEG input? [03:23:25 CET] <furq> i doubt it [03:23:55 CET] <Kadigan> Your answer is a bit ambiguous. [03:24:03 CET] <furq> well i'm not a dev so idk what the plans are [03:24:31 CET] <Kadigan> But was that a "doubt it will be removed" or "doubt it will continue to" [03:24:33 CET] <furq> i'm just looking at the source for that error message [03:24:49 CET] <furq> it's unlikely that they'll remove support for reading jpegs [03:25:04 CET] <furq> because that would be a crazy thing to do [03:25:05 CET] <Kadigan> Then I'm not sure who that message (in these circumstances) is for. [03:25:21 CET] <furq> yeah it's news to me that it throws that warning for inputs [03:25:48 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libswscale/utils.c#L1192-L1196 [03:25:51 CET] <furq> there it is though [03:26:24 CET] <Kadigan> Also, "ffmpeg.pastebin.com" doesn't seem to work. [03:26:41 CET] <furq> any pastebin is fine [03:28:16 CET] <Kadigan> https://pastebin.com/KuKr5Xff is the command (and current output). You can see the error at line 37. -- Maybe I did set something incorrectly? [03:28:50 CET] <Kadigan> (I should probably fix the newlines) [03:30:52 CET] <furq> my understanding is that ffmpeg no longer uses the yuvj* formats internally, so if it encounters it then it just changes it to the equivalent yuv* format and then sets the range flag to full range [03:31:00 CET] <furq> the warning is pretty much just to let you know that this has happened [03:31:16 CET] <Kadigan> What implications does this conversion have? [03:31:22 CET] <furq> nothing [03:31:34 CET] <Kadigan> I see. [03:31:46 CET] <furq> it's not even a conversion, they're both the same format but one is limited range (16-235) and one is full range (0-255) [03:32:01 CET] <furq> i think the yuvj* stuff is the old ffmpeg way of indicating that [03:32:20 CET] <furq> but someone didn't like it so now it's all the same format with the range flag set separately [03:32:20 CET] <Kadigan> The message is confusing. Perhaps adding a "Detected a yuvj* pixel format - internally converting to a corresponding yuv* format." in front of it would help... [03:32:25 CET] <furq> yeah maybe [03:32:40 CET] <furq> the warning makes sense for outputs because that might stop working at some point [03:33:00 CET] <furq> but it's not like mjpeg support is ever going to be dropped [03:33:27 CET] <furq> it also makes sense for outputs because generally you've actually done something in that case [03:33:44 CET] <Kadigan> Also, weird... why would JPEG be using a Rec. 601 format... [03:35:38 CET] <Kadigan> ... wow. JPEG -does- use Rec. 601 [03:36:00 CET] <furq> it's a digital display format that uses yuv so i suppose it might as well [03:36:17 CET] <Kadigan> Okay, so nvm on the "weird", it's right there in the JPEG spec. 1.02 from 1992 [07:10:12 CET] <brimestone> Hey guys, is there a guide on how to use FFmpeg/FFplay on Swift4.2/xCode macOS projects? [17:44:42 CET] <Mavrik> Hmm, so apparently Dolby Atmos has been retrofitted into DD+ / DD TrueHD. Anyone has a good description on how the encoding works? [17:45:47 CET] <JEEB> not that I know. also dolby atmos is another of dolby's sales words [17:45:57 CET] <JEEB> so it probably means completely different things between different places [17:46:17 CET] <JEEB> just like dolby vision is everything from the dynamic metadata to ICtCp-like colorspaces [17:46:32 CET] <Mavrik> Yeah, I mean here the part where audio is encoded with spatial data [17:46:52 CET] <Mavrik> Instead of having a prebuilt surround mix. [17:47:31 CET] <JEEB> generally I've only seen hardware and people wanting to have their LEDs be enabled when bit streaming [17:47:53 CET] <JEEB> not sure if there are swdecs like there are for AC-4 (lol) [17:48:33 CET] <JEEB> but yea, if you find the spec it might be possible to poke at :P (or reverse engineer if a swdec is found) [17:49:03 CET] <Mavrik> Mhm, looking for it but it seems like there's bunch of marketing materials and nothing else. I guess you have to pay Dolby to get the spec :P [17:49:26 CET] <JEEB> yea, generally they only release specs when they want it into broadcast [17:49:33 CET] <JEEB> like AC-3, AC-4 and relative things [17:49:48 CET] <JEEB> ATSC/DVB/EBU etc [17:49:57 CET] <JEEB> ETSI I think one of the places was [17:52:08 CET] <JEEB> you could check if the "atmos" packets just happen to match https://www.etsi.org/deliver/etsi_ts/103100_103199/103190/01.01.01_60/ts_103... or so [17:52:46 CET] <JEEB> so far nobody's thankfully asked or implemented AC-4 because literally no-one is using it [20:38:13 CET] <deltasquared> hmm, having performance issues doing some encoding... but I've noticed ffmpeg giving me an swscaler warning about data alignment. why would there be an auto-injected swscaler in there and can I tell ffmpeg not to do that? [20:38:37 CET] <deltasquared> I'm trying to encode to mp4 using x11grab. logs can be provided if needed [20:38:52 CET] <JEEB> yes, swscale is getting inserted somewhere if that's happening [20:39:11 CET] <deltasquared> invocation is... hold on [20:39:24 CET] <JEEB> lavfi filter chain API has an option to disable implicit additions of format/swscale [20:39:30 CET] <JEEB> not sure if you can set it through ffmpeg.c [20:39:48 CET] <JEEB> (just like lavfi does have a function to graph your generated filter chain but I don't think it's in ffmpeg.c) [20:40:00 CET] <deltasquared> ffmpeg -f x11grab -framerate 30 -video_size 1366x768 -i :1.0 -vcodec libx264 -preset ultrafast -tune zerolatency -threads 4 test.mp4 [20:40:16 CET] <deltasquared> I'm not entirely sure the tune is helping, but it's description seemed like it would [20:42:08 CET] <deltasquared> it keeps up fine while doing things like scrolling in a terminal, but even running a fairly lightweight game, e.g. minetest, causes the output to become chopfest [20:42:23 CET] <Mavrik> swscaler ends up in there probably because you need RGB -> YUV conversion on the way [20:42:46 CET] <deltasquared> Mavrik: I tried libx264_rgb though, that was actually sligtly worse in performance [20:42:53 CET] <deltasquared> erm, minus the underscore [20:43:02 CET] <Mavrik> Yeah, RGB isn't optimized at all since pretty much nothing uses it. [20:43:19 CET] <deltasquared> I wouldn't have thought getting a lossless intermediate rgb format would have been so hard... [20:43:20 CET] <Mavrik> I'd suggest dumping the file to disk with some kind of fast lossless encoding and then reencoding offline. [20:43:22 CET] <JEEB> well, not like it's *not* optimized, but there's more data to begin with (4:4:4 as opposed to 4:2:0) [20:44:00 CET] <deltasquared> Mavrik: and libx264 with ultrafast *isn't* a fast encoding? I have no other ideas... [20:44:15 CET] <JEEB> zerolatency actually slows encoding down FYI [20:44:23 CET] <JEEB> since it prefers latency to speed [20:44:25 CET] <JEEB> :P [20:44:26 CET] <deltasquared> hell I was frame dumping to individual pngs at one point just to see if that would be faster... [20:44:34 CET] <deltasquared> JEEB: I'll try taking it out [20:44:53 CET] <JEEB> although I have a hunch your actual bottleneck is before x264? [20:45:05 CET] <JEEB> and/or your machine is quite slow or already loaded due to the game or so :P [20:45:28 CET] <Mavrik> I usually took huffyuv for those cases [20:45:44 CET] <Mavrik> Not sure if there's anything better for "let's dump this to disk asap" use-case :) [20:45:47 CET] <JEEB> something that video editors like is Ut Video [20:45:49 CET] <deltasquared> why isn't there a huffrgb or something, surely less colour conversion would be better [20:45:59 CET] <JEEB> ffvhuff is the FFmpeg huffyuv [20:46:03 CET] <JEEB> (with more pix_fmts) [20:46:39 CET] <deltasquared> interesting... also daft question, is huffyuv a codec or is it also a container format, just wondering what container I should shove it into [20:46:49 CET] <JEEB> it's a codec [20:46:58 CET] <deltasquared> so... shove it in mkv? :P [20:47:03 CET] <deltasquared> always a safe bet it seems [20:47:12 CET] <JEEB> Ut Video or huffyuv or ffvhuff is generally stuck into AVI since vfw codecs were usually utilized to edit those [20:47:16 CET] <deltasquared> hell I'm not audio grabbing at the moment... [20:47:32 CET] <Mavrik> Yeah, ffvhuff in AVI seems something that would work. :) [20:47:40 CET] <deltasquared> JEEB: I'm not seeing ffvhuff listed in ffmpeg-codecs [20:47:56 CET] <deltasquared> distro is arch linux. I'll dump the build flags if need be [20:48:23 CET] <JEEB> http://up-cat.net/p/fcee509a [20:48:33 CET] <JEEB> my branch I just built [20:48:33 CET] <deltasquared> configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg [20:48:33 CET] <deltasquared> --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3 [20:48:37 CET] <JEEB> it]s internal, too [20:48:46 CET] <deltasquared> ... oops, watch the flood limit, my derp [20:49:04 CET] <JEEB> I think the only dependency is zlib -- if even that? [20:49:26 CET] <deltasquared> ah yes, it's here [20:49:43 CET] <deltasquared> so, -vcodec ffvhuff -pix_fmt rgb24? [20:50:09 CET] <deltasquared> assuming x11 is operating in 24-bit colour mode... [20:50:17 CET] <Mavrik> You probably won't need the pix_fmt since the default is to avoid conversion. [20:50:21 CET] <deltasquared> right. [20:51:48 CET] <deltasquared> ... yow that file size though... I'm going to need a bigger disk [20:52:37 CET] <JEEB> yea it's lossless and intra only and simple [20:52:55 CET] <deltasquared> does it at least try to do something with the frames themselves? [20:53:04 CET] <deltasquared> i.e. is it at least better than raw [20:53:08 CET] <Mavrik> Well, it's way better than RAW [20:53:17 CET] <JEEB> yes, it's zlib-like and has some simple left/median prediction [20:53:22 CET] <JEEB> nothng like modern encoders of course [20:53:41 CET] <deltasquared> 714MB in 30 seconds though... ouch [20:54:28 CET] <deltasquared> 25MB/s or thereabouts... but that is better than 90MB/s or thereabouts for raw though [20:54:41 CET] <deltasquared> it's also faster than one PNG per frame thus far :P [20:55:26 CET] <Mavrik> The other option is to of course use a HW encoder if you have one [20:55:46 CET] <deltasquared> Mavrik: I tried that. my quicksync encoder (ivy bridge mobile chip) produces trash colouring... [20:56:06 CET] <Mavrik> I'm guessing broken reds? [20:56:44 CET] <deltasquared> Mavrik: broken everything... including this weird seizure inducing flicker in 3D games, like the scenery was missing every other frame but the skybox was there... only in the recording though [20:56:54 CET] <deltasquared> I have no clue what was causing that [20:56:59 CET] <deltasquared> that was kmsgrab to boot [20:58:11 CET] <deltasquared> I could try using quicksync in x11 I guess, though there would be a hwupload penalty. [20:58:27 CET] <deltasquared> input via kmsgrab causes system lockups occasionally. [20:58:40 CET] <deltasquared> needless to say it has felt like rock and a hard place at times... [20:59:10 CET] Action: deltasquared does some disk space calculations [20:59:48 CET] <deltasquared> assuming a conservative 30MB/s, 10 minutes would rack up 18GB. it's a bit oof but not completely unworkable I guess [21:00:34 CET] <Mavrik> 4TB drives are not that expensive these days :) [21:00:41 CET] <deltasquared> I should try using simplescreenrecorder again if I'm going with ffvhuff. I tried that with libx264 before but it was pushing the encoding to make the deadline, so the output was utter trash [21:01:03 CET] <deltasquared> Mavrik: oh great, just when I thought I wouldn't need spinning rust in my laptop again :/ [21:01:25 CET] <deltasquared> then again I do have this optical bay spare :) [21:05:26 CET] <deltasquared> gah, sss has still managed to end up doing yuv conversion... [21:06:14 CET] <deltasquared> I wish ffmpeg had an opengl hook library shipped with it. I'd prefer to be able to take more direct control... SimpleScreenRecorder seems to assume too many things [21:06:31 CET] <JEEB> check out libplacebo [21:06:38 CET] <deltasquared> hmm? [21:06:39 CET] <JEEB> if you need GPU colorspace conversions or resizing [21:06:52 CET] <JEEB> you could just utilize that + the FFmpeg APIs [21:07:50 CET] <deltasquared> how would this lib do the opengl hooking though? doesn't seem to be for that based on the description... unless I'm looking at the wrong thing [21:08:58 CET] <JEEB> I was mostly pointing you towards the colorspace conversion and resizing stuff, not hooking [21:09:20 CET] <deltasquared> right. [21:10:46 CET] <deltasquared> JEEB: at the very least, of all the options I've tried thus far ffvhuff has managed to remain realtime. [21:11:54 CET] <deltasquared> I wonder if kmsgrab would knock it down further... but alas that never seems to play ball without a CPU-side format filter present [21:12:33 CET] <deltasquared> somewhat defeating the object of performance [21:12:57 CET] <JEEB> if you were getting unalignment messages then you'd have to look into if you can improve the alignment of your input pictures [21:13:03 CET] <JEEB> otherwise all the SIMD couldn't be utilized [21:13:20 CET] <deltasquared> JEEB: I guess the weird resolution didn't help [21:13:29 CET] <deltasquared> let me see what that looks like in binary powers, one sec [21:14:06 CET] <JEEB> well even with weird resolutions as long as the buffer is properly allocated you should be able to get alignment [21:14:27 CET] <JEEB> esp. since your line-to-line length doesn't have to be width [21:14:31 CET] <deltasquared> 1366x768x3 looks like it should be align-able to 512 bytes... [21:14:43 CET] <deltasquared> [user@hydrocarbon scratch]$ dc -e '1366 768 * 3 * 2 o p' [21:14:44 CET] <deltasquared> 1100000000011000000000 [21:14:55 CET] <JEEB> I'd check the module if it's allocating the images itself [21:15:01 CET] <JEEB> if it is, then it's simple [21:15:04 CET] <deltasquared> what, x11grab? [21:15:11 CET] <JEEB> or kmsgrab or something like that [21:15:19 CET] <deltasquared> x11grab is where I saw those messages [21:15:25 CET] <deltasquared> is there a function I'd look out for [21:15:38 CET] <deltasquared> also where's said sauce code in a hurry [21:15:53 CET] <Hello71> >dc [21:15:55 CET] <Hello71> pls [21:16:00 CET] <JEEB> libavdevice/xcbgrab.c: .name = "x11grab", [21:16:21 CET] <deltasquared> Hello71: haunting me on #archlinux-offtopic wasn't bad enough? :P [21:16:34 CET] <deltasquared> I *like* my RPN [21:16:35 CET] <JEEB> yea, seems like it just gets a buffer [21:16:47 CET] <deltasquared> oh, so from xcb or whatever? [21:16:49 CET] <JEEB> xcb_shm_attach [21:16:51 CET] <deltasquared> ah. [21:16:58 CET] <JEEB> and shmget before that [21:17:21 CET] <deltasquared> well surely that'd be 4k aligned...? [21:17:25 CET] <JEEB> and then data = shmat(id, NULL, 0); [21:17:39 CET] <JEEB> deltasquared: well buffer vs the actual image within that buffer and all other things [21:17:45 CET] Action: deltasquared hurriedly reads man pages [21:17:46 CET] <JEEB> you could add more logging there [21:18:05 CET] <deltasquared> you'll forgive me I'm not set up to rebuild all the things at this time :P [21:18:14 CET] <deltasquared> (also wouldn't that get fairly verbose at 30fps...) [21:18:21 CET] <JEEB> not really, I've done worse :P [21:18:33 CET] <deltasquared> something tells me I don't want to know [21:18:37 CET] <JEEB> (parsers logging multiple times before a single packet gets through) [21:19:17 CET] <deltasquared> JEEB: so if x11 was for some reason daft with alignment I'd run into that issue I guess [21:20:02 CET] <JEEB> yes [21:20:15 CET] Action: deltasquared decides to try seeing what ffvhuff does with just "hwdownload" from kmsgrab [21:22:27 CET] <deltasquared> invalid output format gray for hwframe download... hmm [21:22:42 CET] <deltasquared> I assume it's just saying gray because nothing else told it [21:23:38 CET] <deltasquared> man page > "may be necessary to insert an additional format filter" reeee [21:24:18 CET] <deltasquared> I've tried to use scale_vaapi to help me out here before as well but the same message seemingly appears if you have hwdownload as the last thing in the chain [21:25:51 CET] <deltasquared> using hwmap instead gives "failed to map frame: -38". I assume that's the warning I've seen in places about failure if the buffer isn't linearly mappable [21:27:14 CET] <deltasquared> JEEB: actually, a thought occurs, does the format filter actually necessarily do any work? or is it just there to idk hint that the previous stages should output in a certain format [21:27:27 CET] <deltasquared> because I certainly didn't order gray as a pixel format for instance [21:27:36 CET] <JEEB> it's a hint and doesn't necessarily make any conversions if not necessary [21:27:44 CET] <JEEB> a meta-filter in a way [21:28:57 CET] <deltasquared> right. trying hwdownload again, I've tried setting pix_fmt specifically to rgb24 after -vcodec and the error message changes to "invalid output format rgb24", so it at least gets the hint, but still doesn't seem to like it [21:41:20 CET] <deltasquared> sigh, I guess I'll just have to resign myself to sticking with x11grab for the time being. it is certainly more flexible at least. doesn't require root, for one. [21:42:56 CET] <deltasquared> not wise to be tinkering with video encodes when you've got a headache as it is heh [00:00:00 CET] --- Mon Jan 28 2019