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

[burek]

[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