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

[burek]

[00:02:29 CET] <durandal_1707> it could be used as such., need to check out if it indeed solves problems
[00:03:14 CET] <durandal_1707> its there mainly for properly marking frames
[00:19:21 CET] <atomnuker> you know I'm starting to think maybe it'll be a good idea to have some generic side-data like thing internal to lavc
[00:19:40 CET] <atomnuker> could even be a side data wrapping a internal ffmpeg only side data
[00:19:56 CET] <atomnuker> then we could have filters which could pass data to one another
[00:20:07 CET] <atomnuker> and even codec -> filter or codec -> demuxer
[00:24:33 CET] <durandal_1707> dont,  you are like nicolas
[00:26:34 CET] <iive> atomnuker: how is palette passed though filters?
[00:30:07 CET] <atomnuker> iive: dunno, an avframe field?
[00:30:26 CET] <atomnuker> I should probably tell you I know nothing of palette formats
[00:30:35 CET] <iive> i'm asking since afair palette is sent as side data.
[00:30:41 CET] <atomnuker> it is?
[00:30:55 CET] <iive> might be wrong.
[00:31:15 CET] <atomnuker> I think they're sent under avframe->data[1]
[00:31:24 CET] <atomnuker> I don't see any palette side data
[00:31:27 CET] <iive> or [3]
[00:31:47 CET] <iive> yeh, ignore me.
[00:58:18 CET] <wm4> atomnuker: what would that generic side data thing do?
[00:58:39 CET] <wm4> I think palette is in data[1]
[00:58:58 CET] <wm4> fun fact: even some not paletted formats require a palette
[00:59:02 CET] <wm4> (pseudopal flag)
[00:59:13 CET] <JEEB> gotta love that stuff
[00:59:19 CET] <JEEB> I think we had some fun with that with DShow
[00:59:19 CET] <wm4> I think all 8 bit formats have this, because you can treat them as paletted if you want to
[01:27:54 CET] <atomnuker> BBB: when does vp9 signal stuff like resolution, colorspace, etc? on keyframes only?
[02:16:39 CET] <tmm1> jkqxz: what is the "hw-config metadata" you mentioned in http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221601.html
[02:19:03 CET] <jkqxz> tmm1:  <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mediacodecdec.c;h=39f5cbc0450443180a5c4cc77e889ebe5c6494e7;hb=HEAD#l519>.  You're adding AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX.
[02:23:59 CET] <tmm1> got it, thanks
[02:24:18 CET] <tmm1> should i leave AD_HOC in there and or them?
[02:24:34 CET] <jkqxz> (Being able to use that to determine the support is why wm4 asked for the feature in the first place, I think.)
[02:26:18 CET] <tmm1> i'll replace ad_hoc
[02:26:27 CET] <jkqxz> I removed it from others, it's mostly a placeholder.
[02:26:30 CET] <jkqxz> Yeah.
[02:33:12 CET] <jkqxz> tmm1:  Needs device_type to be set too.
[02:42:50 CET] <tmm1> oops
[02:43:07 CET] <tmm1> fixed locally
[03:35:27 CET] <BBB> atomnuker: yes
[03:35:55 CET] <BBB> atomnuker: inter frames can signal resolution change, but they can also signal resolution taken from a reference, and in 99.9% of the cases thats what happens (because its 1 bit instead of 2x16)
[03:42:24 CET] <stevenliu> src/libavfilter/x86/vf_threshold.asm:75: error: invalid number of operands
[03:42:36 CET] <stevenliu> Darwin liuqideMacBook-Pro.local 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
[03:43:00 CET] <stevenliu> 150  rm -rf *
[03:43:00 CET] <stevenliu>   151  ../configure --enable-fontconfig --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libspeex --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-version3 --cc='ccache gcc' --enable-nonfree --enable-videotoolbox
[03:43:00 CET] <stevenliu>   152  make -j2
[03:45:04 CET] <stevenliu> Hi guys, I get error when complie the FFmpeg, i get the newest code one minute ago,  on OS X.
[03:47:03 CET] <jamrial> what's your nasm/yasm version?
[03:47:58 CET] <stevenliu> liuqideMBP:xxx liuqi$ yasm --version
[03:47:58 CET] <stevenliu> yasm 1.3.0
[03:47:59 CET] <stevenliu> Compiled on Apr 28 2016.
[03:48:00 CET] <stevenliu> Copyright (c) 2001-2014 Peter Johnson and other Yasm developers.
[03:48:02 CET] <stevenliu> Run yasm --license for licensing overview and summary.
[03:48:04 CET] <stevenliu> liuqideMBP:xxx liuqi$ nasm -v
[03:48:06 CET] <stevenliu> NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Oct 11 2017
[03:48:39 CET] <stevenliu> do i need update my yasm?
[03:48:49 CET] <jamrial> no, yasm is the latest version
[03:48:54 CET] <stevenliu> nasm?
[03:48:56 CET] <jamrial> i don't recognize that nasm version, though
[03:49:38 CET] <jamrial> what's is X86ASM set to in config.mak?
[03:50:20 CET] <stevenliu> X86ASM=yasm  Ah, yasm
[03:51:49 CET] <stevenliu> let me try use nasm
[03:52:01 CET] <stevenliu> --x86asmexe=nasm
[03:52:05 CET] <jamrial> huh, curious, it really doesn't work with yasm
[03:52:10 CET] <jamrial> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-yasm
[03:52:45 CET] <jamrial> stevenliu: nasm is default, so it used yasm instead it means your nasm version is too old
[03:53:14 CET] <stevenliu> mhmm, let me update it
[03:59:29 CET] <jamrial> stevenliu: try replacing pblendvb with PBLENDVB in that file
[04:00:16 CET] <stevenliu> I have update to newest nasm, will try "try replacing pblendvb with PBLENDVB in that file" later 
[04:17:17 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:894f1c399b5f: lavf/mov: Fix missing newline.
[04:35:58 CET] <stevenliu> jamrial: PBLENDVB is ok.
[05:01:18 CET] <cone-856> ffmpeg 03Robert Nagy 07master:31b351ea81d0: avformat/hlsenc: fix baseurl missing last char
[05:24:54 CET] <cone-856> ffmpeg 03Steven Liu 07master:071f47649ce3: avformat/hlsplaylist: add int type of API ff_hls_write_file_entry
[05:24:55 CET] <cone-856> ffmpeg 03Steven Liu 07master:ad6946b8189e: avformat/hlsplaylist: add return value check of strftime
[05:24:56 CET] <cone-856> ffmpeg 03Steven Liu 07master:1cfde7abd000: avformat/dashenc: add avpriv_io_move return value check
[06:23:35 CET] <cone-856> ffmpeg 03James Almer 07master:b73304f79eba: x86vf_threshold/: use the PBLENDVB macro
[06:23:48 CET] <atomnuker> jamrial: what do you think the saturation functions should bump in version.h?
[06:23:54 CET] <atomnuker> minor/micro?
[06:24:23 CET] <jamrial> new functions in an installed header, so minor
[07:21:26 CET] <atomnuker> daddesio: yeah, no, the last patch's no-go
[07:21:45 CET] <atomnuker> "As a work-around for this issue, the decoder MAY choose not to apply the 180-degree phase shift"
[07:22:19 CET] <atomnuker> or maybe it should be made an option
[07:22:29 CET] <atomnuker> I think I'll make it into an option
[07:25:02 CET] <daddesio> I agree it might be good to give the user the option.
[07:25:18 CET] <daddesio> because it's not what I would expect.
[07:32:05 CET] <daddesio> we also have to update FATE (specifically: testvector05.f32, testvector06.f32, and testvector12.f32).
[07:49:07 CET] <atomnuker> yes, I know, that's what I'm doing
[07:49:19 CET] <atomnuker> I'm replacing all samples and references
[07:50:26 CET] <atomnuker> and because vorbis sucks so much the test samples are conveniently provided as a raw <bytes_for_packet><packet> bitstream which does mean I have to write a simple program to mux them to something usable
[08:09:46 CET] <daddesio> atomnuker: You can find .opus versions of the testvectors here: https://people.xiph.org/~greg/opus_testvectors/
[08:10:22 CET] <daddesio> although the first one (testvector01.bit.opus) seems to have screwed up timestamps which causes warning in ffmpeg/avconv. the rest are fine.
[08:11:22 CET] <daddesio> JSYK, none of the .bit files changed in RFC8251, only the .dec (PCM output) files.
[08:18:40 CET] <atomnuker> those are 5 years old mate, I'm doing the new testvectors from the rfc
[08:18:47 CET] <atomnuker> they didn't?
[08:18:56 CET] <atomnuker> oh well, nvm
[08:31:22 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:9b45bcf713e0: libavutil: Add saturating subtraction functions
[08:31:23 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:511e6f17f493: opus_silk: Fix arithmetic overflow (per RFC8251)
[08:31:24 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:de052ea454e0: opus_celt: Fix arithmetic overflow (per RFC8251)
[08:31:25 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:fe05f93013c4: opus: Add Special Hybrid Folding (per RFC8251)
[08:31:26 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:1b8649c2ce95: opus: add an option to toggle intensity stereo phase inversion
[08:31:27 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:d1d6f965d81b: fate-opus: update to match the changes from RFC8251
[08:32:18 CET] <atomnuker> michaelni: could you update the fate .dec references in opus to the new versions from https://www.ietf.org/proceedings/98/slides/materials-98-codec-opus-newvectors-00.tar.gz
[08:33:21 CET] <atomnuker> take the testvector##.dec files rather than the testvector##m.dec, the latter ones are for decoding with the apply_phase_inv flag off
[08:33:58 CET] <atomnuker> the tron 6ch sample doesn't need to be updated
[08:37:32 CET] <daddesio> did these patches just go into master? I don't see it in git.ffmpeg.org.
[08:40:32 CET] <atomnuker> I think that one's a mirror to http://git.videolan.org/?p=ffmpeg.git;a=log;h=HEAD
[08:40:50 CET] <atomnuker> so its git.videolan.org - > git.ffmpeg.org -> (eventually) github.com/ffmpeg/ffmpeg
[08:41:50 CET] <daddesio> ah, I see, cool https://git.videolan.org/?p=ffmpeg.git;a=summary
[08:46:00 CET] <daddesio> You might want to be smarter about only dropping the phase shift when it's detected that the stereo CELT frame is going to (eventually, by FFmpeg) be downmixed to one channel.
[08:46:17 CET] <daddesio> for multi-channel audio, I mean
[08:46:36 CET] <daddesio> because some CELT frames might be downmixed and some might not.
[08:47:10 CET] <daddesio> wait
[08:49:33 CET] <atomnuker> I'm pretty sure downmixing is dead code
[08:49:43 CET] <atomnuker> none of the fate samples trigger the code to do it
[08:51:02 CET] <daddesio> It's not dead. If you take a stereo Opus file and modify the OggOpus header to say it's mono, then it will downmix to mono.
[08:52:49 CET] <daddesio> but yeah, you are passing the same c->apply_phase_inv to each CELT frame. But you could totally look at avctx->request_channel_layout to see if this (stereo) CELT frame is mapped to one output channel ... I think. I'm not familiar with request_channel_layout.
[08:53:35 CET] <daddesio> that way it's not like the entire (multichannel) Opus file will drop the phase shift.
[08:54:07 CET] <atomnuker> none of the test samples are broken if I disable all downmixing code
[08:54:15 CET] <atomnuker> they're meant to test every case, right?
[08:54:21 CET] <daddesio> erm
[08:54:38 CET] <daddesio> I thought FATE just had the RFC testvectors, plus a multichannel example.
[08:54:49 CET] <daddesio> the testvectors are all stereo.
[08:55:46 CET] <daddesio> Admittedly I'm not aware of a real-world Opus file that claims it's mono but has stereo CELT frames.
[08:56:16 CET] <atomnuker> if they're meant to handle all aspects of the opus decoder then how come they don't handle downmixing?
[08:57:04 CET] <daddesio> because no real-world files use that feature? :P
[08:57:32 CET] <daddesio> you can create a test tho
[08:58:47 CET] <daddesio> just take any stereo .opus file and change the "Channel Count" field from 2 to 1 (https://tools.ietf.org/html/rfc7845.html#section-5.1) and our Opus decoder will downmix the CELT frames to one mono output.
[08:59:59 CET] <daddesio> going to bed now since I have work tomorrow.
[10:31:40 CET] <cone-856> ffmpeg 03Paul B Mahol 07master:86fda8be3f38: avfilter: add hflip x86 SIMD
[10:35:37 CET] <atomnuker> durandal_1707: that was a bit premature
[10:35:58 CET] <durandal_1707> what?
[10:35:59 CET] <atomnuker> why do you load 2 regs at once and then do exactly the same things to them?
[10:36:09 CET] <atomnuker> also RET should be indented
[10:37:02 CET] <atomnuker> wouldn't loading 2 regs at the same time unconditionally also increase padding requirements?
[10:37:09 CET] <durandal_1707> atomnuker: it should be faster that way
[10:37:24 CET] <atomnuker> it usually isn't
[10:37:32 CET] <atomnuker> also most of the movs should be aligned
[10:37:54 CET] <atomnuker> *most of them == all of them
[10:38:08 CET] <durandal_1707> it cant be aligned if height is not multiple of mmsize
[10:38:22 CET] <atomnuker> you mean width?
[10:39:12 CET] <durandal_1707> one could write special version for width multiple of mmsize
[10:39:59 CET] <durandal_1707> but for what gain?
[10:40:01 CET] <atomnuker> this is irrelevant
[10:40:48 CET] <atomnuker> I'm pretty sure this asm is quite broken
[10:41:08 CET] <durandal_1707> also one can use crop and it will be unaligned
[10:41:09 CET] <atomnuker> seeing as you require a 2*mmsize padded width
[10:41:56 CET] <durandal_1707> atomnuker: no, its faster than what clang gives, so i declare it state of art
[10:42:17 CET] <durandal_1707> if you can improve it even more, patch welcome
[10:43:03 CET] <atomnuker> I meant broken, as it _crashes_
[10:43:22 CET] <durandal_1707> it works here
[10:43:50 CET] <atomnuker> with arbitrary resolutions like 531 or 1011?
[10:43:53 CET] <atomnuker> *width
[10:45:42 CET] <michaelni> atomnuker, about opus testvectors, i cannot upload them as is as they overwrite existing ones and break fate of all past revissions
[10:47:53 CET] <atomnuker> so samples can only be added or removed, not replaced?
[10:48:30 CET] <nevcairiel> only added, not removed either
[10:49:09 CET] <atomnuker> why, what would happen if they did get removed after say, 2 years?
[10:49:31 CET] <nevcairiel> if you try to bisect some older issue your fate run gets all sorts of broken
[10:49:46 CET] <durandal_1707> atomnuker: i tried various widths and it works
[10:50:16 CET] <nevcairiel> but if the references change you can add them as v2 or whatever
[10:50:16 CET] <atomnuker> durandal_1707: in any case at least _fix the bloody indentation_, its all over the place
[10:50:32 CET] <atomnuker> the RETS need to be indented and the "add    wq, rq" needs to be unindented by one
[10:51:28 CET] <durandal_1707> atomnuker: post asm identation rules with example or already written asm code i should use as reference
[10:51:30 CET] <atomnuker> I think the rfc said only 5 and 6 were different
[10:52:59 CET] <atomnuker> durandal_1707: textbook example: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86/diracdsp.asm#L272
[10:53:38 CET] <atomnuker> I don't mind if internal loops get indented by one, as long as after a loop things get correctly... unindented
[10:54:34 CET] <atomnuker> (I do mind about a jump being indented though, it should be indented to the same level as stuff inside the loop)
[10:58:09 CET] <atomnuker> michaelni: everything except testvector02.dec, testvector03.dec and testvector04.dec needs to get v2
[11:01:55 CET] <atomnuker> michaelni: you'll also need to patch the fate test with this: https://pars.ee/temp/opus_fate_upd.diff
[11:02:05 CET] <atomnuker> and rename the new samples to testvector_v2_##
[11:02:55 CET] <atomnuker> you can _remove_ 07, 09, 11 and even 01 if you want to
[11:03:07 CET] <atomnuker> because those samples were never used in a fate test at all
[11:04:12 CET] <atomnuker> (I added a check for 01 just now because I saw it was never used, but feel free to remove it)
[11:26:56 CET] <michaelni> atomnuker, can you provide a .tar that i can just copy/move files from ? (iam too dumb to follow complex multi file rename instructions and not mess up occasionally)
[11:51:57 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:ce87e630fa00: opus_celt: deduplicate band quantization/dequantization function
[11:51:58 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:7b46add72576: opus_pvq: do not compile encoding/decoding code if the encoder/decoder is disabled
[11:51:59 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:e836a0b3fd69: fate-opus: update tests to use new decoder outputs
[11:52:08 CET] <atomnuker> michaelni: https://pars.ee/temp/testvector05_v2.dec and https://pars.ee/temp/testvector06_v2.dec
[11:52:29 CET] <atomnuker> just put them in $FATE_SAMPLES/opus and they'll work
[11:52:56 CET] <atomnuker> those 2 tests alone are enough to test the new hybrid folding, so no need to update the rest, even if they're slightly different
[11:53:14 CET] <atomnuker> I've patched the fate test so you only need to put them
[11:54:08 CET] <atomnuker> and remove 01, 07, 09 and 11 because they're not used and they've never been used if space matters
[11:54:28 CET] <atomnuker> (if space doesn't matter, do mention and I'll add them to the test)
[12:17:41 CET] <michaelni> atomnuker, if i remove  01, 07, 09 and 11 then fate-opus-testvector01, fate-opus-testvector07 fate-opus-testvector09 fate-opus-testvector11 fail
[12:19:02 CET] <atomnuker> damn, I guess you can't remove them because even though their results weren't checked they were still needed
[12:20:18 CET] <atomnuker> what a mess, usually decoders are set in stone once the bitstream is declared stable
[12:21:58 CET] <nevcairiel> yeah it is a bit unusual to re-define the decoder
[12:28:41 CET] <atomnuker> michaelni: but how did you change the fate references to use the ones from the official archive rather than the previous one
[12:28:53 CET] <atomnuker> (to save space by switching from f32 -> s16)
[12:29:41 CET] <michaelni> atomnuker, i dont remember changng anything
[12:30:21 CET] <michaelni> opus/testvector05_v2.dec opus/testvector06_v2.dec uploaded
[12:31:57 CET] <michaelni> nevcairiel, mpeg4 qpel was also changed (that is spec changed to match reference implementation which broke some decoders like ours really long ago which was following the spec and not the implementation)
[12:38:43 CET] <atomnuker> thanks
[12:38:45 CET] <atomnuker> michaelni: https://github.com/FFmpeg/FFmpeg/commit/d228271813ab2c2a3196dcff813cee93c791dbda
[12:47:16 CET] <atomnuker> did that unintentionally break fate by replacing files?
[12:47:59 CET] <michaelni> atomnuker, i almost dont remember this commit 
[12:48:31 CET] <michaelni> but i doubt it broke fate because everyone would have noticed and fried me if it did
[12:50:04 CET] <atomnuker> weird, going to push a commit to check the results of 01, 07, 09, and 11 soon (once I deduplicate another function)
[12:50:22 CET] <atomnuker> might as well make them do something if we've got them
[12:52:44 CET] <michaelni> maybe the tests where disabled and not working before this commit
[12:56:09 CET] <atomnuker> seems so actually
[13:03:18 CET] <nevcairiel> yeah the commit enabled the tests
[13:03:23 CET] <nevcairiel> was commented out before
[13:43:21 CET] <jdarnley> Ha ha ha.  I was searching for a page about intel things and DuckDuckGo added me this message "Including results for intel®"
[13:55:57 CET] <jdarnley> durandal_1707: there aren't byte-sized versions of all registers available on x86 ^
[13:56:52 CET] <durandal_1707> yes, how to fix this?
[13:57:54 CET] <jdarnley> Not sure.
[14:00:09 CET] <jdarnley> I would suggest moving r0 somewhere else, use r0b for this part and then "somewhereelse" for what r0 should be.
[14:01:58 CET] <jdarnley> No, on second thoughts reverse x and v arguments to cglobal
[14:05:26 CET] Action: jdarnley goes afk
[14:13:57 CET] <friki_> Hi, I'm working on my first ffmpeg patch (libavformat/mxfenc.c)... and I have my first question: Is there a reason why "avio_put_str16be(pb, value)" doesn't work as expected if "value" length is 20 or more?
[14:15:00 CET] <thardin> in what way doesn't it work as expected?
[14:18:26 CET] <friki_> thardin: my patch here: https://paste.debian.net/999034/
[14:19:27 CET] <friki_> Take a look at "void mxf_write_track". If I remove the line with "tag->value[19] = '\0'" it stops working
[14:20:08 CET] <friki_> As I've said it's my first time reading ffmpeg code, so probably I'm doing it wrong :-/
[14:20:58 CET] <thardin> uhh yeah?
[14:21:08 CET] <thardin> it's nul terminated like C strings typically are
[14:21:34 CET] <friki_> yap, if i remove that line there is no title tag in output file
[14:21:49 CET] <friki_> avio_put_str16be return correct values each time
[14:22:10 CET] <thardin> is tag->value terminated?
[14:22:36 CET] <friki_> if i change "19" by "20" in this line also fails
[14:22:51 CET] <friki_> 19 seems to be the limit
[14:22:56 CET] <thardin> that's strange but not really what I'm after
[14:23:29 CET] <thardin> what does strlen() say?
[14:24:22 CET] <thardin> can't imagine AVDictionaryEntry has a 20 bytes value limit
[14:25:15 CET] <friki_> strlen(tag->value) is 32 in my test
[14:26:44 CET] <thardin> does avio_put_str16be() do anything strange? I recall it possible copying the string into a new buffer
[14:27:12 CET] <thardin> maybe it expects wide strings and you're putting in 8-bit ones?
[14:29:37 CET] <friki_> i'm using de mxf helper "mxf_write_local_tag_utf16" to transform my string (utf8?) into utf16. It just calculate the propper size and call "avio_put_str16be"
[14:32:41 CET] <thardin> oh god those animations on ffmpeg.org
[14:35:16 CET] <thardin> uhh avio_put_str16be() isn't implemented anywhere
[14:35:46 CET] <thardin> try grep -R avio_put_str16be .  in the root of the ffmpeg repo
[14:35:59 CET] <thardin> or git grep if you prefetr
[14:37:12 CET] <thardin> oh nm there's a macro in aviobuf
[14:37:38 CET] <thardin> I'd put some debug printing in put_str16() in aviobuf.c
[14:55:39 CET] <friki_> thardin: put_str16 seems to do the work. I'll keep finding the problem. thanks for the tips :-)
[15:03:25 CET] <thardin> friki_: the unicode logic in libavformat looks very suspicious, so I wouldn't doubt there's bugs hidden in it
[15:10:28 CET] <cone-856> ffmpeg 03Paul B Mahol 07master:5ff0d2acaef8: avfilter/x86/vf_hflip.asm: fix building on x32
[15:31:03 CET] <JEEB> x32?
[15:31:09 CET] <JEEB> did someone actually try using it on x32?
[15:31:23 CET] <JEEB> didn't we more or less explicitly not support x32?
[15:35:03 CET] <kierank> x32 is dead
[15:35:05 CET] <jdarnley> He means x86
[15:35:12 CET] <kierank> Yeab
[15:35:40 CET] <JEEB> I kind of guessed that, I'm just an asshole that wants a "whoops" reaction or something along those lines :P
[15:35:55 CET] <jamrial> how did that fix x86_32 anyway? it was well within the gpr limit
[15:35:58 CET] <atomnuker> how would people survive without being able to mmap arbitrarily huge files nowadays
[15:37:37 CET] <jdarnley> jamrial: it was trying to use a byte-sized register that doesn't exist on x86.
[15:38:09 CET] <jamrial> oh right, that stupid limitation
[15:38:13 CET] <jdarnley> only r0-r3 have them on x86
[15:38:30 CET] <jamrial> man, does x86_32 suck...
[15:38:45 CET] <atomnuker> it rules, just don't use byte registers
[15:38:56 CET] <atomnuker> oh, x86_32, yeah, it sucks
[15:39:39 CET] <jdarnley> It is a little hard to copy a byte when you don't have a byte-sized register
[15:40:58 CET] <atomnuker> why copy 1 byte when you can copy 4 at a time!
[16:52:59 CET] <cone-856> ffmpeg 03Steven Liu 07master:d67c1dda4032: avformat/hlsenc: fix compiling error when disable-network
[17:39:02 CET] <daddesio> atomnuker: i'm bored, need something new to do. I could do a SILK encoder, or add support for packet-loss concealment.
[17:39:35 CET] <daddesio> only problem is I'm not 100% sure how the noise-shape quantizer works in SILK. I know about noise shaping, minimizing error in the perceptually weighted domain etc.
[17:40:17 CET] <daddesio> i'm currently doing an EA MicroTalk encoder: https://github.com/daddesio/utkencode
[17:42:36 CET] <daddesio> probably it's more important to at least add decoder support for PLC frames though.
[17:55:39 CET] <daddesio> "Hence, a much better design (and indeed the standard practice for multi-pulse speech codecs) is to search for the positions and amplitudes of n pulses such that error is minimized in the output domain (or the perceptually weighted domain)."
[17:55:42 CET] <daddesio> Fun fact: This is actually a Toeplitz (FIR-filtering) matrix equation ***with deleted columns*** (hence the matrix is no longer Toeplitz anymore). I tried finding any kind of O(n^2) algorithm for this but it still seems the most efficient solution to this equation is plain ol' Matrix Least Squares (via QR decomposition), which (in utkencode tool) I'll probably end up using ATLAS/LAPACK for.
[17:58:22 CET] <daddesio> erm no... sorry, I was thinking of the reoptimization problem
[17:58:34 CET] <daddesio> when you have *already decided* where you will place down the n pulses
[17:59:05 CET] <daddesio> (you can decide on the pulse locations using cross-correlation of the signal against the perceptual weighting filter's impulse response)
[18:00:03 CET] <daddesio> In fact, encoding EA Microtalk nicely is so hard precisely because the codec doesn't have a pre-filter/post-filter like most CELP codecs.
[18:21:45 CET] <durandal_1707> michaelni: when you planned to ditch deprecated yuvj pixel formats?
[18:38:24 CET] <durandal_1707> how can i force scale filter when only color range differ?
[18:42:37 CET] <BtbN> Isn't there pretty much always an auto inserted scaler, even if everything matches?
[18:44:23 CET] <durandal_1707> for color range it obviously isnt
[19:18:40 CET] <cone-856> ffmpeg 03sfan5 07master:942eafcf08c4: libavcodec/hevc_filter: support for all skip_loop_filter levels.
[19:18:49 CET] <sfan5> yay
[19:22:28 CET] <kurosu> in theory, the last progress report should likely be y + ctb_size - 4*!skip, but oh well
[19:23:56 CET] <kurosu> also maybe the skip derivation should have been in ff_hevc_hls_filters, and then passed
[19:29:16 CET] <BtbN> Does configure have some magic to do "enabled_any nvenc nvdec cuvid cuda && ..."?
[19:29:34 CET] <BtbN> oh, it actually does
[19:29:41 CET] <BtbN> called... enabled_any
[19:31:38 CET] <BtbN> hm, that's not the right way to do it anyway
[19:38:00 CET] <BtbN> Oh great, the nvidia compat headers include ffmpeg headers
[19:38:24 CET] <BtbN> Guess the loader-header will have to stay in-tree
[19:41:13 CET] <flydev> Hi guys, the last ffmpeg compile guide for Ubuntu 16 is broken
[19:41:20 CET] <BtbN> fix it
[19:42:31 CET] <flydev> Nah, tried, it's screwed up badly
[19:42:54 CET] <flydev> libx265.so.147: cannot open shared object file: No such file or directory
[19:43:56 CET] <flydev> Already have dozens of Ubuntu 14 hosts with older version compiling and running fine, this one also seems to compile everything fine, but it does not run at all
[19:44:38 CET] <flydev> And can't really figure out why x265 lib is missing when x265 compiles fine
[19:45:00 CET] <nevcairiel> you want #ffmpeg, this channel is not for user help
[19:47:02 CET] <cone-856> ffmpeg 03James Almer 07master:1b324700e3a1: checkasm/vf_threshold: fix mixed code and declarations
[19:47:03 CET] <cone-856> ffmpeg 03James Almer 07master:bfd7f07b650b: fate/checkasm: add missing target for vf_threshold test
[19:47:04 CET] <cone-856> ffmpeg 03James Almer 07master:cc2ba526d414: x86/vf_threshold: make threshold8 functions work on x86_32
[21:39:15 CET] <cone-856> ffmpeg 03Paul B Mahol 07master:312b00de8f8b: avfilter/vf_convolution: add 7x7 filter
[00:00:00 CET] --- Tue Dec  5 2017