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

[burek]

[00:00:24 CEST] <nevcairiel> should just work
[00:02:06 CEST] <durandal_1707> what about mkvmerge from mkvtoolnix?
[00:02:20 CEST] <nevcairiel> no idea.
[00:12:12 CEST] <durandal_1707> JEEB: what's so funny with ffmpeg having ocr filter?
[00:18:18 CEST] <JEEB> durandal_1707: not funny, I was actually thinking of making one myself if there wasn't one
[00:18:34 CEST] <JEEB> I just found myself not having noticed it :P
[00:20:52 CEST] <cone-624> ffmpeg 03Marton Balint 07master:60c9a2553041: ffmpeg: fallback to codecpar parameters on input filter eof
[00:20:53 CEST] <cone-624> ffmpeg 03Marton Balint 07master:0031eab61c82: ffmpeg: do not finish output streams manually on eof even if no input is provided
[00:20:54 CEST] <cone-624> ffmpeg 03Marton Balint 07master:084ef7d7d542: avfilter/af_pan: reject expressions referencing the same channel multiple times
[01:32:49 CEST] <cone-624> ffmpeg 03Michael Niedermayer 07master:5c75438b8935: avcodec/tableprint_vlc: Fix build failure with --enable-hardcoded-tables
[02:10:30 CEST] <jamrial> atomnuker: ping
[02:15:01 CEST] <mypopydev> @jkqxz
[02:15:16 CEST] <mypopydev> Hi, Mark
[02:16:36 CEST] <atomnuker> jamrial: pong?
[02:17:34 CEST] <jamrial> atomnuker: are the av1 profiles the same as vp9? as in, 0 for i420, 1 for i422, i440 and i444, 2 for 0 + high bitdepth, 3 for 1 + high bitdepth
[02:21:47 CEST] <atomnuker> jamrial: no, 0 supports 420 at 8 or 10 bits, 1 supports the same but with 444 (!) at 8 or 10 bits and 3 is supports all that + 12 bit support for that + 422 at 8, 10 or 12 bits + monochrom (at 8, 10 or 12 bits)
[02:22:11 CEST] <jamrial> 3 or 2 for the last?
[02:22:26 CEST] <atomnuker> 3
[02:22:37 CEST] <jamrial> no 2 then?
[02:23:00 CEST] <atomnuker> 2 supports 420 @ 8 or 10 and 444 @ 8 or 10
[02:23:32 CEST] <atomnuker> https://aomediacodec.github.io/av1-spec/av1-spec.pdf
[02:23:35 CEST] <nevcairiel> 1 is 444 exclusively, and 2 is 0+1? seems like a rather odd choice
[02:23:38 CEST] <atomnuker> annex a, page 590
[02:23:52 CEST] <atomnuker> oh damn and blast
[02:24:08 CEST] <atomnuker> was looking at the profile names
[02:24:25 CEST] <atomnuker> so 1 supports 420 @ 8 or 10 and 444 @ 8 or 10
[02:24:31 CEST] <atomnuker> 0 supports 420 @ 8 or 10
[02:24:36 CEST] <nevcairiel> they named the profiles now anyway
[02:24:46 CEST] <Chloe> Why do we have libpostproc?
[02:24:48 CEST] <nevcairiel> Main, High, Professional
[02:25:08 CEST] <atomnuker> 2 supports 420 @ 8 or 10 or 12 and 444 @ 8 or 10 or 12 and 422 @ 8 or 10 or 12 and GRAY8, GRAY10 and GRAY12
[02:25:26 CEST] <jamrial> mmh, should i remove the i440 references in the decoder wrapper, then?
[02:25:32 CEST] <jamrial> the enum values are there in libaom, though
[02:25:37 CEST] <nevcairiel> its not mentioned in the profiles anyway
[02:25:41 CEST] <nevcairiel> who would use 440 anyway
[02:25:48 CEST] <jamrial> *shrug*
[02:25:49 CEST] <atomnuker> yeah, I think we removed support for that
[02:25:55 CEST] <jamrial> alright
[02:26:20 CEST] <nevcairiel> i never understood why they never named the vp9 profiles, numbers are so uninspiring
[02:26:24 CEST] <nevcairiel> glad they gave it names for av1
[02:26:36 CEST] <atomnuker> camcoders supported that ages ago apparently, it was just a leftover from vp9 (and vp8 and vp6 and the whole on2 days of nothing)
[02:30:02 CEST] <cone-624> ffmpeg 03James Almer 07master:d039d7d4a4a5: avcodec/libaomdec: remove references to yuv440p pixfmt
[02:31:49 CEST] <atomnuker> jamrial: could you also change the name
[02:31:58 CEST] <atomnuker> I dislike what became of vpx
[02:32:02 CEST] <atomnuker> with libvpx-vp9
[02:32:18 CEST] <jamrial> well, libaom is supposed to be reused for av2, whenever that shows up
[02:32:35 CEST] <atomnuker> I guess, that would be the google way of doing it
[02:59:04 CEST] <jamrial> atomnuker: what about rgb? should i remove that as well and leave only yuv for now?
[03:00:47 CEST] <atomnuker> jamrial: looking at the draft, high and pro profiles support it for 444
[03:01:09 CEST] <jamrial> ok, will do the same as libvpxenc then
[03:01:27 CEST] <atomnuker> oh you're doing the encoder now?
[03:02:11 CEST] <jamrial> yeah, merging the wrapper from libav while also porting some of the changes we have in libvpxenc
[03:02:37 CEST] <jamrial> i did the same with the decoder wrapper, which is why the 440 stuff made it in
[03:18:57 CEST] <rcombs> remind me, is subsampling still worthwhile from a compression standpoint in AV1
[03:19:10 CEST] <rcombs> or is it just to save memory/bandwidth in raw video
[03:27:47 CEST] <TD-Linux> it is still worth it from a compression standpoint
[03:28:04 CEST] <TD-Linux> CfL reduced the need but did not eliminate it. also, the memory bandwidth savings remains very significant
[03:29:16 CEST] <TD-Linux> jamrial, 440 is actually not allowed at all in av1.
[03:29:46 CEST] <jamrial> TD-Linux: yeah, i already removed it from the decoder wrapper
[03:29:55 CEST] <TD-Linux> it still has RGB though.
[03:30:03 CEST] <jamrial> why did the enum values make it in, though?
[03:30:30 CEST] <jamrial> as in, they were not removed after the mass renaming to the new AOM_ namespace
[03:30:47 CEST] <TD-Linux> they probably shouldn't have. libaom isn't abi stable yet so we could still drop it
[03:31:18 CEST] <jamrial> that'd be nice, if anything to have less confusing headers :p
[03:31:34 CEST] <atomnuker> TD-Linux: with spatial domain cfl/general intra it's worth it
[03:32:21 CEST] <atomnuker> I'm still quite sure frequency domain intra can remove the need for it
[03:34:33 CEST] <TD-Linux> https://bugs.chromium.org/p/aomedia/issues/detail?id=1672
[03:35:29 CEST] <TD-Linux> jamrial, actually it rejects all RGB images too, though it shouldn't. then again RGB images are really the same as a 4:4:4 pixfmt
[03:36:02 CEST] <jamrial> well, right now it's also failing when i try to set AV1E_SET_COLOR_SPACE
[03:36:08 CEST] <jamrial> so it clearly needs some more work
[03:36:34 CEST] <TD-Linux> AV1E_SET_COLOR_SPACE doesn't exist in the current codebase
[03:38:07 CEST] <jamrial> i see it defined in aomcx.h
[03:38:16 CEST] <TD-Linux> yeah weird. I'm not sure what happened there
[03:38:51 CEST] <TD-Linux> so the color primaries / matrix / etc ones all work
[03:39:38 CEST] <jamrial> those are the new ones compared to vp9
[03:39:52 CEST] <jamrial> vp9 had color space and color range only
[03:41:13 CEST] <TD-Linux> https://bugs.chromium.org/p/aomedia/issues/detail?id=1673
[03:41:37 CEST] <TD-Linux> yeah. "color space" is no longer a syntax element, but described by the individual elements instead, so deleting the ctl is one way to fix it
[03:42:01 CEST] <jamrial> how is one supposed to set it now, then?
[03:42:47 CEST] <TD-Linux> SET_TRANSFER_CHARACTERISTICS, SET_MATRIX_COEFFICIENTS, SET_COLOR_PRIMARIES
[03:43:27 CEST] <jamrial> ah, i see
[03:43:42 CEST] <TD-Linux> I can remake the ctl and have it set all 3 at once if you like
[03:44:35 CEST] <jamrial> does this mean the aom_color_space_t enum is no longer valid as well?
[03:48:16 CEST] <TD-Linux> yes
[03:48:36 CEST] <TD-Linux> the patch changed at one point to switch to CICP color numbers and it seems that they didn't delete the old stuff
[03:49:27 CEST] <jamrial> ok
[03:49:54 CEST] <TD-Linux> would you find the ctl to set all useful? if not I'll just delete it and the aom_color_space_t enum
[03:53:12 CEST] <jamrial> nah, remove them
[03:54:28 CEST] <jamrial> the new stuff maps the enums in pixfmt.h better
[05:24:42 CEST] <cone-624> ffmpeg 03Luca Barbato 07master:43778a501f1b: Support AV1 encoding using libaom
[05:24:43 CEST] <cone-624> ffmpeg 03James Almer 07master:99cc3cf7a26c: Merge commit '43778a501f1bfbceeddc8eaeea2ea2b3506beeda'
[05:24:44 CEST] <cone-624> ffmpeg 03James Almer 07master:c0f0c9f53187: avcode/profiles: add AV1 profiles
[05:25:44 CEST] <jamrial> you're all welcome to fix all the stuff that's probably broken but i couldn't find on this thing :p
[05:40:25 CEST] <cone-624> ffmpeg 03James Almer 07master:88e9b616b94a: libavcodec/libaomdec: use the matrix coefficients value from aom_image
[05:52:22 CEST] <cone-624> ffmpeg 03James Almer 07master:416d354a576d: libavcodec/libaomenc: fix size specifier in an av_log call
[06:06:02 CEST] <cone-624> ffmpeg 03James Almer 07master:97de37da9c29: libavcodec/libaomdec: add support for transfer characteristics and color primaries
[06:06:03 CEST] <cone-624> ffmpeg 03James Almer 07master:e5819fa62930: libavcodec/libaomenc: add support for transfer characteristics and color primaries
[07:31:25 CEST] <rcombs> > image_copy_16_to_8
[07:31:27 CEST] <rcombs> looks fast
[07:35:25 CEST] <rcombs> and oh glad to see the "mastering display metadata" meme made it into AV1
[07:35:29 CEST] <rcombs> (TL note: no I'm not)
[10:50:49 CEST] <cone-075> ffmpeg 03Paul B Mahol 07master:ae9297097696: avcodec/eac3: add support for dependent stream
[10:50:50 CEST] <cone-075> ffmpeg 03Paul B Mahol 07master:2974b2556b2d: avcodec: add eac3_core bitstream filter
[10:50:51 CEST] <cone-075> ffmpeg 03Paul B Mahol 07master:ae1a8b06907e: doc/general.texi: fix warning
[11:56:38 CEST] <nevcairiel> rcombs: PQ and its metadata (ie. HDR10) is part of the video world now, a new modern codec not supporting it would be far sader then it existing in the first place
[11:57:20 CEST] <JEEB> yup
[14:18:32 CEST] <JEEB> michaelni: cheers. I was trying to run that test actually, but it couldn't generate lena for some reason
[14:18:52 CEST] <JEEB> (I got a zero-byte lena file basically)
[14:19:02 CEST] <JEEB> which of course failed to run the test
[14:20:03 CEST] <JEEB> I wouldn't be surprised if the changes are OK, though, since that code has been running with a few things for more than 24h now and visually the result seems OK
[14:23:49 CEST] Action: durandal_1707 still waiting for ATRAC9
[15:01:10 CEST] <JEEB> right, that test requires fate-samples even though it's not one of those that doesn't bug  you about it
[15:05:44 CEST] <atomnuker> durandal_1707: fine, I'll work on it today, waiting for a vulkan bugfix from mesa anyway
[15:06:13 CEST] <atomnuker> I can crash any intel gpu with a few lines of glsl
[15:06:47 CEST] <wm4> isn't that normal
[15:07:57 CEST] <atomnuker> no, never ever happened in all 6 years of using it
[15:08:32 CEST] <atomnuker> hmm, maybe 2, it did happen before they made it very stable some years ago
[15:11:06 CEST] <Compn> atomnuker : at least you cant brick it, yet :D
[15:32:11 CEST] <jdarnley> atomnuker: if you're not too busy would you mind looking at the following links and giving me some advice on how to handle the bottom of the planes?
[15:32:16 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commit/35615a5d8debab4c22657b206ae321bcc7e52e86#b69a4112d0f94fe626b923c19e9ac0b78a3e09ff_184_218
[15:32:27 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commit/35615a5d8debab4c22657b206ae321bcc7e52e86#b69a4112d0f94fe626b923c19e9ac0b78a3e09ff_256_378
[15:33:12 CEST] <jdarnley> Perhaps I should just add more conditions to the loops and ifs
[15:40:13 CEST] <atomnuker> no idea what's wrong with them, I can't really recognize them anymore
[15:40:22 CEST] <atomnuker> what's up with that progress stuff?
[15:42:39 CEST] <jdarnley> I need to know how many lines I have already processed.
[15:43:15 CEST] <jdarnley> It might be too verbose but I can clean it up later
[15:44:20 CEST] <jdarnley> I should probably reduce it to a single variable
[15:46:12 CEST] <atomnuker> oh, so you can know how many lines the next transform will take based on resolution?
[15:46:41 CEST] <jdarnley> Yeah
[16:12:29 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:95e47654bce3: lavfi/silencedetect: Add mono mode
[16:12:30 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:3deb17f9fb47: lavfi/silencedetect: Fix when silence_start=0
[16:12:31 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:cd4756a55819: lavfi/silencedetect: Update test parameters
[16:12:32 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:56b2731aae33: lavfi/silencedetect: Fix silence_start accuracy
[16:12:33 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:5170ab20e1f5: lavfi/silencedetect: Fix silence_end accuracy
[16:12:34 CEST] <cone-616> ffmpeg 03Nicolas Gaullier 07master:759381d96b22: lavfi/silencedetect: Fix missing log at eos
[17:45:50 CEST] <durandal_1707> should i write pcm-dvd encoder?
[17:51:27 CEST] <jamrial> sure, why not?
[17:53:04 CEST] <atomnuker> isn't that just big endian pcm 16?
[17:54:19 CEST] <nevcairiel> for 16 yes, 20/24 is a bit weird
[18:02:56 CEST] <atomnuker> oh, right, I have some of those here
[18:05:11 CEST] <jdarnley> Oh I am so very close now.
[18:05:22 CEST] <jdarnley> Just a subtle issue at the top of each plane.
[18:37:36 CEST] <durandal_1707> how hard is adding LBRR to native opus decoder?
[19:03:15 CEST] <atomnuker> pretty hard and messy
[19:03:47 CEST] <atomnuker> lbrr data in frame[n] encodes the data from frame[n-1] again
[19:04:18 CEST] <atomnuker> so you'll need to delay all output frames by 1
[19:04:34 CEST] <atomnuker> and then dealing with the fact that the frame size can change at any point
[19:04:52 CEST] <atomnuker> and the fact that the spec defines how those transitions should work
[19:05:15 CEST] <atomnuker> and the fact that the codec itself may change (and if it does so will the transitions and the delay period)
[19:05:21 CEST] <atomnuker> it would be pure masochism
[19:07:53 CEST] <atomnuker> I suspect this was added for lazy telecom companies who still use 120 year old telephone lines to send voice data
[19:08:44 CEST] <atomnuker> when the transmission theorem was dismissed as rubbish ("why would you deliberately put resistors and inductors on the wires")
[19:09:46 CEST] <atomnuker> and the fact it requires a delay of 1 whole frame pretty much undermines one of the goals of opus which is to have a low delay codec
[19:11:18 CEST] <atomnuker> can you actually generate a stream with llbr?
[20:49:57 CEST] <cone-616> ffmpeg 03Paul B Mahol 07master:a8a751ce9aaa: avformat/mpc8: do not return error on stream end
[21:20:11 CEST] <cone-616> ffmpeg 03James Almer 07master:25abaf3545f0: avcodec/libaomenc: minor cosmetics
[22:42:42 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:ea15915b2dc5: avcodec/wmalosslessdec: Fix null pointer dereference in decode_frame()
[00:00:00 CEST] --- Fri Mar 30 2018