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

[burek]

[00:02:51 CEST] <onecamper> win64 doesn't have a red zone on the stack, right?
[00:06:29 CEST] <nevcairiel> there is the shadow space instead, but its smaller and in a different position
[00:08:16 CEST] <nevcairiel> x86inc.asm uses the shadow space to save a few regs there, but its only  32-byte
[00:08:50 CEST] <onecamper> right, so libswresample/x86/resample.asm:68 looks like a bug then 
[00:54:27 CEST] <cone-363> ffmpeg 03John Stebbins 07master:c9a992d93144: lavf/mov: add AVCodecTag entry for GoPro metadata
[00:54:27 CEST] <cone-363> ffmpeg 03John Stebbins 07master:3318ac5b9a7c: lavf/mov: factor out setting codec_id
[00:54:27 CEST] <cone-363> ffmpeg 03John Stebbins 07master:981178f3b0b5: lavf/movenc: Add GoPro metadata to permitted mp4 "codecs"
[00:54:27 CEST] <cone-363> ffmpeg 03John Stebbins 07master:4cfb01d6ae54: lavf/movenc: Fail when codec tag is invalid for format
[02:44:28 CEST] <Gramner> onecamper / nevcairiel: indeed, you can't store anything below the stack pointer on windows or it may go poof at any time due to interrupt handlers and what not. x86inc stores xmm6 and xmm7 in the shadow space but this particular function doesn't need to save them so I guess you could use that as scratch space on win64 without having to change much of the existing code
[02:51:51 CEST] <Gramner> I actually have no idea wtf the microsoft engineers smoked when they designed the win64 calling conventions, because it's such a pile of garbage compared to the system v abi (that everyone else uses) which existed before it. it's like they went out of their way to design something as terrible as possible
[02:53:35 CEST] <atomnuker> they wanted to keep compatibility with 32 bit systems?
[02:54:28 CEST] <Gramner> there's no compatibility in calling conventions
[02:54:34 CEST] <Gramner> it's unrelated to compatibility
[02:55:04 CEST] <atomnuker> are the 32bit and 64bit conventions similar? maybe they wanted to keep their code?
[02:55:18 CEST] <Gramner> vector registers are most commonly used in leaf functions, so let's make the majority of them callee-saved! passing arguments in registers is great, so let's avoid doing that too much! this red zone thing is great, so don't do that and instead make up the concept of a shadow space which mostly just makes things worse than not doing anything!
[02:55:30 CEST] <Gramner> no, 32-bit calling conventions is completely different
[02:57:51 CEST] <atomnuker> that does sound like they were taking the piss then
[03:01:50 CEST] <Gramner> the only logical reason I can come up with is that they wanted to make portability harder as an attempt to try to lock software to their os that they tried to make it as different and possible compared to the "existing standard", and since the existing standard is good they intentionally chose to make something terrible
[11:41:53 CEST] <cone-854> ffmpeg 03Paul B Mahol 07master:158043bae84b: avcodec/gifdec: check ff_lzw_decode_open() for failure
[11:41:53 CEST] <cone-854> ffmpeg 03Paul B Mahol 07master:39cfb722ee73: avcodec/gifdec: set .caps_internal
[11:41:53 CEST] <cone-854> ffmpeg 03Paul B Mahol 07master:05df39cf3f81: avcodec/tiff: check ff_lzw_decode_open() for failure
[11:56:46 CEST] <durandal_1707> should i write gif parser?
[12:03:16 CEST] <cone-854> ffmpeg 03Moritz Barsnick 07master:1693a6818730: avcodec/aacenc: report channel layout by name
[12:03:17 CEST] <cone-854> ffmpeg 03Dale Curtis 07master:8ef7fb86d62c: avformat/utils: Don't calculate duration using AV_NOPTS_VALUE for start_time.
[12:03:18 CEST] <cone-854> ffmpeg 03gxw 07master:090647da84f9: avcodec/mips: [loongson] optimize vp8 decoding in vp8dsp.
[12:03:19 CEST] <cone-854> ffmpeg 03Shiyou Yin 07master:5161f7bcfd3c: avutil/mips: [loongson] simplify macro TRANSPOSE_4H and TRANSPOSE_8B
[14:15:03 CEST] <cone-854> ffmpeg 03Paul B Mahol 07master:4b1b47e81b5c: avcodec/scpr: stop checking for overread twice
[16:32:42 CEST] <j-b> hello
[17:08:49 CEST] <Compn> what up j-b
[17:09:11 CEST] <j-b> Compn: not much, IBC&VDD coming soon. Working on AV1 stuff
[17:10:48 CEST] <JEEB> youtube started offering av1 on some videos it seems
[17:10:49 CEST] <JEEB> in mp4
[17:11:02 CEST] <Compn> unstreamable then being mp4 :D
[17:11:29 CEST] <JEEB> just like all the other live streams totally not working with MPEG-DASH
[17:12:17 CEST] <nevcairiel> yeah mp4 is like the main format for streaming these days
[17:12:24 CEST] <nevcairiel> both in modern hls and dash
[17:12:37 CEST] <Compn> as long as rtmp is dead I am happy :P
[17:13:56 CEST] <j-b> JEEB: for test, yes
[17:14:25 CEST] <j-b> the mp4 mapping is almost ready and done
[17:15:01 CEST] <JEEB> I think it got a 1.0.0 tag a day or two ago
[17:15:14 CEST] <nevcairiel> yeah mp4 mapping 1.0 was finalized on the 7th
[17:16:36 CEST] <j-b> it's only half-idiotic, this time.
[17:16:47 CEST] <j-b> Compared to VP9
[17:17:40 CEST] <ritsuka> multiple frames in the same sample in mp4 looks like fun
[17:18:11 CEST] <nevcairiel> its probably the same deal as ever, grouping invisible frames with visible frames for simpler timestamps
[17:18:41 CEST] <durandal_1707> Compn: where are all the samples?
[18:10:01 CEST] <jamrial> nevcairiel: not just that, you can have three visible frames grouped in one TU, two of them which are meant to be displayed later
[18:13:20 CEST] <Paranoialmaniac> it's AVI packed bitstream :P
[18:16:02 CEST] <JEEB> (just what we needed in 2018)
[18:17:45 CEST] <jamrial> JEEB: which are those test youtube streams? and i guess only chromium dev and with luck firefox nightly will be able to handle them
[18:18:09 CEST] <JEEB> the js player isn't giving those out
[18:18:26 CEST] <JEEB> if you poke youtube-dl at something like https://www.youtube.com/watch?v=F1B9Fk_SgI0
[18:18:46 CEST] <JEEB> (I have not watched that clip, just that youtube-dl gives "WARNING: Unknown codec av01.0.05M.08" with it)
[18:19:47 CEST] <jamrial> yeah, looks like youtube-dl needs to be updated for those
[18:20:08 CEST] <jamrial> guess it's time to remove the experimental tag from the mp4 muxer as well
[18:22:18 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:43421386f2cc: avfilter/vf_extractplanes: fix 14bit format extraction
[18:22:18 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:6c06389d6e80: avfilter/vf_extractplanes: define common 8-bit pixel formats
[18:22:18 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:e10846001d15: avfilter/vf_extractplanes: define higher depth formats with macro
[18:33:09 CEST] <nevcairiel> jamrial: but it still doesnt have re-ordering, no? so its basically like vp9, where you get a all-skip P frame later that just copies the earlier frame?
[18:35:41 CEST] <jamrial> you get a 2 byte frame header only TU that essentially tells the decoder "display this one frame you got several packets ago"
[18:36:25 CEST] <nevcairiel> so yeah its an optimized case of that
[18:36:57 CEST] <jkqxz> Yes, the actually-encoded all-skip frame was only a real thing in VP8.
[18:37:47 CEST] <jkqxz> VP9 and AV1 have eight explicit slots in the DPB, and the special trivial frame which is just "show slot N".
[18:38:07 CEST] <jamrial> vp8 invisible frames were also not packet with visible ones, which could result in weirdness at the container level because of screwed up timestamps
[18:38:39 CEST] <jamrial> the isobmff spec directly didn't bother on defining how those work
[18:39:24 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:e70f6cb7e3d0: avfilter/vf_premultiply: add gray14 format
[18:41:32 CEST] <durandal_1707> i want to help writing av1 in ffmpeg, but nobody wants my hand
[19:11:22 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:bd6c57d532c5: avfilter: add support for gray14 format
[19:13:09 CEST] <jamrial> 16383 shades of gray
[19:15:52 CEST] <atomnuker> durandal_1707: welp, I had it worse, I started writing a decoder in march without knowing someone already had an av1 decoder already somewhat working
[19:17:18 CEST] <atomnuker> jamrial: feel free to push a patch to remove the experimental flag, based on testaments from a somewhat sizable group of people it works
[19:17:19 CEST] <kurosu> if you have the time, energy and ability, that's a good way of getting to understand a codec beyond (whatever quality are) the specs
[19:19:25 CEST] <durandal_1707> atomnuker: what? this is actually closed source - whats point in opening code later on when it is going to be blackbox anyway
[19:20:00 CEST] <jamrial> atomnuker: i'll
[19:20:08 CEST] <kierank> durandal_1707: what is closed source
[19:23:29 CEST] <durandal_1707> kierank: code that nobody but you understand
[19:25:45 CEST] <atomnuker> that's not entirely true, if you get to spend enough time on a certain piece you think you start to understand what the author was trying to do
[19:26:14 CEST] <atomnuker> though you still don't understand why they didn't do it right and had to have random bits of code that do something around
[19:34:43 CEST] <kurosu> durandal_1707, to be blunt, there are likely some high requirements on this work - contract stuff like binding clauses and "srs bsns"
[19:43:31 CEST] <durandal_1707> kurosu: i bet i fill find bugs
[19:52:21 CEST] <atomnuker> of course you would, you've seen the logic of the code in libaom, no way something hasn't been forgotten
[19:52:42 CEST] <atomnuker> I think there's already a potential bugfix lined up for an annex
[19:57:49 CEST] <kierank> atomnuker: even after the argon spec compiler?
[19:57:58 CEST] <cone-479> ffmpeg 03Daniel Oberhoff 07master:a75d805e6b7b: avfilter/vf_remap: add slice threading
[20:00:41 CEST] <atomnuker> kierank: I haven't seen it but I would be really suprised if they made it work without using libaom source code
[20:16:43 CEST] <durandal_1707> can some cracker comment lagarith patch?
[20:28:34 CEST] <kierank> durandal_1707: i'm quite surprise by speed increase going to planar
[20:36:21 CEST] <nevcairiel> what i might wonder, how is the overall speed if i swscale that back to packed
[20:38:22 CEST] <durandal_1707> swscale stinks
[20:39:19 CEST] <durandal_1707> nevcairiel: irrelevant, avcodec is not new swscale, we are not doing cinepak pixel format conversions in codecs
[20:39:38 CEST] <kierank> durandal_1707: we should use fastest pixel format available
[20:42:33 CEST] <atomnuker> durandal_1707: I saw you memcpy'd from buf[i] to avframe->data[i], can't you make it such that buf[i] points to avframe->data[i] and skip a memcpy?
[20:44:36 CEST] <durandal_1707> atomnuker: visit nearest hospital, my patch removes memcpy and microoptimizations by our beloved leader
[20:45:16 CEST] <nevcairiel> durandal_1707: i'm not saying you should do it in the decoder, but if i need packed rgb output, it might be interesting to know the performance afterwards as well
[20:45:20 CEST] <nevcairiel> its nice to output fast packed
[20:45:31 CEST] <nevcairiel> eh fast planar
[20:45:37 CEST] <nevcairiel> but if i need packed, that doesnt benefit me :D
[20:45:56 CEST] <kierank> durandal_1707: did you not try simd version instead of memset
[20:46:12 CEST] <kierank> for packed
[20:46:20 CEST] <durandal_1707> kierank: there is such thing?
[20:46:32 CEST] <kierank> iiuc lararith is predictive so surely faster to predict all components instead of planar
[20:50:12 CEST] <durandal_1707> atomnuker: ugh, i see what you want, but that is for another patch
[20:51:23 CEST] <atomnuker> kk
[20:54:13 CEST] <durandal_1707> nevcairiel: swscale + my patch vs old : 384 vs 365
[20:54:32 CEST] <durandal_1707> so going to rgb24 is still faster
[20:58:38 CEST] <cone-479> ffmpeg 03Justin Ruggles 07master:d2047c14c078: Use QT format for audio sample descriptors depending on stsd version.
[20:58:39 CEST] <cone-479> ffmpeg 03Derek Buitenhuis 07master:f55d987bad40: Add FATE test for QT format audio descriptors in MP4
[21:05:51 CEST] <durandal_1707> kierank: i dunno what you want to say, but with this patch decoding and pixel conversion with sws is faster
[21:07:08 CEST] <kierank> unfortunately I lack the time to look at it in detail so I take your word for it
[21:15:12 CEST] <atomnuker> it does somewhat slow down a use case though - a video player
[21:15:43 CEST] <atomnuker> since interleaved rgba is native you can just memcpy it, with a planar surface you need to interleave it
[21:16:39 CEST] <atomnuker> I like the patch though, if lagarth is more suited to be outputted as planar rgb
[21:17:45 CEST] <durandal_1707> atomnuker: wtf? so I can apply that old cinepak patch after all?
[21:19:18 CEST] <durandal_1707> and this is all with swscale not having simd for gbrp->rgb24
[21:24:07 CEST] <durandal_1707> real video player uses shaders for format conversion, and mpv have that, but even then players like ffplay, can use swscale and it will still be faster
[21:25:40 CEST] <nevcairiel> sounds fine to me if planar decode + sws is even still faster
[21:26:58 CEST] <durandal_1707> yes, but even if it is not lagarith should be treated same as cinepak: no lavc format conversions
[21:30:18 CEST] <durandal_1707> i'm paying 10000$ for someone to write gbrp->rgb24/rgba simd for swscale!
[21:30:45 CEST] <nevcairiel> interleaving simd is easy
[21:30:49 CEST] <nevcairiel> dont overvalue it =p
[21:31:39 CEST] <cone-479> ffmpeg 03Marton Balint 07master:bd3c27fd7aa3: avdevice/decklink_enc: add support for setting duplex mode
[21:31:40 CEST] <cone-479> ffmpeg 03Marton Balint 07master:4737387d288d: avutil/file: allow mapping 0 byte files with av_file_map
[21:31:42 CEST] <cone-479> ffmpeg 03Marton Balint 07master:43d3b61abeb7: avfilter/f_cue: add cue and acue filters
[21:31:42 CEST] <cone-479> ffmpeg 03Marton Balint 07master:37caec3dc459: avfilter/vf_framerate: switch to activate
[21:33:32 CEST] <jamrial> that path doesn't exist already?
[21:36:02 CEST] <durandal_1707> jamrial: afaik, -cpuflags 0 give same speed as without it
[21:46:33 CEST] <durandal_1707> so anybody want to write it?
[21:47:13 CEST] <jamrial> for $10000? sure
[21:47:40 CEST] <durandal_1707> jamrial: what about for 0$?
[21:49:35 CEST] <jamrial> that's not as attractive :p
[21:50:15 CEST] <atomnuker> durandal_1707: no, that old cinepak patch did colorspace conversion, which isn't acceptable as it isn't lossless
[21:51:16 CEST] <atomnuker> (that's not to say you should output rgb24 as rgb48, you should pad to the nearest appropriately sized pixel format if your input is say 14 bit per component rgb)
[22:24:00 CEST] <atomnuker> jamrial: youtube-dl just updated so you can download av1, but you can't mux them in mp4 because of the experimental flag
[22:25:23 CEST] <jamrial> atomnuker: ok, give me a sec
[22:27:11 CEST] <cone-479> ffmpeg 03James Almer 07master:edafb9f52991: avformat/movenc: remove experimental checks for AV1 streams
[22:28:30 CEST] <atomnuker> thanks, its totally the future now
[22:29:59 CEST] <jamrial> atomnuker: they literally hardcoded a "av01.0.05M.08" check, though
[22:30:23 CEST] <JEEB> that's teh test for it I think?
[22:30:40 CEST] <JEEB> they have a separate thing that searches for 'av01'
[22:30:48 CEST] <jamrial> yes, but wont that fail with streams reporting a different profile, level, tier and bitdepth?
[22:30:55 CEST] <JEEB> which then if a video track isn't set yet sets it as av1
[22:31:00 CEST] <JEEB> *as a video track
[22:31:23 CEST] <JEEB> jamrial: I think the if codec in ('avc1', 'avc2', 'avc3', 'avc4', 'vp9', 'vp8', 'hev1', 'hev2', 'h263', 'h264', 'mp4v', 'hvc1', 'av01'):
[22:31:29 CEST] <JEEB> part is the actual video recognition
[22:31:40 CEST] <JEEB> while the other is just a test
[22:31:41 CEST] <JEEB>  test/test_utils.py
[22:31:47 CEST] <jamrial> oh right, my bad
[22:31:54 CEST] <JEEB> so that it parses that thing as video
[22:31:56 CEST] <JEEB> I guess
[22:33:11 CEST] <atomnuker> I like how youtube only seem to offer it for 480p in that video
[22:33:24 CEST] <atomnuker> curious to know what encoding settings they use but we don't have SEI
[22:34:06 CEST] <kierank> atomnuker: they do segmented encoding anyway
[22:36:59 CEST] <durandal_1707> nevcairiel: actually swscale completely lacks unscaled gbrap to rgb24, so its very slow, i fixed that now
[22:37:25 CEST] <durandal_1707> running FATE, after itt passes i will push my patches
[22:38:56 CEST] <JEEB> did libp2p have anything useful for that?
[22:39:07 CEST] <JEEB> (and yes, that's another troll'y name by twc)
[22:39:45 CEST] <durandal_1707> JEEB: zimg is slower than sws, so i doubt
[22:40:21 CEST] <JEEB> unlike zimg I don't think packing/unpacking has any slower, "proper" ways of doing things :P
[22:42:00 CEST] <JEEB> but yea I don't see any specific SIMD
[22:42:06 CEST] <JEEB> https://github.com/sekrit-twc/libp2p/blob/master/p2p_api.cpp
[22:44:43 CEST] <durandal_1707> JEEB: compilers are usually smart so they optimize it
[22:50:57 CEST] <durandal_1707> oh, i broke fate, gonna push a fix asap
[22:52:12 CEST] <cone-479> ffmpeg 03Devin Heitmueller 07master:6a9abe9ec333: avcodec/v210enc: Pass through A53 CC data
[22:52:13 CEST] <cone-479> ffmpeg 03Devin Heitmueller 07master:8732dfa99549: avdevice/decklink: Add support for EIA-708 output over SDI
[22:52:14 CEST] <cone-479> ffmpeg 03Devin Heitmueller 07master:35498c124a81: avcodec: add AV_PKT_DATA_AFD to allow AFD data to be embedded in AVPacket
[22:52:15 CEST] <cone-479> ffmpeg 03Devin Heitmueller 07master:fb9d4f5c3e27: avcodec/v210enc: Pass through Active Format Description (AFD) data
[22:56:11 CEST] <atomnuker> would be nice for the opus in mp4 spec to get finished, apparently its been stuck for 2 years because they didn't know how to fix the preskip
[22:56:33 CEST] <atomnuker> and left it as is because its apparently broken for everything unless edit lists are used
[23:01:08 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:b2ffecbd0ccc: avcodec/lagarith: switch to planar rgb
[23:01:10 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:29a24e5f7970: avcodec/lagarith: set pict_type too
[23:01:10 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:931e7c050e77: swscale/swscale_unscaled: add gbrap -> packed rgb path
[23:01:12 CEST] <cone-479> ffmpeg 03Paul B Mahol 07master:404d21f486b0: tests/fate: fix lut hash for gray14
[23:17:49 CEST] <atomnuker> can't seem to find any other videos with av1, and the person who filed the bug probably found it by coincidence
[23:18:09 CEST] <JEEB> there was another one from that same group of videos I think
[23:18:15 CEST] <JEEB> because someoen came to #mpv
[23:18:25 CEST] <JEEB> because youtube-dl picked av01 as audio
[00:00:00 CEST] --- Mon Sep 10 2018