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

[burek]

[00:11:59 CET] <kierank> atomnuker: why do you think it is ffmpeg
[00:21:13 CET] <nevcairiel> also, it doesnt mention vp9 anywhere on there
[00:21:19 CET] <nevcairiel> or opus for that matter
[00:22:29 CET] <kierank> doesnt install here
[01:28:11 CET] <tmm1> jkqxz: any ideas about this error mateo` ran into: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221692.html
[01:30:36 CET] <jkqxz> That's the missing device type which you've already fixed.
[01:31:01 CET] <JEEB> :)
[01:38:51 CET] <tmm1> hah
[01:41:48 CET] <cone-036> ffmpeg 03sfan5 07master:d3a2100c67a0: fate/hevc: add skip_loop_filter test
[01:41:49 CET] <cone-036> ffmpeg 03Michael Niedermayer 07master:c8bd2c7d09bf: tests/fate/mov: Fix fate-mov-invalid-elst-entry-count failure on ARM
[01:51:48 CET] <tmm1> mateo`: can you try changing mediacodec_hw_configs .device_type and see it works?
[01:52:43 CET] <tmm1> if you want to amend the docs as you suggested and push the commits, feel free
[04:01:32 CET] <atomnuker> kierank: https://blogs.windows.com/msedgedev/2017/12/05/introducing-web-media-extension-package-ogg-vorbis-theora-support/#KIdDVQjCmq1sG7HW.97
[04:02:32 CET] <kierank> Oh nice
[04:07:50 CET] <wm4> I wonder if they can play ogg theora correctly (unlike ffmpeg)
[06:15:31 CET] <TD-Linux> wm4, what are you referring to? the zero length packet?
[06:15:36 CET] <TD-Linux> (still updating my vm to test)
[06:15:44 CET] <TD-Linux> wm4, note that it uses ffmpeg
[06:16:22 CET] <TD-Linux> https://github.com/Microsoft/FFmpegInterop
[06:16:51 CET] <wm4> fucked up timestamps
[06:18:04 CET] <TD-Linux> oh, it does granulepos wrong?
[06:18:40 CET] <wm4> no idea, never cared about it
[06:18:58 CET] <wm4> rmuxing to mkv with mkvmerge makes such files playable
[06:19:16 CET] <TD-Linux> you haven't described the problem enough for me to have a hope of reproducing it
[06:20:09 CET] <wm4> actually wait, maybe it was ogm
[06:20:18 CET] <wm4> which is apparently completely different
[06:20:31 CET] <TD-Linux> yeah, ogm is a hack to put vfw into ogg
[06:21:54 CET] <wm4> can't find a sample file anyway
[06:23:14 CET] <TD-Linux> katawa shoujo has some
[06:24:00 CET] <TD-Linux> (that said, I don't really care about ogm either)
[10:39:51 CET] <fx159159> Is my assumption correct that when I have a YUV picture where U and V are interleaved and U starts at 0xcc8e0001 and V at 0xcc8e0000 that the format is actually NV21?
[10:55:18 CET] <nevcairiel> sounds like it
[10:59:44 CET] <fx159159> nevcairiel: Weird.. I have to set the opposite (NV12) on my AVStream, otherwise the colors are swapped
[11:04:20 CET] <wm4> I think ffmpeg's plane order conventions are swapped relative to other systems
[11:04:35 CET] <wm4> you see the same with 3 plane 4:2:0 yuv
[11:12:12 CET] <fx159159> Swapped relative to what? So ffmpeg's NV12 is actually NV21 in other definitions?
[11:15:25 CET] <wm4> no idea, just saying that it might be possible that it's a confusion of conventions
[11:22:26 CET] <nevcairiel> NV12 is NV12
[11:22:39 CET] <nevcairiel> the only confusion is that people assume that yuv420p == YV12
[11:22:52 CET] <nevcairiel> but yuv420p is I420 if you want to stay with FourCCs
[11:23:01 CET] <nevcairiel> YV12 is I420 with swapped chroma planes
[11:25:45 CET] <wm4> I mean, if you use libswscale or something to convert a 3 plane format to nv12, the confusion could still occur
[11:26:04 CET] <fx159159> Well... could it be that Android actually fucks up again and swaps U and V planes? 
[11:26:28 CET] <nevcairiel> from the same reason tho, that people assume yuv420p = YV12. YV12 is really the only common "FourCC" format which is swapped
[11:26:43 CET] <nevcairiel> all others have U first
[11:26:53 CET] <nevcairiel> including NV12
[11:27:23 CET] <nevcairiel> if  Android doesnt even call it NV12, they can do whatever, I guess?
[11:27:30 CET] <fx159159> https://developer.android.com/ndk/reference/group___media.html#gga9c3dace30485a0f28163a882a5d65a19aea9797f9b5db5d26a2055a43d8491890
[11:27:50 CET] <nevcairiel> their definition is so broad that it might as well be NV21
[11:27:53 CET] <fx159159> They call it YUV_420_888 with a pixel stride of 2 ;-)
[11:28:11 CET] <nevcairiel> it could be I420, YV12, NV12, NV21 .. all in one name with added properties
[11:28:41 CET] <fx159159> I relied on their order of the planes but then U and V are probably swapped
[11:30:28 CET] <wm4> what a surprise that mediacodec doesn't even get this right, sigh
[11:31:45 CET] <nevcairiel> well, they have a generic description, its not inherently "wrong"
[11:32:28 CET] <nevcairiel> its just uncommon
[11:42:23 CET] <jdarnley> I would agrue that it is wrong to make people think that there is junk between each U and each V sample with their silly "pixel stride" value.
[11:42:48 CET] <jdarnley> But perhaps I am just too used to stride being used for alignment and padding for SIMD.
[11:43:27 CET] <BtbN> There can be anything in the "empty space" between the width and the linesize
[11:46:41 CET] <jdarnley> True, you need to read some docs to discover whether you can write to it or not.
[11:47:19 CET] <BtbN> It usually exists because certain instructions do write to it, so they do not write over the next line
[11:49:12 CET] <atomnuker> jdarnley: have you heard of v210a?
[11:49:20 CET] <jdarnley> I have not
[11:49:44 CET] <atomnuker> there's some v210 out there with an alpha channel in the 2 bits of padding
[11:50:48 CET] <jdarnley> Oh, not as bad as I expected.
[11:50:50 CET] <jdarnley> I am lead to believe the those two bits must be zero otherwise.
[11:51:01 CET] <jdarnley> So you can't put junk there anyway.
[11:53:36 CET] <nevcairiel> I only know Y410 wich packs 2-bit alpha with 3x10bit pixel into one, i've always wondered if 2-bit alpha are really worth having
[11:54:20 CET] <nevcairiel> 0/25/75/100 arent exactly that high granularity for alpha
[11:55:31 CET] <wm4> probably good enough if you need only binary transparency, and the other bit is a free extra so they included it
[11:55:35 CET] <jdarnley> y410 huh?  Based on the previous discussion is that v210 with swapped chroma? :)
[11:55:44 CET] <nevcairiel> no, its 4:4:4
[11:55:54 CET] <jdarnley> ah
[11:56:27 CET] <jdarnley> Are you sure it isn't 4:1:0 :)
[11:57:02 CET] <nevcairiel> yes, the 10 indicates bitdepth, there is also a Y416 which is 64bpp and includes full 16-bit alpha
[11:57:56 CET] <rcombs> MediaCodec used to have a bunch of different IDs for different ways to encode YUV 4:2:0
[11:58:28 CET] <rcombs> they deprecated them all and replaced them with one "flexible" ID meant to represent any 8-bit YUV 4:2:0, with an additional struct describing the plane layout
[11:58:37 CET] <rcombs> (said struct is not available via the C API)
[11:58:47 CET] <rcombs> thanks, android
[11:58:49 CET] <rcombs> thandroid
[11:59:51 CET] <nevcairiel> I dont know if microsoft really defined those formats, but its their recommended YUV formats following a fixed structure .. P or Y for planar or packed (no idea why Y for packed, but hey), 0/2/4 for the chroma variants (4:2:0, 4:2:2, 4:4:4), and followed by the bitdepth (10/16) .. so that makes  P010, P016, P210, P216, Y210, Y216, Y410, Y416 (for some reason they dont like planar 4:4:4)
[15:01:00 CET] <thardin> I want to insert a bunch of stuff in a binary file. anyone know a good editor for that? mostly copy-pasting bytes. but I do need insert functionality, not replace
[15:02:34 CET] <sfan5> any hex editor?
[15:02:48 CET] <sfan5> i mostly use ghex / bless if I need to do this
[15:03:07 CET] <thardin> I'm used to vbindiff, which only does replace
[15:03:17 CET] <JEEB> vbindiff is good for binary diffs, yea
[15:03:30 CET] <JEEB> but yes, bless I think I've used on *nix and hxd on windows
[15:03:50 CET] <thardin> better yet, is there a binary template editor?
[15:04:05 CET] <thardin> like 010
[15:04:12 CET] <JEEB> ah
[15:04:31 CET] <thardin> it would be nice if length fields and alignment pads were recomputed automagically
[15:04:45 CET] <JEEB> I think hexamonkey had some templates for file types
[15:04:53 CET] <JEEB> but I don't know if it works for modifications
[15:05:20 CET] <thardin> neat
[15:05:47 CET] <thardin> 010 is pretty crazy. you can edit DEFLATEd data for example
[15:05:50 CET] <JEEB> yea
[15:05:58 CET] <JEEB> 010 I've thought of getting every now and then
[15:11:18 CET] <thardin> I think I'll modify the code I'm looking at and pretend it's getting a bad file for now
[15:15:45 CET] <thardin> getting ffprobe to choke, woo!
[15:18:08 CET] <JEEB> :)
[15:19:10 CET] <thardin> I can construct a file that makes ffprobe spec 1 ms parsing every 4 specially crafted bytes on an i7
[15:19:17 CET] <thardin> spend not spec
[15:20:36 CET] <thardin> will have to write a patch for it
[15:20:52 CET] <thardin> and check some other libs for similar issues
[16:00:26 CET] <thardin> is there a way to get overcommit to play nice with av_calloc?
[16:01:04 CET] <thardin> if I allocate a rather hefty chunk of memory but only use it very sparsely but still want it filled with zeroes
[16:01:50 CET] <cone-040> ffmpeg 03Paul B Mahol 07master:53855e3c040a: avfilter: add setrange filter
[16:06:49 CET] <thardin> seems linux might actually do what one expects, but av_calloc spoils it
[16:07:29 CET] <BtbN> How would you zero initialize memory that's not allocated?
[16:07:37 CET] <BtbN> calloc is alloc + zero-fill after all
[16:09:23 CET] <thardin> I wouldn't, the kernel would
[16:09:28 CET] <thardin> on page fault
[16:09:32 CET] <DHE> I think your only other option is to mmap /dev/zero, but that's not av_free*() friendly
[16:10:04 CET] <iive> isn't that what glibc does for calloc?
[16:10:06 CET] <thardin> we had a similar discussion in the local HPC group. don't bother with packed matrix formats, just allocate as much space as a full matrix would use
[16:10:37 CET] <thardin> you can allocate 1000,000x100,0000 no problem
[16:12:55 CET] <BtbN> How would the kernel know to zero-allocate the new memory?
[16:13:15 CET] <thardin> that's the question
[16:14:50 CET] <BtbN> https://github.com/bminor/glibc/blob/master/malloc/malloc.c#L3360 it's definitely a complex one
[16:16:45 CET] <BtbN> But even that ultimately just doe memset(d, 0, clearsize);
[16:16:49 CET] <BtbN> *does
[16:16:51 CET] <thardin> probably possible is going to be my guess. not going to worry about it since it's only a matter of half a meg in this case
[16:19:47 CET] <thardin> the code I'm looking to replace might allocate up to 1 MiB anyway
[16:24:39 CET] <iive> BtbN: the actual question is, why a kernel would allocate anything bug zeros?
[16:24:46 CET] <iive> bug/but
[16:24:53 CET] <BtbN> Because it's faster.
[16:25:05 CET] <iive> and may leak confidential data
[16:25:16 CET] <jkqxz> Yeah, anonymous mmap() always gives you zero pages.
[16:25:38 CET] <jkqxz> Or, more accurately, anonymous mmap() always gives you the zero page (possible lots of times).
[16:26:12 CET] <jkqxz> It's then CoW, so calloc() filling with zeroes will force the copy even though it isn't changing anything.
[17:56:51 CET] <durandal_1707> if i insert scale filter to convert from limited to full range yuvj test passes
[17:58:10 CET] <durandal_1707> thing is the scale filter should be already autoinserted anyway
[18:07:09 CET] <funman> __av500__: is http://www.tp-link.fr/products/details/cat-18_TL-PA4010P.html any good ?
[18:37:23 CET] <cone-040> ffmpeg 03Nikolas Bowe 07master:5a412a5c3cc2: avcodec/extract_extradata_bsf: Fix leak discovered via fuzzing
[20:49:00 CET] <cone-040> ffmpeg 03James Almer 07master:d6d605eb05c3: avformat/mux: stop delaying writing the header
[21:20:35 CET] <SortaCore> best way to retain a AVFrame for later sws_scale?
[21:20:43 CET] <SortaCore> is it av_frame_clone or av_frame_ref?
[21:22:27 CET] <JEEB> the doc tells you if you look at both of then https://ffmpeg.org/doxygen/trunk/group__lavu__frame.html#ga46d6d32f6482a3e9c19203db5877105b
[21:22:32 CET] <JEEB> *them
[21:23:01 CET] <JEEB> with ref you need to have another AVFrame already created, if you don't want to be calling that all the time, then clone handles that for you
[21:23:12 CET] <JEEB> (or if you want to share an AVFrame instead of creating a new one)
[21:31:27 CET] <SortaCore> hmm, I'm doing a while loop and pulling avframes until it can't get any, I want to keep the old... one...
[21:31:36 CET] <SortaCore> why'd they all quit
[21:32:00 CET] <SortaCore> s/old/first
[21:32:13 CET] <JEEB> the docs tell you exactly what those functions do, thankfully :P
[21:32:18 CET] <JEEB> also this is #ffmpeg stuff
[21:32:32 CET] <SortaCore> yea, but whenever I ask there, people think I want commandline >.>
[22:09:50 CET] <cone-040> ffmpeg 03Michael Niedermayer 07master:5e9a13a5a33b: avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97*
[22:09:51 CET] <cone-040> ffmpeg 03Michael Niedermayer 07master:610dd74502a5: avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED()
[23:02:50 CET] <cone-040> ffmpeg 03Gyan Doshi 07master:dc7d5f9f1904: avcodec/libx265 - Add named option to set profile
[23:16:01 CET] <gander83> Using the ffmpeg loudnorm filter; having a hard time flushing it.  I have tried avfilter_graph_request_oldest - but am getting only some of the buffered samples.  Any ideas
[23:27:25 CET] <SortaCore> send null stuff
[23:43:15 CET] <tmm1> i'm trying to figure out why ffprobe reports field_order as interlaced on 720p mpeg2video
[23:45:00 CET] <nevcairiel> the global field_order field isnt very reliable if the container doesnt provide it
[23:54:56 CET] <tmm1> looks like an easy fix for the mpeg2 case
[00:00:00 CET] --- Thu Dec  7 2017