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

[burek]

[00:11] <cone-822> ffmpeg.git 03Carl Eugen Hoyos 07master:4b63bcef907b: Autodetect jpeg-ls files.
[02:45] <kierank> nevcairiel: sent a patch to do afd in h264
[02:45] <kierank> (I think it was you who asked me)
[03:34] <cone-495> ffmpeg.git 03Mark Reid 07master:d6af706eee48: avformat/movenc: write reel_name metadata to tmcd atom
[05:21] <cone-495> ffmpeg.git 03Michael Niedermayer 07master:64d029de41ed: avformat/matroskaenc: fix MAX_CUEPOINT_SIZE calculation
[06:38] <Compn> mythtv has many modifications to ffmpeg, including teletext mpeg-ts changes ? nice
[06:39] <Compn> i vote we include the whole demuxer as a secondary demuxer in ffmpeg
[06:39] <Compn> call it mpegts2 or something
[06:39] <Compn> maybe it will demux some files better or worse than our demuxer
[06:53] <nevcairiel> Luckily no one listens to you. :)
[06:56] <Compn> so its better just to ignore possibly better code ?
[06:56] <Compn> we do nothing > nothing improves
[06:56] <Compn> we do code duplication > someone gets annoyed enough to port changes
[06:57] <Compn> troll development 101.
[06:57] <Compn> i remember some complaints about mpegts stuff over the years
[06:57] <nevcairiel> Just copying some code doesn't improve anything
[06:58] <nevcairiel> Find stuff that doesn't work and improve what we have
[07:00] <wm4> makes me want to grab mythtv's ffmpeg and diff it
[07:00] <Compn> nevcairiel : you looked at mpegts.c ? :)
[07:00] <nevcairiel> Often
[07:00] <nevcairiel> Have you?
[07:01] <Compn> no not at all
[07:01] <Compn> wm4 : do it. post giant diff :)
[07:04] <wm4> how many libraries did they fork
[07:04] <wm4> libmythbluray...
[07:13] <Compn> well when you start collecting internal libs.... and the externals are either a) dead or b) change api or c) hate downstream ... its a tough habit to break
[07:13] <Compn> also when you modify them and optimize or fix and upstream rejects.
[07:19] <nevcairiel> I don't remember any rejected back ports on the ML, which means their last attempt to must be more than 2-3 years ago. A lot had changed in that time, and by now they are just a bitter uncooperative downstream
[07:20] <Compn> we have to make friends with all of those downstreams we burned years ago
[07:20] <Compn> cant abandon them now nevcairiel
[07:20] <nevcairiel> They abandoned us :P
[07:20] <wm4> oh no
[07:20] <wm4> they're cherry-picking
[07:21] <Compn> wm4 : are you saying theres no git magic to save us now ?
[07:21] <Compn> ehe
[07:22] <wm4> probably will lead to a huge diff, depending on stuff
[07:23] <wm4> I found this mysterious README.sync: http://sprunge.us/HCKZ
[07:23] <wm4> instead of leading it to git, they made some sort of changelog
[07:24] <Compn> closed caption support
[07:24] <Compn> didnt someone just ask about that
[07:25] <Compn> yes they did
[07:25] <Compn> now you know i'm going to have to post this ...
[07:25] <Compn> :)
[07:26] <j-b> they should use libvlc </compn>
[07:32] <wm4> this is the diff: http://sprunge.us/gTcY
[07:32] <wm4> from mythtv git head to ffmpeg 2.2.4
[07:33] <wm4> I think my ffmpeg git tree wasn't entirely clean, I hope no crap ended up in it
[07:34] <wm4> ff_codec_id_string
[07:34] <wm4> ????
[07:34] <j-b> I hope this is cleanly integrated and not rushed-in because "MOAR FEATURES"
[07:34] Action: Compn trolls j-b extreme
[07:35] <Compn> one suggestion and everyone freaks out :\
[07:35] <Compn> j-b : we are already reviewing the diff for useful items! 
[07:35] <j-b> Compn: sorry, but seeing some features getting merged...
[07:36] <Compn> when exactly did everyone become so against new features ?
[07:36] <Compn> its a strange argument
[07:36] <wm4> vlc prefer to NIH the easy bits
[07:36] <j-b> wehn you started merging EVERYTHING
[07:36] <j-b> wm4: right.
[07:37] <j-b> wm4: and your ref for this is?
[07:37] <j-b> Compn: when you arrive to get 3 prores decoders and 2 prores encoders...
[07:37] Action: Compn lols
[07:37] <j-b> Compn: or merging code producing non-standard files
[07:38] <Compn> the prores thing has reasons
[07:38] <Compn> good reasons!
[07:38] <wm4> j-b: such as you being against subtitle support, because it just adds potential for bugs and because vlc already has its own subtitle code
[07:38] <j-b> wm4: I'm clearly not against subtitles support
[07:38] <j-b> I'm against bad subtitles support
[07:38] <wm4> :)
[07:38] <j-b> and I'd love to get rid of VLC subtitles code
[07:39] <j-b> the less code I need to maintain, the best it is.
[07:39] <wm4> cue to ubitux blaming Libav for "needing" to use the bad subtitle API
[07:39] <j-b> but, seriously, subtitles decoders are very simple
[07:39] <j-b> issue is rendering
[07:40] <wm4> there's a library with a nice name for that
[07:40] <j-b> really ?
[07:40] <j-b> I doubt it.
[07:41] <wm4> (libass)
[07:41] <j-b> There is a library that depends on fontconfig
[07:41] <j-b> aka, not an option
[07:41] <wm4> libass is working on it
[07:41] <j-b> sure
[07:41] <j-b> it's not there yet
[07:41] <wm4> blame the lazy contributors
[07:41] <wm4> for OSX there's a working branch but with problems
[07:42] <j-b> yeah, so, there is nothing I can use now
[07:42] <j-b> 07:36 <+wm4> vlc prefer to NIH the easy bits
[07:42] <wm4> for windows there's an idea, but the one working on it has time for it only in 10 years
[07:42] <j-b> and this is not NIH
[07:42] <j-b> it was in VLC before
[07:42] <wm4> sure, that was a sarcastic joke at best
[07:42] <wm4> (same as the 10 years)
[07:42] <Compn> now mpv dev is trolling vlc dev :P
[07:42] <Compn> ehe
[07:43] <j-b> Compn: but yeah, so no libavfilter for me
[07:43] Action: wm4 slaps Compn 
[07:43] <Compn> j-b : fine, have fun reinventing stereo3d :P
[07:44] <Compn> wm4 : i'm trying to get libavfilter into vlc :P
[07:44] <j-b> Compn: maybe one day, you will split the repos like I suggested a long time ago
[07:44] <j-b> and stop violating libav* boundaries
[07:45] <Compn> those boundaries are more like guidelines
[07:45] <Compn> is there an actual rule about them somewhere ?
[07:45] <wm4> so yeah, the largest addition in the mythtv patch is a new mpeg-ts demuxer, probably based on the old one
[07:46] <wm4> plus some dvb stuff, plus random hacks and fixes all over the place
[07:46] <wm4> +libavformat/mov.c               // Fix http streaming of iPhone videos (Fix from xbmc)
[07:46] <wm4> that one is pretty funny
[07:46] <j-b> Compn: making more libraries depend on libavcodec. is not fun
[07:47] <wm4> a fix that traveled from xbmc's internal copy to mythtv's...
[07:47] <j-b> wm4: and will get merged into mplayer's copy, then merged into ffmpeg, then backported in libav
[07:47] <wm4> j-b: IMO filters would be better implemented as a standard API (think avisynth/ladspa/etc.), rather than a repo that tries to accumulate everything
[07:47] <wm4> lol
[07:47] <Compn> mplayer doesnt have internal copy anymore...
[07:47] <Compn> git copy now
[07:47] <j-b> wm4: I agree, of course
[07:48] <nevcairiel> My fork probably has more changes than theirs, pfff amateurs
[07:48] <wm4> Compn: it's still built as internal copy
[07:48] <wm4> right, nevcairiel has his own fork
[07:48] <j-b> wm4: and resampler shouldn't be there either
[07:48] <Compn> i wonder what changes ffmbc has...
[07:48] <wm4> with ordered chapters
[07:48] <wm4> j-b: that's needed for automatic conversion filters, but I find them evil too
[07:48] <j-b> Compn: ffmbc has mostly mov, mp4 and mxf massive changes
[07:48] <wm4> just how many fucking forks are there
[07:48] <j-b> wm4: so? why does libavcodec or so need conversion filters?
[07:49] <Compn> wm4 : tons.
[07:49] <nevcairiel> ffmbc abused the GPL to make back porting impossible though
[07:49] <wm4> j-b: oh, thought you talked about lavfi
[07:49] <wm4> lavc depends on resampling?
[07:49] <Compn> j-b : would you be happy if we duplicated all code around so each libav* was easily seperated ?
[07:49] <Compn> pfft not abusing gpl but whatever
[07:49] <nevcairiel> wm4: opus decoder uses av/swresample
[07:50] <wm4> meh.
[07:51] <nevcairiel> Compn: that clause of the LGPL is BS. You can fork a LGPL project and then make it so that the original project can't benefit from your changes. Good free software!
[07:52] <wm4> j-b: what I envision is a set of API definitions to allow freestanding filters (and maybe more), plus a support library for basic data structures (ffmpeg-independent AVFrame replacement)
[07:52] <Compn> nevcairiel : just more ifdef enable_gpl .... i dont see problem with it :P
[07:52] <wm4> the incompatibilities between the various GPL licenses are the greatest failures of the GPL
[07:53] <Compn> also talking with baptiste a few times, he seems willing to go lgpl
[07:53] <Compn> or maybe i have misunderstood his replies
[07:54] <j-b> wm4: libavfi depends on libavcodec, libavcodec depends on resample, lavf depends on lavc (this cannot be done differently)
[07:55] <Compn> j-b  :we combine it all and call it libffmpeg , similar to libvlc no ?
[07:55] <j-b> Compn: but that's not what you do.
[07:55] <j-b> if you did, maybe
[07:55] <Compn> i mean would it be ok ?
[07:55] <Compn> ok
[07:55] <nevcairiel> These days lavfi at least shouldn't have a hard dep on lavc anymore
[07:55] <nevcairiel> Only if you use one of the specific filters that use it
[07:56] <j-b> Compn: it was my major point when I said you should split the gits
[07:56] <wm4> on the other hand, I see no big point in actually separating lavc and lavf
[07:56] <Compn> i probably forgot your solution j-b
[07:57] <j-b> wm4: well, agreed
[08:00] <wm4> also, I guess one "problem" with split repo is that FATE is also part of the repo
[08:00] <wm4> I guess it would have to be part of the repo that houses ffmpeg.c
[08:00] <Compn> talking about just splitting lavc into its own git repo? what would it do ?
[08:01] <wm4> it would bring peace and harmony
[08:01] <Compn> oh
[08:01] <Compn> somehow i doubt
[08:02] <Compn> maybe if someone took over as admin and referee/babysitter
[08:02] <wm4> aka maintainer? (??)
[08:08] <Compn> thanks for the diff wm4
[08:08] <Compn> wonder what xbmc's fork diff looks like
[08:09] <nevcairiel> They keep individual patches in a folder, iirc
[08:09] <j-b> wm4: ffmpeg.c should be in a different repo
[08:10] <Compn> probably i agree with that 
[12:23] <cone-860> ffmpeg.git 03Diego Biurrun 07master:d35b94fbabd8: avcodec: Rename xvidmmx IDCT to xvid
[12:23] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:3841f2ae665d: Merge commit 'd35b94fbabd8beb5d566c0b5d01688aff62c3b36'
[12:52] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:25eeff960030: avcodec/avdct: add "xvid" alias AVOption and use FF_IDCT_XVID
[14:55] <kierank> 6:56 AM <"j-b> Compn: it was my major point when I said you should split the gits --> you'd have to make libav do that
[14:55] <kierank> otherwise ffmpeg can't
[14:58] <wm4> lol
[15:12] <viperfx_> Is there any way to improve the speed of the avformat_open_input() call for an HTTP stream? Does FFmpeg need to read all of it before it can proceed?
[15:14] <michaelni> viperfx_, submit a bugreport to trac if opening http takes unreasonably long
[15:14] <wm4> viperfx_: first I'd try to confirm how much data it really reads
[15:15] <wm4> it can vary; e.g. I had cases where the probing ruins web radio streams, while in other cases it's minimal
[15:19] <viperfx_> Sorry I did not mean stream as in live. I meant its a file. But its a mp4a in DASH container
[15:19] <viperfx_> It seems to take 4-6s to complete that call. That time suggests that it is reading the whole file.
[15:19] <wm4> there's some issue in the mov demuxer that makes it read dash files completely
[15:20] <wm4> yeah
[15:20] <wm4> AFAIK you can work it around by disabling indexing
[15:20] <wm4> I haven't bothered to track down why it happens, though
[15:20] <viperfx_> how can I do that?
[15:21] <wm4> unfortunately, I forgot
[15:21] <wm4> it's some weird avoption
[15:21] <viperfx_> ok I will track it down.
[15:22] <wm4> I think a generic one (not specific to mov/mp4, just interpreted by it)
[15:39] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:f75786f3bc88: avformat/avio: Fix "warning: struct AVBPrint declared inside parameter list"
[17:45] <ubitux> beastd: ping
[19:12] <cone-860> ffmpeg.git 03Anton Khirnov 07release/0.10:187cfd3c13a1: eamad: use the bytestream2 API instead of AV_RL
[19:12] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:d60f680fa741: Merge commit '187cfd3c13a1deb47661486824a5b8f41e158a7a' into release/0.10
[19:19] <cone-860> ffmpeg.git 03Diego Biurrun 07release/0.10:e4fdfdf65d52: vf_select: Drop a debug av_log with an unchecked double to enum conversion
[19:19] <cone-860> ffmpeg.git 03Bernhard Übelacker 07release/0.10:277103e07fbe: video4linux2: Avoid a floating point exception
[19:19] <cone-860> ffmpeg.git 03Diego Biurrun 07release/0.10:28f2d3c5a5a3: cmdutils: Conditionally compile libswscale-related bits
[19:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:c4dabc38a3a2: Merge commit 'e4fdfdf65d520ce3af13a21ff8a3649e37757af8' into release/0.10
[19:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:f3ae90621e03: Merge commit '277103e07fbe22fc8e4361bacd5c6b48133f3ba5' into release/0.10
[19:19] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:cdfd61b78ba6: Merge commit '28f2d3c5a5a3a3c14a68cf691054f15e4f23355a' into release/0.10
[19:33] <ubitux> kierank: avr is way less tested than swr in ffmpeg
[19:34] <cone-860> ffmpeg.git 03Diego Biurrun 07release/0.10:976f2e0a542e: x86: Fix linking with some or all of yasm, mmx, optimizations disabled
[19:34] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:a465ed5707f5: pgssubdec: Check RLE size before copying
[19:34] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:184c79729d40: h264_sei: check SEI size
[19:34] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:2c10833d5e4c: Merge commit '976f2e0a542e47aaf68ddbe001fb70a00bf96d99' into release/0.10
[19:34] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:5404bf29c3b7: Merge commit 'a465ed5707f5cbc9713d5e9629d424cd2d46e038' into release/0.10
[19:34] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:330791c2ae2b: Merge commit '184c79729d4011f33027bcdc61a63d521017ebc1' into release/0.10
[19:38] <ubitux> kierank: did you find your issue with opus/swr?
[19:38] <kierank> no
[19:38] <kierank> it's something to do with float_dsp I think
[19:38] <kierank> not sure if swr uses float dsp, need to check
[19:39] <kierank> ubitux: i mean avr should be enabled to allow people to use it
[19:39] <kierank> certainly the assembly is much better  than swr
[19:39] <ubitux> how so?
[19:41] <kierank> I guess it got fixed but there was a lot of inline asm
[19:42] <ubitux> there isn't anymore yes
[19:42] <ubitux> did you make any benchmark?
[19:45] <nevcairiel> swr has some more assembly though, it should be faster when resampling
[19:45] <kierank> well i need to figure out how i can get a crash dump that is usable from it
[19:49] <cone-860> ffmpeg.git 03Vittorio Giovara 07release/0.10:7585a6254bbb: h264: prevent theoretical infinite loop in SEI parsing
[19:49] <cone-860> ffmpeg.git 03Janne Grunau 07release/0.10:3e60501f311c: h264: slice-mt: check master context for valid current_picture_ptr
[19:49] <cone-860> ffmpeg.git 03Mans Rullgard 07release/0.10:50493f1f7d22: twinvq: fix out of bounds array access
[19:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:0a83007ceee4: Merge commit '7585a6254bbb38148e4467793fc34211b79d5f7d' into release/0.10
[19:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:b5ae0e349adc: Merge commit '3e60501f311c50bf234033f206c19d34d889df01' into release/0.10
[19:49] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:2ec8e46550dc: Merge commit '50493f1f7d2235db811d2991b9e5b330baf7c05a' into release/0.10
[19:51] <nevcairiel> Libav did bump now, if someone has some quick ABI changes, now is the chance :p
[19:52] <jamrial> i already sent some patches with the objective of cleaning the .v files so we stop exporting internal functions
[19:52] <nevcairiel> The constness change we used yo hide behind a define is probably one thing that can be enabled after the bump
[19:53] <jamrial> what we need to check is which of the deprecated stuff we have that libav doesn't we want to postpone or let die right now
[19:54] <nevcairiel> Their goal was to keep API in place and only do a few ABI changes
[19:54] <ubitux> ./ffmpeg -i ~/samples/audio/april02.flac -ar 8000 -f null -  4.61s user 0.10s system 312% cpu 1.508 total
[19:54] <ubitux> ./ffmpeg -i ~/samples/audio/april02.flac -ar 192000 -f null -  9.92s user 0.21s system 156% cpu 6.480 total
[19:54] <ubitux> ./avconv -i ~/samples/audio/april02.flac -ar 8000 -f null -  5.91s user 0.03s system 99% cpu 5.942 total
[19:54] <ubitux> ./avconv -i ~/samples/audio/april02.flac -ar 192000 -f null -  15.39s user 0.03s system 99% cpu 15.425 total
[19:54] <nevcairiel> They postponed like all API changes
[19:54] <ubitux> (not a proper benchmark, alright)
[19:54] <jamrial> i know at least one in lavc we have that libav doesn't (and thus didn't postpone) that's needed for on libmpcodecs filter
[19:55] <jamrial> *on a
[19:55] <ubitux> ./ffmpeg -i ~/samples/audio/april02.flac -ac 6 -f null -  3.90s user 0.11s system 380% cpu 1.054 total
[19:55] <ubitux> ./ffmpeg -i ~/samples/audio/april02.flac -ac 1 -f null -  4.19s user 0.11s system 451% cpu 0.952 total
[19:55] <ubitux> ./avconv -i ~/samples/audio/april02.flac -ac 6 -f null -  2.78s user 0.03s system 99% cpu 2.806 total
[19:55] <ubitux> ./avconv -i ~/samples/audio/april02.flac -ac 1 -f null -  2.69s user 0.01s system 99% cpu 2.709 total
[19:55] <nevcairiel> Still some libmpcodecs things left huh
[19:56] <ubitux> maybe the difference is not due to swr/avr, someone needs to make proper benchmarks
[19:56] <nevcairiel> I'm surprised the mixing would be so different. AFAIK only resampling is more optimized
[19:56] <ubitux> but i wouldn't say for sure avr asm is better than swr one
[19:56] <ubitux> maybe
[19:57] <jamrial> avresample has optimized 6 channel mixing afaik
[19:57] <ubitux> proper benchmark should be made
[19:57] <jamrial> whereas swr doesn't
[19:58] <ubitux> actually, decoding looks faster in ffmpeg, that might be reason
[19:59] <nevcairiel> FFmpeg has mt audio decoding for some codecs
[19:59] <ubitux> ah, threading :)
[20:00] <jamrial> and if that's a 24bits flac, pengvado added x86 asm earlier this year
[20:01] <ubitux> no, s16 here
[20:01] <nevcairiel> I never got the point of mt audio though, but apparently it can help a bit
[20:01] <ubitux> it definitely helps yeah
[20:02] <kierank> as usual when i want opus/swr to crash I can't make it crash
[20:02] <nevcairiel> I disable it on principle though :P
[20:12] <ubitux> ok avconv is faster @ -ac 6 but fails at other mostly (slightly faster at -ac 1 but might be per chance): http://pastie.org/pastes/9458271/text
[20:12] <ubitux> i should probably use a longer audio
[20:17] <jamrial> you could instead use ffmpeg compiled first with lavr and then swr to make sure differences in decoding are not affecting the benchmarks
[20:17] <ubitux> i'm not sure how to test avr properly in ffmpeg
[20:18] <ubitux> we don't use the same filters
[20:18] <ubitux> ideally some C code should actually be written :p
[20:18] <ubitux> anyway that's not a serious benchmark
[20:19] <ubitux> the resampling in avr is disturbing though
[20:22] <ubitux> mmh, threading dctdnoiz is actually going to be a bit tricky..
[20:29] <cone-860> ffmpeg.git 03Diego Biurrun 07release/0.10:4a6622550a4a: huffyuv: Check and propagate function return values
[20:29] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:e17dc0a254ac: mmvideo: check horizontal coordinate too
[20:29] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:a1804df66a40: huffyuvdec: check width size for yuv422p
[20:29] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:7d42ede8fec4: Merge commit '4a6622550a4a4bf4690ea7d9fe42210a30a67936' into release/0.10
[20:29] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:e719bfc403df: Merge commit 'e17dc0a254ac8d3c33887a114a66e2b659ba0bc5' into release/0.10
[20:29] <cone-860> ffmpeg.git 03Michael Niedermayer 07release/0.10:90241187ceb6: Merge commit 'a1804df66a4064aa30554a11e4fd6cdac3ed89c0' into release/0.10
[20:34] <cone-860> ffmpeg.git 03Clément BSsch 07master:d7594beedee3: avfilter/dctdnoiz: remove a few indirections in idcts
[20:41] <cone-860> ffmpeg.git 03Anton Khirnov 07master:4d1ff2a489f4: hevc: calculate the dbf strength in hls_pcm_sample() only if dbf is enabled
[20:41] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:adba796eb4a5: Merge commit '4d1ff2a489f4c60501b1a6a2d1f3874e61a77df9'
[20:45] <michaelni> if avr has some asm that swr is missing then it should be ported to swr
[20:57] <cone-860> ffmpeg.git 03Anton Khirnov 07master:65b8b6c47645: hevc_filter: drop redundant checks
[20:57] <cone-860> ffmpeg.git 03Anton Khirnov 07master:550197157857: hevc_filter: drop more redundant checks
[20:57] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:ca80c65726db: Merge commit '65b8b6c476454d201348737527a1d9471f689278'
[20:57] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:73e9d4cd6fa6: Merge commit '55019715785790836f60870180e1764b06e6591c'
[20:58] <ubitux> so, can anyone test & suggest nice freq denoising expression for dctdnoiz?
[21:01] <ubitux> currently it's just either a high pass or a custom expression
[21:01] <ubitux> if one or two expression appears to be interesting i could add them in a mode so it's faster than calling the eval api
[21:06] <michaelni> one could from a series of test images of "signal" and a series of noise images both representative of the actual signal and noise calculate the optimal scalar function for each coefficent
[21:08] <cone-860> ffmpeg.git 03Anton Khirnov 07master:70211539a39c: hevc: deobfuscate slice/tile boundary handling for DBF
[21:08] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:3f2495d98c26: Merge commit '70211539a39ca3854f8a9e97d51dc27caa079943'
[21:31] <cone-860> ffmpeg.git 03Anton Khirnov 07master:a7a17e3f1915: hevc_filter: move some conditions out of loops
[21:31] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:8d7c4cc08238: Merge commit 'a7a17e3f1915ce69b787dc58c5d8dba0910fc0a4'
[21:45] <ubitux> is the jobnr in the filter_slice callback supposed to be ordered?
[21:45] <ubitux> mmh my bad
[21:45] <ubitux> stupid question
[22:00] <michaelni> kierank, do you provide security support for avr and do maintain it ?
[22:01] <michaelni> if not i think you shouldnt suggest people to use it
[22:01] <michaelni> because i dont 
[22:01] <michaelni> and iam not sure who else in ffmpeg does
[22:01] <michaelni> if someone does, then thats ok of course
[22:04] <michaelni> kierank, also if you have an issue with swr, please tell me more about it so i can fix it
[22:10] <kierank> michaelni: daemon404 uses it
[22:10] <kierank> For many millions of viewers every day
[22:10] <kierank> I can't because the crash entirely smashes the stack frame
[22:10] <michaelni> did you try asan ?
[22:12] <kierank> No
[22:12] <michaelni> also is it known if any & which asm function is responsible ?
[22:12] <michaelni> asan might be worth a try
[22:13] <kierank> It crashed in emms
[22:13] <michaelni> did it work with cpuflags 0 ?
[22:14] <kierank> Yes
[22:14] <kierank> It was on a live stream using the api
[22:14] <jamrial> didn't you say that in the end the crash was in floatdsp and not swr?
[22:15] <kierank> Not sure but it was in the opus decoder somewhere
[22:15] <kierank> Which uses both
[22:15] <michaelni> if it works with cpuflags 0 then one can "bisect" which asm function causes it
[22:16] <michaelni> by disabling asm functions
[22:16] <michaelni> isnt 100% reliable though if theres a random factor
[22:16] <cone-860> ffmpeg.git 03Anton Khirnov 07master:52a2c17ec006: hevc_refs: drop the handling of negative coordinates in ff_hevc_get_ref_list()
[22:16] <cone-860> ffmpeg.git 03Anton Khirnov 07master:7acdd3a1275b: hevc_filter: avoid excessive calls to ff_hevc_get_ref_list()
[22:17] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:5a3a83f01df0: Merge commit '52a2c17ec006282f388071a831dfb21288611253'
[22:17] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:499ff6a05259: Merge commit '7acdd3a1275bcd9cad48f9632169f6bbaeb39d84'
[22:17] <jamrial> floatdsp doesn't seem to use mmx at all, only sse or 3dnow. swr uses mmx and calls emms only if you have pre sse2 cpus (or force mmx with cpuflags) and only with 32 bits builds
[22:18] <michaelni> kierank, if you suspect its swr, you also could also put a fprintf(stderr before the swr calls in opus and see what is the last printout before it crashes
[22:18] <michaelni> maybe that points to something
[22:18] <nevcairiel> The emms may be a red herring
[22:19] <michaelni> kierank, also enable asserts at level2
[22:20] <michaelni>  --assert-level=2
[22:20] <kierank> How do I do that on the api?
[22:21] <nevcairiel> Its a build option
[22:21] <kierank> Oh
[22:21] <kierank> Didn't crash at work but I will try at home in 1hr
[22:26] <cone-860> ffmpeg.git 03Anton Khirnov 07master:f4c444e17d13: Postpone API-incompatible changes until the next bump.
[22:26] <cone-860> ffmpeg.git 03Michael Niedermayer 07master:3e41d2e61221: Merge commit 'f4c444e17d137c786f0ed2da0e5943df505d5f9e'
[22:44] <jamrial> michaelni: will we postpone any of the ffmpeg-only FF_API deprecations?
[22:46] <j-b> Anyone heard anything about DxVA breakage lately?
[22:48] <j-b> kierank: FYI, libavcodec-ffmpeg plugin is 2MB more than libavcodec-libav plugin for VLC 2.2.0-pre1
[22:55] <Daemon404> j-b, wtf adds 2 mb
[22:56] <kierank> Libavcodec only...
[22:56] <kierank> Wtd
[22:56] <kierank> Wtf
[22:56] <ubitux> iirc ffmpeg has something like 100.000 lines of additional code, but that's not lavc specific
[22:57] <ubitux> also, http://lucy.pkh.me/diff/diff-codecs.html
[22:57] <Daemon404> thats not 2mb
[22:57] <michaelni> jamrial, feel free to suggest it on the ML
[22:58] <kierank> ubitux: what is up with ac3 fixed end?
[22:59] <kierank> Enc?
[22:59] <ubitux> dec
[22:59] <ubitux> "ENCODER" ’ "ENCDEC"
[23:00] <kierank> Yeah hard to read on my phone
[23:02] <j-b> Daemon404: I do not know.
[23:02] <j-b> Daemon404: I will check if iconv got in, maybe?
[23:02] <Daemon404> ah.
[23:02] <j-b> kierank: and I will do the usual testing of both  :)
[23:02] <Daemon404> why would you build wiht iconv if you dont use libav* for subs
[23:02] <Daemon404> or lavfi or w/e
[23:03] <j-b> Daemon404: exactly, that would be braindead
[23:03] <j-b> Daemon404: nope, I pass --disable-iconv
[23:03] <Daemon404> o ok
[23:03] <Daemon404> beats me
[23:03] <j-b> Daemon404: but it could have been the case, because of pkg-config-somethign
[23:04] <Daemon404> lol.
[23:04] <ubitux> given the number of additionnal codecs we have, it doesn't sounds that surprising to have 2 additionnal MB
[23:06] <ubitux> about 8k lines of assembly too, but that might not be that huge on the final size
[23:06] <ubitux> (x86)
[23:07] <j-b> ubitux: like which codecs?
[23:07] <ubitux> 22:57:08 <@ubitux> also, http://lucy.pkh.me/diff/diff-codecs.html
[23:07] <j-b> lol
[23:07] <j-b> xvmc, vdpau
[23:07] <jamrial> hevcdsp_init.o alone is 220kb after stripping
[23:07] <jamrial> in libav it's a couple kb at most
[23:07] <j-b> because some people refuse to read the hwaccel doc
[23:07] <j-b> 3prores decoders
[23:08] <ubitux> no
[23:08] <j-b> jamrial: that is a better point, indeed. and probably DSD has new tables
[23:08] <j-b> jamrial: plus some encoders
[23:10] <ubitux> j-b: there are 2 decoders, and 2 encoders
[23:10] <nevcairiel> I agree about the hwaccel stuff, but some people just can't let go
[23:10] <j-b> ubitux: that too much
[23:10] <ubitux> it appears there are 3 encoders, but "prores" is aliased on "prores_aw"
[23:11] <nevcairiel> And those people can't even maintain it them self since they are not coders :P
[23:11] <ubitux> j-b: licenses & compatibility
[23:11] <Daemon404> nevcairiel, we know exactly who "those people" are
[23:11] <Daemon404> it's always the same people.
[23:11] <Daemon404> for everything
[23:11] <nevcairiel> Person in this case
[23:11] <Daemon404> :P
[23:11] <Daemon404> same source
[23:13] <nevcairiel> Speaking of DSD, I need to get a DSD DAC for work. Wonder if there is something not costing $1000 and above
[23:14] <Daemon404> lol DSD
[23:14] <Daemon404> why wuld you bother
[23:14] <nevcairiel> Because users care, and I get paid to care about what the users care about
[23:15] <iive> i kind of don't get your hwaccel rant.
[23:16] <nevcairiel> j-b: dxva works fine for me still
[23:52] <kierank> as usual when i need to debug the crasb the crash goes
[00:00] --- Sun Aug 10 2014