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

[burek]

[00:16:06 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:2ccc1b304e08: MAINTAINERS: add key fingerprint
[01:06:06 CET] <rcombs> BBB: do you think working out memory allocations in the init API should block merging the patch series?
[01:06:13 CET] <rcombs> since it doesn't actually create a leak as-is
[01:17:42 CET] <BBB> rcombs: no, not really
[01:17:48 CET] <BBB> rcombs: Im fine with the patches as-is
[01:17:51 CET] <rcombs> cool
[01:18:00 CET] <BBB> I think the interface is a little complex
[01:18:05 CET] <BBB> I mean, its a callback driven thing
[01:18:12 CET] <BBB> but I cant think of anythinh simpler that is not stupid
[01:18:38 CET] <BBB> (stupid being probably incomplete after we use it a couple of times)
[01:19:02 CET] <BBB> you probably thought more about that than I did already anyway
[01:19:29 CET] <rcombs> I really just crammed it in with interleaving because it fit well there
[01:19:44 CET] <rcombs> since we've already got all the buffering it needs
[01:20:38 CET] <rcombs> and in theory it stays flexible enough that you could inspect a few packets before making up your mind
[01:40:39 CET] <BBB> I think its fine to go in, Id like to use it and write my own bsfs
[01:40:57 CET] <BBB> (which I know I can do anyway, but the point is that theyre required in certain scenarios and this allows me to enforce that)
[01:49:14 CET] <rcombs> which contexts, out of curiosity?
[01:49:48 CET] <rcombs> (and I'm still kinda afraid to push things so I'm waiting on someone to do that)
[03:07:17 CET] <BBB> rcombs: vp9_parser splits superframes into frames, Id like a bsf that reverses that so we can properly mux vp9 into webm as speced
[03:07:34 CET] <BBB> (and maybe vp9_parser should be a bsf also; demuxers can already insert bsfs, right?)
[08:06:35 CET] <atomnuker> development of libfaac seems to have ceased and the webpage linked in doc/encoders.texi is dead
[08:09:10 CET] <atomnuker> will remove it when I push the rewritten AAC encoder documentation (as well as glorifying it wherever relevant :)
[08:23:14 CET] <JEEB> :)
[08:23:44 CET] <JEEB> yeah, libfaac only got a few updates over its lifetime
[08:53:51 CET] <durandal_1707> will push sdx2 patch shortly
[09:47:28 CET] <__gb__> wm4, I believe the reason behind #define ALIGN in libavu/mem.c is explained below in av_malloc() and the 32 for HAVE_AVX is just a heuristic to match cache lines in a way Gramner exposed. Just a guess
[09:48:14 CET] <__gb__> what I want is: all video AVFrames to have page-alignment and 64-byte strides for more efficient interop with GPU or other video processors
[09:50:00 CET] <__gb__> having an av_buffer_alloc2() with explicit alignment or additional flags is interesting to me
[09:50:20 CET] <__gb__> that way we could also foresee cases when we need sharedmem for bitstream buffers for example
[09:50:38 CET] <__gb__> (out-of-process, or other needs :))
[09:50:59 CET] <__gb__> I would tend to option 2 too
[09:54:35 CET] <wm4> well, AVBufferRef can be constructed from existing memory, and custom free functions
[09:56:04 CET] <__gb__> well, that's not about vaapi business to allocate such memory, but to use it wherever applicable
[09:56:23 CET] <__gb__> it could also be user allocated pages, with such requirements, we can import them afterwards
[09:57:44 CET] <wm4> in any case, at most this heuristic should be in av_frame_get_buffer, not av_malloc - though there are a bunch of places where AVFrames are allocated using other methods (like libavcodec allocs planes itself from a buffer pool)
[10:01:06 CET] <__gb__> yes, the option 2 was about libavutil/frame.c changes + av_buffer_alloc2() or something similar
[10:32:23 CET] <cone-207> ffmpeg 03Paul B Mahol 07master:035ae3c0096f: avcodec: add SDX2 DPCM decoder
[10:32:23 CET] <cone-207> ffmpeg 03Paul B Mahol 07master:ff1e44b01ef7: avformat/thp: set duration for audio stream too
[11:26:21 CET] <ubitux> TEST    aac-pns-encode
[11:26:23 CET] <ubitux> stddev:  666.58 PSNR: 39.85 MAXDIFF:10110 bytes:  1675800/  1679360
[11:26:25 CET] <ubitux> stddev: |666.58 - 695| >= 25
[11:26:27 CET] <ubitux> is this known?
[11:26:57 CET] <ubitux> ah, asan is not happy
[11:28:14 CET] <ubitux> but just the test failing normally
[11:28:58 CET] <ubitux> aren't most fate instance dead since a while?
[11:29:14 CET] <ubitux> most fate instances seems to be at least 7 days old
[11:30:15 CET] <nevcairiel> seems to be michaels which are down for a couple days now
[11:30:34 CET] <ubitux> is fate-aac-pns-encode failing only for me?
[11:30:52 CET] <nevcairiel> oh wait, those that seem dead are building release branches
[11:31:08 CET] <nevcairiel> just no changes there
[11:31:27 CET] <nevcairiel> i wish the main listing wouldnt include those
[11:31:34 CET] <nevcairiel> for better overview
[11:32:06 CET] <nevcairiel> and yes, its only you ubitux
[11:32:09 CET] <nevcairiel> fate seems happy
[11:33:01 CET] <nevcairiel> asan lists it, maybe thats related
[11:33:06 CET] <nevcairiel> but all others are fine
[11:33:12 CET] <ubitux> yes, it's weird
[11:33:21 CET] <ubitux> but i have the issue locally too
[11:33:26 CET] <ubitux> without asan
[11:40:31 CET] <ubitux> how much stddev are you supposed to get on this test btw? around 695?
[11:43:38 CET] <ubitux> http://b.pkh.me/aac-pns-encode.wav.gz  this is what i obtains; can someone send me a wav that works?
[11:44:41 CET] <durandal_1707> what compiler?
[11:45:29 CET] <ubitux> gcc 5.2.0
[11:49:48 CET] <nevcairiel> 695 +/- 25, obviously
[11:49:54 CET] <nevcairiel> so 670-720
[11:53:17 CET] <nevcairiel> is there a way for fate to preserve the intermediate files
[11:59:14 CET] <nevcairiel> ubitux: http://files.1f0.de/tmp/aac-pns-encode.zip
[11:59:58 CET] <nevcairiel> the stddev of that file is 684.85
[12:00:28 CET] <nevcairiel> stddev:  684.85 PSNR: 39.62 MAXDIFF:11573 bytes:  1675800/  1679360
[12:06:12 CET] <nevcairiel> BBB: bsf's shouldnt be needed for demuxer->decoder operation, thats the job of the parser, so the vp9_parser being a parser is perfectly fine
[12:07:05 CET] <nevcairiel> (they both do somewhat of a similar job, to be honest)
[12:09:59 CET] <wm4> generally bsf is never used for demuxer->decoder, except internally in some decoders, while we have an infra structure to put parsers between demuxer and decoder
[12:13:24 CET] <durandal_1707> can parser do both audio and video at once?
[12:13:44 CET] <wm4> no
[12:15:33 CET] <cone-207> ffmpeg 03Ganesh Ajjanagadde 07master:68a0a164d1f6: avfilter/vf_removegrain: replace qsort with AV_QSORT
[12:26:28 CET] <BBB> nevcairiel: ok, thats fine with me, but I will still need the inverse operation as a bsf for going from copy/encoder->muxer
[12:26:38 CET] <BBB> (assuming bsf is the right way to do that)
[12:34:59 CET] <nevcairiel> BBB: sure that works as bsf
[13:33:34 CET] <cone-207> ffmpeg 03Michael Niedermayer 07master:4f00d2357720: tests/fate/aac: Add bitexact flags to fate-aac-pns-encode
[14:16:49 CET] <ubitux> nevcairiel: thanks
[14:16:55 CET] <ubitux> michaelni: ah, so you got the issue too?
[14:17:35 CET] <nevcairiel> its a stddev comparison, shouldnt that only take audio data into account, how does minor version modify it
[14:18:30 CET] <ubitux> nevcairiel: your file is getting more and more different over time, it's fun
[14:18:33 CET] <ubitux> (from mine)
[14:20:49 CET] <nevcairiel> sounds like fun?
[14:21:08 CET] <ubitux> i can't tell the difference with my ears though
[14:21:58 CET] <ubitux> i can ear how this sample is a nice audio stress btw
[14:25:10 CET] <nevcairiel> theoretically your file is better, isnt it
[14:25:17 CET] <nevcairiel> higher psnr, lower stddev
[14:25:37 CET] <nevcairiel> lower maxdiff
[14:25:46 CET] <nevcairiel> so whats your secret?
[14:25:46 CET] <nevcairiel> :D
[14:30:29 CET] <ubitux> nevcairiel: it's fixed by the bitexact commit from michael& maybe it's using some asm code doing better averaging that the C or something?
[14:30:53 CET] <nevcairiel> there is no reason my system wouldnt use all the asm thats available
[14:31:03 CET] <nevcairiel> unless its 3dnow =p
[14:31:17 CET] <ubitux> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
[14:31:18 CET] <ubitux> rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
[14:31:21 CET] <ubitux> do you have all of this? @_@
[14:32:02 CET] <nevcairiel> well its a haswell, so i would hope so
[14:32:10 CET] <ubitux> ok
[14:32:18 CET] <nevcairiel> no really new relevant instructions since then
[14:32:28 CET] <nevcairiel> still weird
[14:32:32 CET] <nevcairiel> should grep for the bitexact flag
[14:32:33 CET] <ubitux> CPUFLAGS=none doesn't help
[14:32:40 CET] <ubitux> so i guess it's unrelated
[14:33:55 CET] <ubitux> maybe a swr resampling happening?
[14:34:24 CET] <nevcairiel> aacenc writes encoder ident info into the bitstream
[14:34:36 CET] <nevcairiel> but presuambly there is an actual audio difference, and not just that, right?
[14:34:55 CET] <michaelni> maybe 9->10 results in a difference in bit allocation
[14:34:59 CET] <ubitux> i doubt ident would affect stddev & psnr :p
[14:35:13 CET] <michaelni> as its one byte longer
[14:35:22 CET] <michaelni> but just guessing
[14:35:33 CET] <nevcairiel> avpriv_float_dsp_alloc has a bitexact param
[14:35:36 CET] <nevcairiel> but its only used on ppc
[14:35:37 CET] <nevcairiel> :D
[14:36:46 CET] <nevcairiel> i suppose its possible that the ident info causes the bit distribution to be different
[14:37:29 CET] <nevcairiel> make note: set bitexact in $work code for more bits for audio
[14:40:09 CET] <ubitux> indeed, if i remove put_bitstream_info(s, LIBAVCODEC_IDENT), it fixes fate
[14:40:24 CET] <ubitux> madness
[14:41:23 CET] <ubitux> maybe it does trigger a different bitrate adjustment?
[14:41:41 CET] <nevcairiel> yeah it seems to use the full frame size in some conditions, including this
[14:45:40 CET] <nevcairiel> guess that makes sense then
[14:53:00 CET] <kierank> rcombs: "0.612 +- 1.857" --> that's odd
[15:12:18 CET] <cone-207> ffmpeg 03Vittorio Giovara 07master:8c2214822052: timecode: Do not fail for non-standard framerates
[15:12:18 CET] <cone-207> ffmpeg 03Vittorio Giovara 07master:63ea8e0610d0: timecode: Support HFR values
[15:13:08 CET] <Daemon404> "high frame rate" is 100+ now?
[15:13:21 CET] Action: Daemon404 wonders who owns such panels
[15:13:48 CET] <nevcairiel> what panels
[15:13:49 CET] <Daemon404> besides /r/pcmasterrace
[15:13:57 CET] <nevcairiel> my screen does 144hz
[15:14:21 CET] <Daemon404> none of mine do
[15:14:36 CET] <nevcairiel> most newer TVs will do 120hz
[15:14:44 CET] <thardin> do we have variable frame rate yet?
[15:14:51 CET] <Daemon404> they can *do* 120 hz yet
[15:14:59 CET] <Daemon404> but can you feed it that?
[15:15:03 CET] <ubitux> TIL nevcairiel plays CS
[15:15:12 CET] <Daemon404> many tvs onyl do 120hz in their own motion interpolation
[15:15:15 CET] <Daemon404> not actual 120fps content
[15:15:52 CET] <nevcairiel> actually with a bunch of them you can feed ti that too
[15:15:54 CET] <JEEB> all of the new broadcast specs for 120fps seem to note that they'd be separate parts of the bit stream
[15:16:03 CET] <JEEB> so you either decode a 60fps or 120fps stream
[15:16:13 CET] <nevcairiel> isnt that this hevc thing
[15:16:16 CET] <nevcairiel> shvc?
[15:16:28 CET] <Daemon404> i thought shvc was for spatial res
[15:16:41 CET] <nevcairiel> hm right
[15:16:47 CET] <JEEB> I think it was indeed some sort of scalable thing
[15:16:48 CET] <nevcairiel> hevc also has this concept of temporal layers
[15:16:51 CET] <JEEB> ENOTSURE though
[15:16:52 CET] <nevcairiel> where you can decide only to decode one
[15:16:57 CET] <JEEB> and yeah, temporal layers
[15:17:18 CET] <Daemon404> will it be just as used as SVC was?
[15:18:00 CET] <JEEB> well I don't think SVC got into broadcast specs too much...
[15:19:00 CET] <Daemon404> tests/Makefile:209: recipe for target 'fate-aac-ltp-encode' failed
[15:19:00 CET] <Daemon404> make: *** [fate-aac-ltp-encode] Error 1
[15:19:04 CET] <Daemon404> wut
[15:19:21 CET] <Daemon404> the .err file has 0 useful info
[15:19:46 CET] <wm4> (does it ever)
[15:20:17 CET] <Daemon404> stddev: 1522.74 PSNR: 32.68 MAXDIFF:19476 bytes:  1675800/  1679360
[15:20:18 CET] <Daemon404> stddev: |1522.74 - 1535| >= 10
[15:20:26 CET] <Daemon404> atomnuker, ^ :?
[15:20:41 CET] <nevcairiel> try setting the bitexact flag
[15:21:05 CET] <Daemon404> it is set
[15:21:17 CET] <Daemon404> /home/daemon404/dev/f/ffmpeg/ffmpeg -nostdin -nostats -cpuflags all -flags +bitexact -fflags +bitexact -hwaccel none -threads 1 -thread_type frame+slice -i /home/daemon404/dev/f/ffmpeg/tests/data/fate/aac-ltp-encode.adts -c:a pcm_s16le -fflags +bitexact -f wav -
[15:21:21 CET] <Daemon404> from V=1
[15:21:32 CET] <nevcairiel> thats the decode
[15:21:34 CET] <nevcairiel> i meant the encode
[15:22:00 CET] <Daemon404> that sounds a tad silly
[15:22:03 CET] <Daemon404> but ok
[15:22:11 CET] <nevcairiel> read discussion of the last hour
[15:22:13 CET] <Daemon404> oh
[15:22:16 CET] <Daemon404> so its known?
[15:22:27 CET] <nevcairiel> just set it and see if it helps
[15:22:32 CET] <nevcairiel> if it does, you may co mmit a patch
[15:22:33 CET] <nevcairiel> =p
[15:23:32 CET] <Daemon404> im nto actually sure where/when to add it
[15:23:38 CET] <Daemon404> theres flags, fflags, and a few positions
[15:23:54 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=4f00d235772064f2bdd471260763a2c951c4a2ae
[15:23:58 CET] <nevcairiel> copy what that patch did
[15:24:18 CET] <nevcairiel> (since the patch we kinda figured out why its needed, so no longer unknown)
[15:24:45 CET] <Daemon404> yeah
[15:24:47 CET] <Daemon404> now it passes
[15:25:14 CET] <nevcairiel> we may want to mass-add that for all aac tests just to get it over with
[15:25:20 CET] <Daemon404> probably.
[15:29:33 CET] <ubitux> ffs fate-aac-ltp-encode also fails now
[15:29:44 CET] <nevcairiel> (read up)
[15:29:56 CET] <ubitux> heh yeah...
[15:30:13 CET] <Daemon404> ill push a fix along with this patch i was testing
[15:32:22 CET] <cone-207> ffmpeg 03Tinglin Liu 07master:9ea812692c38: mov: Add support parsing QuickTime Metadata Keys.
[15:32:23 CET] <cone-207> ffmpeg 03Derek Buitenhuis 07master:a7fcc43bcc8c: tests/aac: Add bitexact flags to AAC LTP Encode test
[15:34:02 CET] Action: Daemon404 pokes nevcairiel for a merge sometime soon-ish (next 1-2 days)
[15:34:21 CET] <nevcairiel> didnt see anything interesting
[15:34:28 CET] <Daemon404> theres one patch i need =p
[15:34:48 CET] <nevcairiel> which
[15:34:55 CET] <Daemon404> e02dcdf6bb6835ef4b49986b85a67efcb3495a7f
[15:35:04 CET] <Daemon404> wait wrong hash
[15:35:07 CET] Action: Daemon404 stabs clipboard
[15:35:14 CET] <Daemon404> 5ea5a24eb70646a9061b85af407fcbb5dd4f89fd
[15:38:00 CET] <canaar> Hello is anyone up?
[15:39:58 CET] <Daemon404> dont ask to ask, ask
[15:41:16 CET] <canaar> I started reading ffplay.c 2 days ago. 
[15:41:30 CET] <canaar> Where can I get to know what algorithms are exactly used ?
[15:42:09 CET] <Daemon404> uh, wut?
[15:42:20 CET] <Daemon404> that is an incredibly vague question
[15:42:32 CET] <Daemon404> algorithms for what part, etc
[15:42:36 CET] <Compn> canaar : do you want the algorithms from the codecs, or from the various cryptographies ?
[15:43:20 CET] <Compn> also , i dont think we wrote down most of the algorithms in the code, i could be wrong
[15:43:38 CET] <Compn> easier to find the algorithms on wikipedia..
[15:44:15 CET] <Compn> sorry, i'm thinking of equations.
[15:44:21 CET] Action: Compn needs food
[15:44:38 CET] <canaar> I want to learn how ffplay works, so before directly reading the code, should I read how it works
[15:44:52 CET] <Daemon404> there is no such document.
[15:44:59 CET] <canaar> Oh I see
[15:45:14 CET] <Daemon404> nobody in the world outside of academi is going to write a document that descriebs exactly how their entire codebase works
[15:45:16 CET] <canaar> There is one for ffserver
[15:45:18 CET] <Daemon404> academia*
[15:45:30 CET] <Daemon404> i am not aware of one for ffserver
[15:45:33 CET] <Daemon404> so its news to me
[15:45:59 CET] <wm4> what part/aspect of ffplay do you want to know how it works?
[15:46:07 CET] <Daemon404> i already asked taht
[15:46:09 CET] <Daemon404> that*
[15:46:14 CET] <ubitux> probably refering to http://ffmpeg.org/ffserver.html#toc-Detailed-description
[15:46:22 CET] <canaar> Exactly
[15:46:49 CET] <ubitux> there is no complex concept to describe for a player
[15:46:58 CET] <ubitux> so http://ffmpeg.org/ffplay.html ...
[15:47:34 CET] <ubitux> (from a user perspective i meant)
[15:48:12 CET] <canaar> Okay. What are the very basic things involved in a media player?
[15:48:42 CET] <ubitux> canaar: http://ffmpeg.org/ffmpeg.html#Detailed-description
[15:48:47 CET] <ubitux> player does the top part of that
[15:48:59 CET] <kierank> what do you actually want to learn about a player
[15:49:03 CET] <ubitux> demux+decode, and renders the decoded stuff
[15:49:22 CET] <ubitux> (with eventually filtering, described below)
[15:49:42 CET] <canaar> I see.
[15:55:06 CET] <cone-207> ffmpeg 03Clément BSsch 07master:7794627032e9: avcodec/avdct: remove redundant "default" information in options
[15:55:07 CET] <cone-207> ffmpeg 03Clément BSsch 07master:90c4ccc629a3: avcodec/options: remove redundant and wrong default information for skipcmp option
[15:55:08 CET] <cone-207> ffmpeg 03Clément BSsch 07master:51ee62d50b19: avcodec/options: remove a few more redundant "default" information
[15:55:25 CET] <ubitux> the ac3 enc options are really weird
[15:55:35 CET] <ubitux> that "default" thing
[15:56:22 CET] <ubitux> there are bool-like options (on/off) with a "notindicated" value, and with a default which is actually even different
[15:56:33 CET] <nevcairiel> those are all single metadata flags, which can be set to 1/0, or just not included in the bitstream, which can have a different meaning
[15:56:52 CET] <ubitux> "notindicated" is actually 0
[15:56:59 CET] <ubitux> which means "off"
[15:57:15 CET] <nevcairiel> weird
[15:57:17 CET] <ubitux> so it could be dropped and replaced with a bool+auto
[15:57:28 CET] <nevcairiel> but their default is -1
[15:57:32 CET] <ubitux> yes
[15:57:33 CET] <ubitux> "none"
[15:57:35 CET] <ubitux> :P
[15:57:39 CET] <ubitux> #define AC3ENC_OPT_OFF              0
[15:57:42 CET] <ubitux> #define AC3ENC_OPT_NOT_INDICATED    0
[15:58:48 CET] <nevcairiel> -1 triggers auto defaults in the code
[15:58:55 CET] <nevcairiel> instead of just setting these defaults in the opt table
[15:58:56 CET] <nevcairiel> oh well
[15:59:13 CET] <ubitux> sometines there is a on/off an more value
[15:59:14 CET] <nevcairiel> a bunch of those employ other conditions, apparently
[15:59:23 CET] <ubitux> like dsurex_mode
[15:59:36 CET] <ubitux> anyway, fun stuff
[15:59:56 CET] <nevcairiel> just let it be :D
[16:00:19 CET] <ubitux> well, i wanted to drop the "(default)" thing
[16:00:32 CET] <ubitux> (because it's redundant since displayed in the help)
[16:00:42 CET] <ubitux> but for those... it's a bit special
[16:00:44 CET] <ubitux> anyway
[16:01:11 CET] <ubitux> i'm going to calm down my ocd and move on
[16:01:39 CET] <Daemon404> dsurex_mode <-- i read that as durex_mod...
[16:01:40 CET] <Daemon404> mode*
[16:02:04 CET] <ubitux> i read 3 times what i wrote to avoid writing that mistake
[16:02:19 CET] <Daemon404> hah
[16:07:40 CET] <Daemon404> i guess saying 'ffserver' is liek saying beetlejuice 3 times...
[16:08:16 CET] <nevcairiel> dont we have some developer that feels responsible for ffserver these days
[16:11:36 CET] <Compn> yes, i thought so
[16:35:48 CET] <Daemon404> it disturbs me that someone may use ffserver for real things
[16:37:28 CET] <nevcairiel> they probably dont know any better
[16:39:19 CET] <Stormsys> Sorry im not sure if this is the right channel, but i want to understand how ffmpeg calculates a streams bitrate when delaing with an mp4?
[16:39:34 CET] <Stormsys> i ask becaue im getting slight variances on what im expecting
[16:40:17 CET] <Stormsys> For instance whjen im expecting 160000 im getting 159997
[16:42:39 CET] <wm4> Stormsys: it's in libavformat/utils.c
[16:42:48 CET] <wm4> (probably)
[16:48:12 CET] <Stormsys> Just had a look through that, im refering to AVCodecContext ->bit_rate (in relation to AVStream)
[16:48:23 CET] <Stormsys> but i guess its a question about libav in that case then?
[16:51:25 CET] <wm4> uh what do you mean?
[16:52:36 CET] <Stormsys> wm4, to be very specific, im actually having an issue with tools/ismindex.c it reads an mp3, loads a AVStream that has a AVCodecContext, the bit_rate value in there i need to understand how it is obtained as it sppears to be off
[16:54:06 CET] <Stormsys> seems to use avformat_open_input to get the model in the first place.
[16:54:34 CET] <Stormsys> which does appear to be in libsbgotmsy/utils actually let me read through it
[17:24:18 CET] <Daemon404> wtf is libsbgotmsy
[17:24:37 CET] <Daemon404> oh shifted keys
[17:25:33 CET] <martijnb> xD
[17:25:52 CET] <martijnb> you actually caught that pretty quick, took me a minute
[18:21:29 CET] <kierank> lol RHEL
[18:21:31 CET] <kierank> and ffmpeg 0.6
[18:22:06 CET] <Compn> why do distros maintain these old releases?
[18:22:08 CET] <Compn> whyyyy
[18:35:13 CET] <JEEB> Compn: are you implying it's maintained?
[18:48:03 CET] <rcombs> jamrial: whoops re: absolute path in fate file
[19:01:20 CET] <wm4> uh so I wanted to look at adding something like a proper uint64 AVOption type
[19:01:27 CET] <wm4> but AVOption.min/max are double
[19:01:56 CET] <wm4> which is where my endeavor ends
[19:11:38 CET] <durandal_1707> wm4: can't you add new 128 bit fields?
[19:12:15 CET] <durandal_1707> or interpret it like uint64?
[19:12:38 CET] <JEEB> lol
[19:13:53 CET] <wm4> well there's this patch that does
[19:13:54 CET] <wm4> +            *(uint64_t *)dst = (llrint(num/den - (INT64_MAX + 1ULL)) + (INT64_MAX + 1ULL))*intnum;
[19:52:02 CET] <atomnuker> ubitux, Daemon404: looking into it now
[20:46:54 CET] <rcombs> michaelni: (yes)
[21:18:56 CET] <cone-207> ffmpeg 03Kyle Swanson 07master:dcb95ef48255: avfilter: add vibrato filter
[21:57:00 CET] <ubitux> durandal_170: did you check if vibrato really works with inplace buffers?
[21:57:39 CET] <ubitux> maybe i'm misreading but i'm afraid it's going to read values it's rewriting
[21:57:46 CET] <durandal_170> isn't that default?
[22:01:26 CET] <ubitux> writable frames?
[22:01:39 CET] <ubitux> it really depends
[22:01:48 CET] <ubitux> perms=random is your friend to test this :p
[22:01:53 CET] <ubitux> (with some logging to make sure)
[22:17:03 CET] <durandal_170> i tried ro and rw and md5 is same
[22:20:29 CET] <peloverde> Anyone have a good understanding of what's going on with the vpx bool coder probability ranges? BBB?
[22:20:53 CET] <BBB> ?
[22:21:17 CET] <BBB> can you be more specific on what youre trying to do?
[22:21:40 CET] <BBB> are you trying to compare libvpx w/r->range with some ffmpeg equivalent?
[22:21:50 CET] <BBB> or something else?
[22:22:16 CET] <peloverde> I'm trying to understand how to interpret p = 0, to build compatible tables for a new entropy coder
[22:23:54 CET] <peloverde> The textual description the the vp8 spec says 0 <= p <= 255, and the probability should be interpreted as p/256
[22:24:06 CET] <BBB> p=0 is the same as p=1
[22:24:09 CET] <BBB> it has no meaning basically
[22:24:36 CET] <peloverde> okay
[22:25:04 CET] <BBB> (Im not saying thats a good thing or thats how it should be)
[22:25:16 CET] <BBB> (it wastes 1/256th of your value range)
[22:25:19 CET] <BBB> (but thats what it does)
[22:26:07 CET] <BBB> in your new one, will the actual float p[0,1] be linear over the p[0,255] range? or will you apply a beta function or something like that?
[22:26:12 CET] <BBB> (thats what cabac does)
[22:26:41 CET] <BBB> (or, well, not a beta, I dont actually know what it does, btu at least its not linear, it has higher density in the more-often occurring range, by some metric or whatever)
[22:26:42 CET] <peloverde> some of the code seems to be written as if 0 and 255, 1 and 254, etc are complements, and some as if 1 and 255, 2 and 254, etc.
[22:26:56 CET] <BBB> yeah, thats because nobody knew :D
[22:27:07 CET] <BBB> but for the actual coder, 1 and 255 are complements, I believe
[22:27:35 CET] <peloverde> In what I'm looking at 0 will be invalid, mostly becuase I don't want to put a bunch of divide by 257 in the decoder
[22:27:46 CET] <BBB> fair enough
[22:28:14 CET] <peloverde> thanks for the info
[22:28:28 CET] <BBB> yeah, I tried that at some point, the realworld cost of encoding total garbage data 1s or 0s is identical for p:0 and 256-p:1
[22:48:58 CET] <BBB> does anyone know of a tool that if I give it a y4m file and a text file (or whatever format) with motion vectors, it can visualize the mvs on the frame for me? I guess kind of like -debug +mv but with self-created mvs instead of using ffmpegs me
[23:01:25 CET] <ubitux> BBB: doc/examples/extract_mvs?
[23:01:47 CET] <ubitux> not sure what you want actually
[23:02:01 CET] <BBB> the inverse of -debug +mv
[23:02:12 CET] <BBB> or the mvvis filter
[23:02:25 CET] <ubitux> codecview does display mvs
[23:02:27 CET] <BBB> so I want it to show a list of mvs that I made up
[23:02:33 CET] <BBB> instead of ones in the file
[23:02:40 CET] <ubitux> if you set them in the frame side data
[23:02:44 CET] <ubitux> by whatever means
[23:03:19 CET] <TD-Linux> I don't know of any, I'd just write one. I wrote one for daala https://github.com/tdaede/jirojiro
[23:22:21 CET] <rcombs> michaelni: in your failed test there, does tests/data/fate/lavf-fate-crypto.err show anything wrong?
[23:25:52 CET] <michaelni> rcombs, it likely will list a missing .pgm file that hasnt been generated, will have to retest
[23:26:20 CET] <michaelni> does it work for you if you do a make distclean and make fate-lavf-fate-crypto ?
[23:26:56 CET] Action: rcombs tries
[23:32:18 CET] <michaelni> rcombs, "ffmpeg/tests/vsynth1/%02d.pgm: No such file or directory"
[23:32:25 CET] <rcombs> ahhh
[23:33:03 CET] <michaelni> and before that "Could find no file with path 'ffmpeg/tests/vsynth1/%02d.pgm' and index in the range 0-4"
[23:34:15 CET] <rcombs> michaelni: not sure how to add that dependency
[23:38:24 CET] <michaelni> look at how other tests that use such files do, i dont remember how exactly its done
[23:56:54 CET] <rcombs> michaelni: how's this look? https://gist.github.com/fbdf6b31bcc6a02bc9a9
[23:59:29 CET] <michaelni> if that fixes it then sure 
[00:00:00 CET] --- Tue Oct 27 2015