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

[burek]

[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_103190v010101p.pdf 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 at 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