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

[burek]

[00:18] <cone-756> ffmpeg.git 03Vignesh Venkatasubramanian 07master:5a206569468a: lavf/matroska: Add functions for WebM DASH Manifest
[00:18] <cone-756> ffmpeg.git 03Vignesh Venkatasubramanian 07master:3e73d1429045: lavf: Add WebM DASH Manifest Muxer
[00:18] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:e240d01c120e: avformat/matroskadec: fix declaration after statement
[00:18] <cone-756> ffmpeg.git 03James Almer 07master:ad24256e7e9f: diracdec: remove unused dsputil context
[00:41] <cone-756> ffmpeg.git 03Hanspeter Niederstrasser 07master:04980dbee805: avdevice/avfoundation: kCVPixelFormatType_OneComponent8 only exists from 10.8 onward
[00:41] <cone-756> ffmpeg.git 03Marc Jeffreys 07master:a0b71e9f3e95: avfilter/drawtext: Add basic text shaping using libfribidi
[00:54] <cone-756> ffmpeg.git 03Marc Jeffreys 07fatal: ambiguous argument 'refs/heads/release/2.3': unknown revision or path not in the working tree.
[00:54] <cone-756> Use '--' to separate paths from revisions
[00:54] <cone-756> refs/heads/release/2.3:HEAD: avfilter/drawtext: Add basic text shaping using libfribidi
[01:41] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:cf92cc8751bb: avcodec/hevc: clear HEVClcList[i] on allocation
[01:59] <cone-756> ffmpeg.git 03Michael Niedermayer 07release/2.3:cf92cc8751bb: avcodec/hevc: clear HEVClcList[i] on allocation
[01:59] <cone-756> ffmpeg.git 03Michael Niedermayer 07release/2.3:7fa72ff19cc0: update for FFmpeg 2.3
[02:02] <cone-756> ffmpeg.git 03Michael Niedermayer 07release/2.3:e32249605456: RELEASE_NOTES: update version numbers
[02:08] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:13a72d9b08c9: doc/APIchanges: update
[02:08] <cone-756> ffmpeg.git 03Michael Niedermayer 07release/2.3:2678b2509910: doc/APIchanges: update
[02:08] <jamrial> michaelni: change  "version <next>" to "version 2.3" in the release/2.3 changelog file
[02:08] <jamrial> also in master for that matter
[02:10] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:faafd1e4f1fc: Changelog: change  "version <next>" to "version 2.3"
[02:10] <cone-756> ffmpeg.git 03Michael Niedermayer 07release/2.3:bc4f6ae88e5f: Changelog: change  "version <next>" to "version 2.3"
[02:11] <michaelni> jamrial, done thx, would have forgotten that one probably
[02:15] <Timothy_Gu> michaelni: do you think after this release we should change RELEASE to 2.4.git? Currently it's 2.2.git, and it is uncommon that 2.2.git > 2.2.5
[02:21] <michaelni> no objections from me
[02:29] <jamrial> BBB: the patch merely moves draw_edges from one context to another. it doesn't change any decoder or encoder behavior
[02:29] <jamrial> BBB: h264, vp8 and vp9 have nothing to do with it. they don't depend on draw_edges afaics
[02:30] <jamrial> unless i'm missing something...
[02:31] <BBB> jamrial: exactly
[02:31] <BBB> jamrial: so right now, a ffmpeg built with just vp8, vp9 and h264 (think chrome) does not include draw_edges
[02:31] <BBB> jamrial: your patch changes that, by moving it into a context used by vp8/vp9/h264
[02:31] <BBB> theyre not _using_ it, but its included in the binary
[02:31] <BBB> I dont want that
[02:32] <BBB> that old stuffy mpeg encoder code needs to stay where it is now; in the mpeg encoder
[02:32] <BBB> decoders shouldnt touch it
[02:32] <BBB> emu_edge is always faster
[02:34] <jamrial> i'm ok with any solution, really. i was merely following michaelni's suggestion to remove the mpegvideoenc dependency from snow and dirac decoders
[02:36] <michaelni> i suggested it as it seemed like the simplest way to improve it, i dont claim it leads to the best code independant of effort
[02:36] <jamrial> although i'm not going to remove the draw_edges usage from those two decoders myself. i'll let someone else do that if needed
[02:40] <Timothy_Gu_> michaelni: did you see my patch on RELEASE_NOTES? 2.3 won't be complete without it.
[02:42] <BBB> so does libavs dirac decoder depend on mpegenc?
[02:43] <BBB> or does libav not have a dirac decoder?
[02:44] <jamrial> looks like they don't have a dirac decoder at all
[02:44] <jamrial> only parser
[02:45] <kierank> they don't have a dirac decoder
[02:45] <kierank> there was a lot of cosmetic madness iirc that meant it never got merged
[02:45] <kierank> the guy got a bit fed up
[02:46] <wm4> lol, so that does happen
[02:46] <jamrial> yeah, no wonder diracdsp was untouched as part of all the dsputil massacre from the past few months
[02:47] <kierank> wm4: imo that gsoc was probably the worst
[02:47] <kierank> and it's got better now
[02:47] <wm4> cosmetic gsoc?
[02:47] <kierank> usually the commitors who care about the cosmetics do them now
[02:47] <kierank> wm4: people writing good code and then getting blasted for cosmetics
[02:50] <cone-756> ffmpeg.git 03Timothy Gu 07release/2.3:bef4d9bf87f7: RELEASE_NOTES: update
[02:52] <michaelni> Timothy_Gu_, applied, thx
[02:54] <Timothy_Gu_> Yeah. Most of their patches are like "LGTM, there are only 60 nits. Please fix them before pushing."
[02:55] <kierank> Timothy_Gu_: in the past yes
[02:55] <kierank> but these days no
[02:56] <Timothy_Gu_> because no new developers are coming to Libav, and the only new dev in the past 12 (?) months, koda, has been thoroughly trained to avoid DonDiego's blasts
[02:58] <michaelni> BBB, i can look into converting snow to emu_edge but not sure whe ive time
[03:00] <jamrial> for that matter, diracdec is calling ff_emulated_edge_mc_8 directly instead of using the function pointer from videodsp
[03:00] <jamrial> is there a reason for that?
[03:01] <jamrial> changing it to use the pointer doesn't break fate here
[03:01] <j-b> emu_edge \o/
[03:13] <BBB> jamrial: I worked on libav when I converted emu_edge to be a dsp function
[03:13] <BBB> jamrial: libav probably didnt have a dirac decoder back then
[03:13] <BBB> so it was naturally not converted when the patch was merged here
[03:14] <wm4>  [FFmpeg-devel] [PATCH] lavfi: check refcount before merging. <- wow this format negotiation stuff is hitler
[03:15] <BBB> godwins law!
[03:15] <BBB> :D
[03:15] <Daemon404> wm4, more like the SS
[03:15] <Daemon404> since lavfi is hitler
[03:16] <wm4> somehow this negotiation stuff is terribly complicated because it tries really hard to insert "optimal" conversion filters
[03:16] <Daemon404> you probably dont want to see dshow pin negotiation code
[03:16] <Daemon404> :P
[03:19] <jamrial> BBB: ah good. i'll send a patch changing it then
[03:19] <cone-756> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.3': unknown revision or path not in the working tree.
[03:19] <cone-756> Use '--' to separate paths from revisions
[03:19] <cone-756> refs/tags/n2.3:HEAD: Changelog: change  "version <next>" to "version 2.3"
[03:19] <Daemon404> dumb bot is dumb
[03:20] <Timothy_Gu> It has been like this for years if not months
[03:20] <Daemon404> cia.vc existed in the not so distant past.
[03:20] <kierank> wm4: all filter negotiation and/or reconfiguration is messy
[03:20] <Daemon404> be thankful the caller doesnt have to manually do negotiation
[03:20] <Daemon404> via some callback
[03:20] <Daemon404> or something
[03:21] <kierank> " IRC and Subversion have taken a back seat to Twitter and Github"
[03:21] <kierank> lol
[03:21] <kierank> development via twitter
[03:21] <Daemon404> im trying to deal with a github-tracker-only project right now
[03:21] <Daemon404> its pain.
[03:21] <kierank> IRC is still the best way to do collaborative development
[03:21] <Daemon404> worse because the entire community around it is super naive / wtf
[03:22] <Daemon404> (mozjpeg)
[03:22] <kierank> lol
[03:23] <Daemon404> im trying to help them out, but damn
[03:23] <Daemon404> i might just give up
[03:23] <j-b> twitter is the new IRC
[03:23] <j-b> lol
[03:23] <Daemon404> i thought that was hipchat
[03:24] <Daemon404> or is there somthing more hip now
[03:24] <kierank> I've not found anything better than IRC where I can just get people to click a button and visit my channel
[03:25] <wm4> obviously you should use facebook for development
[03:25] <jamrial> #bugsquashing #optimizing #testinginproduction #YOLO
[03:25] <kierank> I get people trying to friend me on facebook
[03:25] <jamrial> though YOLO is probably outdated by now
[03:25] <kierank> and then asking for help
[03:35] <Daemon404> oh
[03:35] <Daemon404> so thats where i remember this guy on mozjpeg from
[03:35] <Daemon404> https://github.com/vapoursynth/vapoursynth/issues/85
[03:35] <Daemon404> SIGH
[03:36] <wm4> lol
[03:36] <wm4> did he make the same post on mozjpeg or what
[03:36] <Daemon404> https://github.com/mozilla/mozjpeg/issues/66
[03:36] <Daemon404> that's this
[03:37] <Daemon404> there are far more annoyings things though
[03:37] <wm4> uargh
[03:37] <wm4> nnedi in a jpeg decoder?
[03:37] <Daemon404> in fucking cjpeg
[03:37] <wm4> *encoder
[03:38] <Daemon404> https://github.com/mozilla/mozjpeg/issues/21#issuecomment-48390582
[03:38] <Daemon404> and
[03:38] <wm4> Daemon404: I see you're trying hard to prevent his retarded ideas to make it into the project
[03:38] <Daemon404> https://github.com/mozilla/mozjpeg/issues/67
[03:38] <Daemon404> these anger me.
[03:39] <Daemon404> theyre breaking ABI silently and leaving it as libjpeg.so with the jpeg6 soname
[03:39] <Daemon404> silently.
[03:40] <kierank> is there anything that explains the mapping from av_opt to the values in avcodeccontext?
[03:42] <Timothy_Gu> kierank: lavc/options_table.h
[03:43] <kierank> ah thanks
[03:56] <BBB> jamrial: can you remove the prototype of ff_emulated_edge_mc_8_c from videodsp.h if we no longer need to expose it?
[03:56] <BBB> jamrial: unless its used in other palces
[03:56] <BBB> jamrial: (not sure, didnt check)
[04:01] <Timothy_Gu_> BBB: clang's static analyzer reports some dead code in vp9
[04:01] <BBB> uhm& ok
[04:01] <BBB> which?
[04:01] <Timothy_Gu_> http://50d2506d.ngrok.com/report-c92ac6.html http://50d2506d.ngrok.com/report-6e0817.html and http://50d2506d.ngrok.com/report-52fa84.html
[04:04] <jamrial> BBB: it's still being used by gmc_mmx, form MpegVideoDSPContext
[04:04] <jamrial> *from
[04:04] <BBB> the first two seem correct
[04:04] <BBB> yeah theyre all correct
[04:05] <BBB> Timothy_Gu_: patch to remove these is fine
[04:05] <BBB> jamrial: ah I see
[04:21] <cone-756> ffmpeg.git 03Vittorio Giovara 07master:14b4e64eabc8: g2meet: allow size changes within original sizes
[04:21] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:f00bb086cb97: Merge commit '14b4e64eabc84c5a5e57c8ccc56bbeb95380823b'
[04:21] <cone-756> ffmpeg.git 03James Almer 07master:b67a0e99ee82: diracdec: don't call ff_emulated_edge_mc_8 directly
[04:21] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:8156e036e527: avcodec/snowdec: remove mpegvideoencdsp dependency
[04:33] <Timothy_Gu_> BBB: I decided not to make a patch because that would decrease readability. If you wanna do this 3-line commit, go ahead.
[04:33] <BBB> why does it decrease readability?
[04:35] <Timothy_Gu_> like the one at l.2481 if I remove the unused h4 but leave w4 other people will be like "is this wrong?"
[04:35] <Timothy_Gu_> w4 is used
[04:35] <BBB> are those people that understand the fundamental nature of this video codec?
[04:35] <BBB> I mean, there is a topright but not bottomleft, so its obvious to me that you need a w but not a h variable for that
[04:36] <BBB> (unlike hevc, which has both)
[04:36] <Timothy_Gu_> OK, I have no idea what you are talking about, but sure, I'll send a patch
[04:36] <Timothy_Gu_> (I mean I understand it in words but not the function)
[04:37] <BBB> you know spatial (intra) prediction right?
[04:38] <Timothy_Gu_> nope :p
[04:39] <Timothy_Gu_> I haven't even read JPEG specs
[04:39] <BBB> hm...
[04:39] <BBB> ok
[04:39] <Timothy_Gu_> I know what Intra is though
[04:39] <BBB> so
[04:39] <BBB> intra prediction is taking edge pixels to predict a blocks content
[04:39] <Timothy_Gu_> what is a block?
[04:39] <Timothy_Gu_> a part of a frame?
[04:39] <Timothy_Gu_> what is a macroblock? a group of blocks?
[04:40] <BBB> the base subdivision unit of a frame in which the actual video content is coded
[04:40] <BBB> for h264, 16x16 is the base block unit size
[04:40] <Timothy_Gu_> ok
[04:40] <BBB> vp8 same
[04:40] <BBB> vp9/hevc its 64x64 -> 8x8 (with 4x4 support throug some hacks)
[04:40] <Timothy_Gu_> huh?
[04:40] <BBB> so to predict a block, you take edge pixels, apply a function over it, and thats the blocks predicted content
[04:40] <Timothy_Gu_> where did the 64 come from?
[04:41] <BBB> vp9/hevc have bigger blocks
[04:41] <BBB> basically gives better compression for some hd content
[04:41] <Timothy_Gu_> then how about 8?
[04:41] <BBB> for complex content
[04:41] <BBB> i.e. adaptive to content of frame
[04:41] <BBB> a 64x64 block can divide to 4 32x32 blocks, or be coded as-is
[04:41] <BBB> 32x32 -> 16x16 -> 8x8 -> (hacky) 4x4
[04:42] <Timothy_Gu_> ok, so HEVC allows any of those (64, 32, 16, 8, 4)?
[04:42] <BBB> yes
[04:42] <BBB> and the encoder will select what makes most sense given the content
[04:42] <BBB> for static motion (or no motion), youll likely get bigger blocks for hd content
[04:43] <BBB> for highly complex motion patterns, maybe smaller blocks
[04:43] <Timothy_Gu_> and then the block's predicted content is compared with the actual content?
[04:43] <Timothy_Gu_> and a "diff" is coded?
[04:43] <BBB> right, the difference is coded as transformed coefficients
[04:43] <BBB> diff = quantize(transform(src[]-pred[]))
[04:44] <BBB> and thats your basic video encoder right there
[04:44] <Timothy_Gu_> how does transform() work?
[04:44] <BBB> typically just a forward dct
[04:45] <Timothy_Gu_> how does DCT/Fourier transform work?
[04:46] <BBB> Id just read the wikipedia page :D
[04:46] <Timothy_Gu_> BTW I asked my homeroom teacher (who teaches AP Stats) once on Fourier transform for a "for dummies" definition, and he was like "oh I remember back in college I did a project on it. I'm pretty sure it is covered in multi-variable calculus"
[04:47] <BBB> its basically a function that finds frequency patterns in the set of difference values
[04:47] <BBB> so think of the coefficients as weights of sine wave functions
[04:47] <BBB> (ignore the 2d aspect for now, think just 1d)
[04:47] <BBB> so if I have an array of 4 diff values double x[4]
[04:47] <Timothy_Gu_> Then he pulled up the Wikipedia page (¡qué coincidencia!) that has a chart I absolutely don't understand
[04:48] <Timothy_Gu_> ok continue
[04:48] <BBB> and their values are like 0, 1, 1, 0
[04:48] <BBB> you can see this as a wave function that goes up towards the middle of the line, and down at the edges
[04:48] <BBB> now imagine that I predefined 4 sine wave functions with different frequencies
[04:49] <BBB> first DC (i.e. infinite wavelength), and the others something like pi/n wavelength (or maybe 2pi/n, I forgot), where n is 1, 2, 3
[04:50] <BBB> then the values (0,1,1,0 in this case, but really any set of values) can also be represented as a vector of 4 multipliers times each of these 3 wave functions (plus the one with infinite wavelength - the one I called dc)
[04:50] <BBB> in this case, the 0,1,1,0 have an average value of 0.5, so the weight of dc would be 0.5
[04:51] <BBB> then after I subtract that, Im left with -0.5, 0.5, 0.5, -0.5
[04:51] <BBB> and the 2pi/2 describes that quite well (if you assume the function is centered at the middle), again with a multiplier of 0.5 (if I assume the peak to be 1)
[04:51] <BBB> so then the coefficients are 0.5, 0, 0.5 and 0
[04:52] <BBB> for typical natural patterns, which are common in video, transforms decrease the amount of information that needs to be coded
[04:52] <BBB> the inverse transform is just the opposite, its basically multiply the wav functions bu the cofficients (multipliers), add them all up, and you have your original diff back
[04:52] <Timothy_Gu_> is transform lossless?
[04:53] <BBB> no
[04:53] <BBB> it can be
[04:53] <BBB> but dcts typically arent
[04:53] <BBB> vp9s dht (4x4) is lossless
[04:53] <BBB> dwt, sorry
[04:53] <BBB> h264s dht is maybe lossless?
[04:53] <BBB> but these are dct approximations that are changed to be less dct-like (thus worse compression) to become lossless
[04:54] <Timothy_Gu_> ok
[04:54] <BBB> also quantization is not lossless, so lossless dht/dwt only works for a quantizer of 1.0 (i.e. none)
[04:55] <BBB> vp8 has no lossless transform
[04:55] <BBB> Im honestly not sure about hevc
[04:56] <BBB> bedtime now, sorry...
[04:56] <Timothy_Gu_> how did -.5, .5, .5, -.5 become .5, .0, .5, .0 again?
[04:56] <Timothy_Gu_> last question
[04:57] <BBB> -.5, .5, .5, -.5 became the third coefficient
[04:58] <BBB> look at this image: http://en.wikipedia.org/wiki/Discrete_cosine_transform#mediaviewer/File:Dctjpeg.png
[04:58] <BBB> imagine that each small square boxed in red edges is a 2d sine function
[04:58] <BBB> just look at the top 8 (in fact, just the left 4 of the top row)
[04:58] <BBB> imagine now that white is 1.0, and black is -1.0
[04:59] <BBB> the topleft one is a sine function where all values are 1.0
[05:00] <BBB> the second one is a sine function that goes from 1.0 to -1.0, like 1.0, 0.4, -0.4, -1.0 or so
[05:00] <Timothy_Gu_> If all the values are the same, is it even a sine function?
[05:00] <BBB> with infinite wavelength, sure
[05:00] <Timothy_Gu_> ok
[05:00] <BBB> (but I mean, its a special case, yes)
[05:01] <BBB> the third one is something like 1.0, -0.7 -0.7, 1.0
[05:01] <BBB> and the fourth one is & 1.0, -1.0, 1.0, -1.0
[05:01] <BBB> makes sense?
[05:01] <Timothy_Gu_> So... are these "coefficients"?
[05:02] <BBB> no, these are the base functions
[05:02] <BBB> the coefficients are the multipliers times each of these base functions to get the diff
[05:02] <BBB> like a matrix multiplication (in fact, slow implementations of f/idct are like a matrix multiply)
[05:03] <BBB> so if your diff was 1.0, 1.0, 1.0, 1.0
[05:03] <BBB> you only need the first base function to describe this (multiplier=1.0)
[05:03] <BBB> the multipliers for the other base functions are 0
[05:03] <BBB> so your coefficients are then 1.0, 0.0, 0.0, 0.0
[05:03] <Timothy_Gu_> oh, now I get it
[05:03] <BBB> and so for more complex diff patterns youll use all 4 base functions with various coefficients
[05:04] <BBB> the typical effect is that the earlier coefficients are bigger and the later are smaller, so that after quantization, they are zero
[05:04] <cone-756> ffmpeg.git 03Michael Niedermayer 07master:aa1d096d027b: avcodec/snow: only allocate space for edges when encoding
[05:04] <BBB> which means you can code only nonzero ones and thus save space
[05:04] <BBB> thats why transforms help compression
[05:05] <BBB> instead of coding 4x4 pixels for a 4x4 block, you code only& say, 13, or 7, or even just 2
[05:05] <Timothy_Gu_> So if I understood correctly, DCT = avg all the members out -> use a wave form (or some wave forms) to simulate it by "assembling" different basic waves together
[05:06] <Timothy_Gu_> And then after DCT you quantize ~0 values as 0
[05:06] <Timothy_Gu_> ~ as in approximated
[05:10] <BBB> well, theyre not floating point values
[05:10] <BBB> theyre fixed point
[05:11] <BBB> so 1.0 would be like 1000, and 0.1 would be 100
[05:11] <BBB> then you use a quantizer
[05:11] <BBB> say my quantizer is 200
[05:11] <BBB> 1000/200=5
[05:11] <BBB> 100/200=0
[05:11] <BBB> so the 100 fell off the radar
[05:11] <Timothy_Gu_> ok, in floating point concept mine is correct, right?
[05:12] <BBB> yeah
[05:12] <BBB> and thats your basic fdct
[05:12] <BBB> idct is the same, but inverse
[05:12] <BBB> and dequant is just multiply coded coefficients by the quantizer value
[05:12] <BBB> so 5*200=1000, 0*200=0, etc.
[05:13] <BBB> I guess now is bedtime :-p
[05:13] <Timothy_Gu_> ok, thanks for everything
[05:14] <Timothy_Gu_> good night!
[05:14] <Timothy_Gu_> still 2 hours before my bed time
[05:15] <Timothy_Gu_> I gotta save this somewhere
[05:33] <fionag> if you have any other questions I can try to help!
[05:49] <Timothy_Gu_> fionag: thanks, but I think this is enough for today :D
[05:52] <fionag> okay :P
[05:52] Action: fionag looks at the log.   okay that is quite a lot
[08:43] <db0> Compn: about the .js files, this is just the recommended header so it works well on IE9 and I dont know exactly so we can also remove this part of the header, or we can download them locally. I assume it's recommended to include the url in case the content needs to be changed for some reason
[09:17] <ubitux> oh, --enable-memory-poisoning found an actual issue?
[09:17] <ubitux> cool
[09:25] <rrouton> hello everyone
[09:27] <rrouton> anyone here have any experience with the C/C++ libs?  I have written a decent transcoder in order to learn ffmpeg's api and was wondering if anyone knows how the memory works under the hood, specifically the buffering of av packets when using av_interleaved_write
[09:28] <rrouton> is it smart enough to know not to buffer anything before the stream if there is an audio frame adjacent to a video ?
[09:31] <rrouton> i am not sure I like this chat client (LimeChat)
[10:02] <plepere> morning
[11:46] <ubitux> frame side data doesn't have a variable size?
[11:46] <ubitux> :(
[13:03] <BBB> Timothy_Gu: thats actually a fair point, michaelni or #x264dev are good places to learn more (or write your own video decoder [or encoder?])
[14:38] <cone-165> ffmpeg.git 03Timothy Gu 07master:ea6178fff8ee: get_bits: remove unused assignment
[14:49] <cone-165> ffmpeg.git 03Timothy Gu 07master:9bc0410e4f89: vp9: remove unused assignment
[15:46] <ubitux> TIL i learned michaelni is a place
[15:50] <Daemon404> wat
[15:50] <Daemon404> also s/i learned //
[16:01] <gnafu> Daemon404: RIP in peace.
[16:02] <ubitux> Daemon404: yeah, i learned twice
[16:02] <Daemon404> ;p
[16:02] <ubitux> Daemon404: 13:03:19 <@BBB> Timothy_Gu: thats actually a fair point, michaelni or #x264dev are good places to learn more (or write your own video decoder [or encoder?])
[16:02] <Daemon404> o
[16:03] <Daemon404> how i learned to write a decoder in ffmpeg: cp simpledec.c mydec.c
[16:03] <Daemon404> then hack mydec.c
[16:03] Action: Daemon404 runs
[16:03] <ubitux> that's how you're supposed to write filters
[16:03] <ubitux> ;)
[16:03] <Daemon404> lol
[16:04] <Daemon404> the only thing i ever had trouble with in lavc was the vlc stuff
[16:04] <Daemon404> ff_init_vlc_sparse is confusing
[18:06] <nevcairiel> GCC 4.9.1 is out, anyone run a full fate on it yet?
[18:07] <JEEB> oh, finally_
[18:07] <JEEB> motherfucking finally I should say
[18:07] <JEEB> :V
[18:07] <JEEB> it should have at least the FLAC fix
[18:07] <JEEB> since that got backported to 4.9.x
[18:08] <Case> backported from what? Isn't 4.9.x latest branch?
[18:08] <JEEB> all fixes go into master first
[18:08] <JEEB> and then get backported
[18:08] <JEEB> because releases get branched off some time before release
[18:09] <JEEB> I think at the RC point
[18:10] <Case> no new lovely Windows packages at http://files.1f0.de/mingw/ or xhmikosr's site yet :(
[18:10] <JEEB> nev builds those :P
[18:10] <JEEB> and he probably wanted to know if anyone ran full FATE on it yet exactly for that
[18:11] <Case> damn you nevcairiel
[18:11] <Case> weren't those tests already ran with some earlier builds and confirmed that things work?
[18:13] <JEEB> yeah, but you want to make sure that the current state works
[18:22] <nevcairiel> Will take me a bit to build them, away from my systems for a couple more days
[18:24] <Daemon404> \o/
[18:25] <jamrial> i assume the celebrations are for gcc 4.9.1? :P
[18:26] <Daemon404> yes
[18:29] <Daemon404> that but title makes no sense...
[19:59] <ubitux> michaelni: -skip_idct is nice; anything working with h264?
[20:05] <michaelni> adding skip_idct support to h264 should be possible
[20:06] <wm4> what for
[20:06] <ubitux> wm4: see [RFC] avcodec: export MB information in frame side data
[20:07] <ubitux> tl;dr i'm looking for a way to avoid decoding the frames so the MV extraction doesn't need to be so slow
[20:08] <ubitux> and in my personal use-case i'm interested in h264 in particular
[20:08] <wm4> how is that useful
[20:08] <ubitux> > faster
[20:08] <ubitux> i don't need the frames, i just want the MV information
[20:08] <wm4> also prefixing the option name with sd_ is a bad idea
[20:08] <ubitux> ah?
[20:09] <ubitux> (it's not an option but a flag value)
[20:09] <ubitux> (so it won't be a -sd_mb_info, but -flags2 +sd_mb_info)
[20:12] <wm4> sd sounds like low resolution
[20:14] <ubitux> oh, mmh
[20:49] <cone-609> ffmpeg.git 03Diego Biurrun 07master:adff0a816634: arm: dsputil: Coalesce all init files
[20:49] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:21dfabfa6461: Merge commit 'adff0a8166345bb9513f0f658043fb6387e90122'
[21:04] <cone-609> ffmpeg.git 03Timothy Gu 07master:1b034483853b: aaccoder: remove unused assignment
[21:34] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:a3f752bcee4d: avcodec/snow: remove unused variables
[21:52] <cone-609> ffmpeg.git 03Ben Avison 07master:649c666137f4: armv6: Accelerate vector_fmul_window
[21:52] <cone-609> ffmpeg.git 03Ben Avison 07master:57641410d1a3: armv6: Accelerate butterflies_float
[22:56] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:7da2592f5677: avformat/md5enc: add format_version, to allow selecting which version to use
[22:57] <jamrial> michaelni: micro bump?
[23:12] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:37a0ac1d8227: avformat: Micro bump for "md5enc: add format_version, to allow selecting which version to use"
[23:12] <michaelni> jamrial, done thx
[00:00] --- Thu Jul 17 2014