[01:12:21 CEST] <alexmarkley> i'm trying to control camera input parameters, such as framerate, resolution, and pixel format... examples show setting those options via av_set_dict() and passing the dictionary into avformat_open_input() [01:12:45 CEST] <alexmarkley> is this correct? it seems to have no effect for me [01:13:00 CEST] <alexmarkley> the input format is video4linux2 [01:13:46 CEST] <alexmarkley> also, av_dict_count() reports 0 after avformat_open_input() which i think means that it recognized all of the options [01:15:59 CEST] Action: kierank tries to figure out how frame properties are obtained in threaded h264 [01:32:12 CEST] <jamrial> "uncut console output pls (2)" [01:38:07 CEST] <alexmarkley> if somebody could even point me to the relevant documentation that would be helpful [01:39:14 CEST] <alexmarkley> i'm having a lot of trouble following ffplay.c to see how it handles, (eg.) video_size [01:53:32 CEST] <jamrial> alexmarkley: documentation is in https://ffmpeg.org/documentation.html, but it may be lacking [01:53:45 CEST] <jamrial> and api usage questions go in #ffmpeg, not here [01:53:57 CEST] <alexmarkley> oh my bad, i misread the topic [01:54:06 CEST] <alexmarkley> thanks for the pointer [05:41:33 CEST] <philipl> BtbN: My 2080ti arrived today. Supports HEVC 4444 decoding. [09:27:27 CEST] <nevcairiel> philipl: i read that it would, but did they actually add a chroma format for that to any of the APIs? [11:17:01 CEST] <BtbN> It probably works like all the other formats, and it just outputs NV12? [11:17:08 CEST] <BtbN> Pr P016 at best [11:21:55 CEST] <nevcairiel> so practically useless then [11:22:41 CEST] <nevcairiel> I understand why they support 444 encode, its for their streaming tools, but decode into subsampled chroma seems a bit weird [11:37:45 CEST] <atomnuker> true, considering doing the conversion and subsampling on the encoding side would be faster [13:05:11 CEST] <cone-826> ffmpeg 03Jun Zhao 07master:ab9349e664f1: lavfi/deshake: fix deshake crash issue. [13:18:00 CEST] Last message repeated 1 time(s). [13:40:00 CEST] Last message repeated 1 time(s). [13:40:07 CEST] <JEEB> > same commit thrice [13:40:27 CEST] <durandal_1707> wtf? [13:40:42 CEST] <JEEB> note the same hash too, so it could just be the bot [13:41:00 CEST] <durandal_1707> lets kick him? [13:41:19 CEST] <JEEB> and what would that help with? [13:41:25 CEST] <durandal_1707> dunno [13:41:31 CEST] <JEEB> exactly [13:46:28 CEST] <cone-826> ffmpeg 03Jun Zhao 07master:ab9349e664f1: lavfi/deshake: fix deshake crash issue. [13:48:18 CEST] <durandal_1707> see ^ [13:50:12 CEST] <durandal_1707> actually bot is ok, looks like commit cant go in [13:50:33 CEST] <JEEB> yea I don't see it in the repo [13:51:13 CEST] <durandal_1707> really, what is going on? [13:51:24 CEST] <nevcairiel> maybe a hook is refusing it, and instead of fixing it, he is just trying again and again =p [13:51:37 CEST] <durandal_1707> but bot should be silent.... [13:52:02 CEST] <JEEB> it's probably pre-hook or something [13:57:19 CEST] <jkqxz> There is something wrong, I think. Trying to push seems to hang at the point when the remote has been sent the change - I've been sitting there for several minutes. [13:57:34 CEST] <jkqxz> Maybe the bot message will appear when it times out, or something? [13:58:03 CEST] <durandal_1707> ugh, right, same happened to me [13:58:43 CEST] <durandal_1707> but my patches got in [14:05:58 CEST] <jkqxz> "remote: send-mail: Connection lost in middle of processing" "remote: Can't send mail: sendmail process failed with error code 1" [14:06:31 CEST] <JEEB> right, if it's the sendmail trigger at the end of the push? [14:06:43 CEST] <JEEB> for the ffmpeg-cvs or whatever the list was? [14:07:25 CEST] <jkqxz> It's still hung after giving that, too. [14:13:51 CEST] <cone-826> ffmpeg 03Mark Thompson 07master:6ff4473012bc: av1_metadata: Fix constraint on setting chroma_sample_position [14:14:20 CEST] <JEEB> that went through at least [14:15:29 CEST] <jkqxz> Taking ~20 minutes. [14:16:19 CEST] <JEEB> ouch [14:16:23 CEST] <JEEB> but at least not impossible [14:18:11 CEST] <jkqxz> Maybe it's two mail timeouts, each ten minutes? <https://0x0.st/sgH3.txt> [14:50:49 CEST] <JEEB> jkqxz: there was indeed an issue with e-mail and seems to be fixed now [15:30:58 CEST] <cone-826> ffmpeg 03Jun Zhao 07master:5a3ce4a92b84: lavfi/deshake: fix deshake crash issue. [16:00:59 CEST] <thardin> a friend tells me there's anime webms encoded with av1 in the wild. does that mean it's finally standardized or is some encoder jumping the gun? [16:03:07 CEST] <atomnuker> lol no, they're jumping the gun, no av1 in webm until google says so [16:04:17 CEST] <atomnuker> and even then, only webvtt subtitles [16:04:29 CEST] <JEEB> yea, everyone just thought av1 in matroska will be the thing picked by GOOG [16:04:41 CEST] <JEEB> except for now mp4 is the pick [16:05:14 CEST] <JEEB> so we might see av1 in mstroska, but whether GOOG puts the webm stamp on it is up in the air [16:08:52 CEST] <gnafu> Maybe it's just time for the "WebM" moniker to die. [16:12:02 CEST] <gnafu> Let "WebM" just mean "VPx", and then use AV1 in standard containers. [16:15:28 CEST] <thardin> that's what I suspected [16:16:01 CEST] <thardin> webm might be useful as it narrows down what an mkv file can be [16:22:48 CEST] <gnafu> But do we really want that anymore? I mean, sure it can be nice to know it "must" be using a free audio codec (and not someone putting AV1 and AAC into an MKV container), but I don't know we really need that distinction anymore. [16:24:02 CEST] <thardin> it might be helpful for that, yes. and for users, maybe [16:24:39 CEST] <thardin> but eventually you kind of get back to square one when old devices that can't be easily upgraded support "webm" but only say vp8 and vorbis, not av1 and opus [16:25:15 CEST] <thardin> you'd almost want it to be .web1 .web2 .web3 etc [16:25:29 CEST] <thardin> I dunno [16:28:56 CEST] <gnafu> Well, maybe .webm2. [16:29:30 CEST] <gnafu> Too many applications do weird things based solely on file extensions, though. [16:30:03 CEST] <thardin> I'm also reminded of mp4 ftyps [16:30:11 CEST] <gnafu> Honestly, I'm probably going to end up using AV1+Opus-in-MP4 :-P. [16:30:25 CEST] <gnafu> At the end of the day, nothing beats good ol' AVI. [16:30:38 CEST] <thardin> that's standardized? I recall mp4 being very picky [16:30:41 CEST] <thardin> mov on the other hand [16:31:20 CEST] <gnafu> thardin: I believe it is official now, yes. My understanding was that the final MKV spec for AV1 was waiting on the MP4 spec being finished, and I think both have happened now. [16:31:28 CEST] <gnafu> And Opus-in-MP4 is official. [16:32:40 CEST] <gnafu> Or maybe it hasn't reached "1.0": http://opus-codec.org/docs/opus_in_isobmff.html [16:33:15 CEST] <gnafu> But AV1 has: https://cdn.rawgit.com/AOMediaCodec/av1-isobmff/v1.0.0/index.html [16:35:28 CEST] <atomnuker> mp4 has no support for sane subtitles (and even then not exactly widespread for the insane ones) [16:36:17 CEST] <gnafu> And WebM is too restrictive, so I would expect people who care about subtitles to use Matroska. [16:39:20 CEST] <jamrial> google left the av1 in matroska definition to matroska people, and then they just used that for webm [16:40:16 CEST] <jamrial> which is a no brainer seeing the matroska spec was defined following the mp4 one [16:41:13 CEST] <jamrial> i think it's not finished-finished, but libaom was recently updated to be compliant with it [16:41:19 CEST] <jamrial> libwebm not so much [16:42:06 CEST] <durandal_1707> thardin: put them in jail! [16:53:10 CEST] <thardin> seven years! no trials! [16:58:46 CEST] <philipl> nevcairiel: Presumably until the next SDK update, there is no appropriate output format available. I did a brief attempt to see if it was undocumented but present but got errors back [16:59:22 CEST] <philipl> I tried asking it to output to P016 and it would decode but then the copy-out failed with errors implying the memory layout was mismatched. [16:59:43 CEST] <nevcairiel> but nv12 worked? [17:00:12 CEST] <philipl> I did not try. Perhaps I should. [17:03:09 CEST] <philipl> nv12 does seem to work (although I started with a 12bit 444 sample). [17:03:20 CEST] <philipl> At least it decodes and the initial copy works. [17:03:41 CEST] <philipl> The rest of the pipeline is currently reacting to the expected 444p12 format, but if I fixed that, I think it would display correctly [17:04:07 CEST] <philipl> So ok, it can downsample to nv12 but not to p016. [18:48:44 CEST] <philipl> nevcairiel: After more effort, there are undocumented 444 output formats and I can use them. Not sure what the layout is. [18:49:17 CEST] <philipl> This is where we again see nvidia using a YUV444P10 (or 12) format with the padding at the opposite end from what ffmpeg does. [18:49:32 CEST] <philipl> At least that's my suspicion [18:50:24 CEST] <atomnuker> yeah, it kinda sucked vulkan chose that format for most pixfmts [18:53:30 CEST] <atomnuker> which just made me notice VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 (p010) is also defined with padding in the LSBs so I have to remove yet another pixfmt from my hwcontext code [18:54:28 CEST] <philipl> yay... [18:54:45 CEST] <atomnuker> was the entire industry on paint tinners when they made this part of the spec? [18:55:42 CEST] <philipl> It's somehow better for the hardware? [18:57:12 CEST] <atomnuker> I think they do such shifts for free [19:06:29 CEST] <philipl> Hmm. So I'm also seeing the chroma planes seemingly misaligned. I'll probably be flailing around with this until they document the layout. [19:07:51 CEST] <atomnuker> misaligned chroma planes? I had issues with delayed chroma planes when I had the binary drivers with cuda [19:08:28 CEST] <philipl> Looks like the V plane is half a frame vertically misaligned. [19:08:31 CEST] <philipl> U plane looks correct. [19:09:03 CEST] <philipl> bingo. [19:09:10 CEST] <philipl> I did a manual offset adjustment and output looks correct. weird. [19:12:53 CEST] <philipl> I'm guessing there's something wrong in our copying code - we've not had 3 plane output from the decoder before. [19:48:24 CEST] <cone-793> ffmpeg 03Zhong Li 07master:21733b39d0af: lavu/qsv: fix a random hwupload failure regression [19:48:24 CEST] <cone-793> ffmpeg 03Mark Thompson 07master:1f1ec958f6c6: Merge commit '21733b39d0af5211d7b9f168ff3667ea86362e2b' [20:31:37 CEST] <cone-793> ffmpeg 03Paul B Mahol 07master:c98ffa086c5d: avfilter/avf_showspectrum: switch to activate and add fps option [00:00:00 CEST] --- Sun Oct 7 2018