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

[burek]

[01:12] <cone-123> ffmpeg.git 03Michael Niedermayer 07master:28dce3cdbc33: avcodec/alacenc: Remove unused variable
[01:29] <cone-123> ffmpeg.git 03Michael Niedermayer 07release/2.2:5df02760dd2f: update for 2.2.8
[01:53] <BBB> oh was/is vdd this weekend? do we get an executive summary?
[02:11] <cone-123> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.2.8': unknown revision or path not in the working tree.
[02:11] <cone-123> Use '--' to separate paths from revisions
[02:11] <cone-123> refs/tags/n2.2.8:HEAD: avcodec/alacenc: Remove unused variable
[11:11] <kierank> hmmm interlaced chroma upsample + normal scale won't work the way i propose
[11:12] <wm4> so ilpack is useful?
[11:15] <kierank> dunno let me implement and see
[11:36] <kierank> michaelni: will swscale understand the concept of chroma lying outside the plane?
[11:38] <kierank> http://i.msdn.microsoft.com/dynimg/IC500902.png
[11:38] <kierank> specifically in 420 mpeg-2
[11:38] <kierank> the second line has a chroma sample that lies above it
[11:47] <wm4> I thought swscale can now do arbitrary chroma posititioning, but not sure if it would go out of bounds in your case
[12:17] <JazzCZ> hi, where do i get the truehd patch?
[12:17] <wm4> Warning: Encountered more data after announced end of track (frame 14054/14054). Frankenstein!
[12:17] <wm4> ...
[12:18] <wm4> This was a Frankenstein track.
[12:18] <wm4> ^ how mpg123 handles concatenated mp3s
[12:18] <wm4> JazzCZ: this one? https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163189.html
[12:19] <JazzCZ> yes man, that is right
[12:20] <JazzCZ> yeah, that's what I mean
[12:24] <michaelni> kierank, ill push a fix for that in a moment
[12:31] <nevcairiel> considering the one Blu-ray that uses this feature wasn't even released yet, a lot of people sure seem to have pirated it :p
[12:34] <wm4> so is this yet another rarely used extension?
[12:34] <nevcairiel> who knows
[12:34] <nevcairiel> its new
[12:35] <nevcairiel> impossible to say how often it will be used
[12:38] <wm4> so I assume it's strictly optional, and the issue is really just that there was a parsing bug?
[12:38] <nevcairiel> yeah, plus that you need to skip the new data, as its not directly audio data
[12:39] <nevcairiel> they use the truehd substream to transport another compressed bitstream inside
[12:40] <nevcairiel> afaik, there is no software implementation of this yet, commercial or otherwise, the only way to decode it are external devices through HDMI streaming of the truehd stream
[12:41] <rcombs> is it actually more compressed audio data, or just channel mapping/panning meta?
[12:42] <nevcairiel> i assume its compressed audio data, its big enough for that at least. Its object-based audio data, which you can then render depending on your speaker configuration, i don't think you can reconstruct that from the other pcm streams
[12:43] <rcombs> fun
[12:44] <nevcairiel> its a fascinating concept for sure, but the problem is that you can never render that properly unless you have detailed information about the room and setup you're rendering to, which means you ideally need a measuring mic
[12:44] <nevcairiel> works for the HDMI AV Receivers, those come with mics usually anyway
[12:45] <rcombs> mine did!
[12:45] <wm4> lol really
[12:45] <wm4> fascinating
[12:45] <wm4> so they calibrate themselves
[12:45] <rcombs> it also only has 3 HDMI input ports, and can't convert analog video to HDMI, and can't play HDMI audio on its second zone
[12:46] <nevcairiel> the idea behind it is pretty good, why pre-render audio into 8 channels based on some fixed speaker setup when you can just encode the audio sources directly and do the mixing at the users end based on their actual physical setup
[12:46] <rcombs> wm4: mine only calibrated gain levels for each speaker with it
[12:47] <rcombs> and maybe some sort of phase-related thing I'm not remembering the details of
[12:47] <rcombs> I should probably recalibrate it
[12:47] <cone-560> ffmpeg.git 03Diego Biurrun 07master:103391ca90b2: dca: Remove some commented-out cruft
[12:47] <cone-560> ffmpeg.git 03Michael Niedermayer 07master:950ce21d4a7c: Merge commit '103391ca90b2f7c56ae756d76c76f7c3dfa28dd4'
[12:47] <nevcairiel> the high end models try to  adjust for the frequency response of the speakers as well
[12:47] <cone-560> ffmpeg.git 03Michael Niedermayer 07master:61af6bebb457: swscale: Allow chroma samples to be above and to the left of luma samples
[12:47] <cone-560> ffmpeg.git 03Michael Niedermayer 07master:e927682e1b25: avfilter/vf_scale: Allow chroma samples to be above and to the left of luma samples
[12:47] <rcombs> the mic itself also functioned as a decent desk microphone with a really long mono 3.5mm cable
[12:47] <nevcairiel> i would think with that long cable its prone to interference
[12:48] <rcombs> probably :3
[12:48] <rcombs> feel free to yell at yamaha
[12:48] <wm4> you can sell better cables separately to the audiophiles
[12:48] <nevcairiel> for calibration is probably fine, as he calibration sounds are pretty loud and would probably drown out any interference :P
[12:48] <rcombs> I'm not sure if a bit of EM interference would make a significant difference during calibrationyup
[12:50] <nevcairiel> those HDMI devices are not really targeted at the audiophiles anyway, they use separate USB DACs with their own amplifiers after
[12:50] <rcombs> that sounds dumb
[12:51] <nevcairiel> its really the same thing, only split in two devices, and no stupid HDMI
[12:51] <rcombs> meanwhile, I get users complaining about decoding AC3/DTS audio on their computers and sending to their receivers as PCM instead of passing it through on the HDMI cable
[12:51] <wm4> rcombs: of course
[12:51] <rcombs> because they think the receiver will somehow do a better job of decoding the audio than lavc, I guess?
[12:52] <wm4> rcombs: welcome to a world of pain
[12:52] <wm4> no
[12:52] <wm4> because they can't send PCM over their shitty link
[12:52] <nevcairiel> users are stupid like that, they need to see the light for bitstream decoding go on, or its not good sound
[12:52] <nevcairiel> wm4: even if they can, they dont want to
[12:52] <kierank> Dolby atmos is serious business
[12:52] <wm4> or maybe that isn't an issue anymore with actual HDMI
[12:52] <rcombs> wm4: HDMI can handle 8-channel PCM
[12:52] <rcombs> wm4: that was an issue with S/PDIF over coax
[12:52] <wm4> oh, good
[12:53] <wm4> there still might be issues with speaker config etc.
[12:53] <nevcairiel> the thing is, in my experience if you bitstream to the receiver, its typically a bit louder than sending PCM of the same audio
[12:53] <nevcairiel> and louder is perceived as better by most people
[12:53] <wm4> haha
[12:53] <wm4> I wonder if that's an intentional marketing trick
[12:53] <nevcairiel> no idea
[12:53] <rcombs> of course, then there are the audio streams that have embedded dynamic range compression information
[12:53] <wm4> but most likely it's just differences in remixing?
[12:54] <nevcairiel> might be lavc ignoring stuff like dialnorm or dr
[12:54] <rcombs> lavc parses dialnorm, though I'm not sure if it uses it
[12:54] <kierank> Doesn't use it
[12:54] <kierank> On some codecs DRC is applied
[12:55] <rcombs> of course, dialnorm is just stream-global fixed gain, so&
[12:55] <rcombs> that could indeed be why bitstreaming is sometimes louder
[12:57] <rcombs> and from what I've heard, DRC meta on DVDs and BDs is often really poorly-executed
[12:58] <rcombs> "<A> that will make it decode the TrueHD/DTS-MA streams to 7.1 LPCM. <B> yes but isnt that shit?" <-- actual (anonymized) conversation between two people who both supposedly knew what they were talking about
[12:58] <wm4> there was a patch for DTS-MA
[12:58] <wm4> but it's not bitexact yet, and now it appears to be bitrotting
[12:58] <nevcairiel> on windows i hijacked a binary decoder for dts-hd ma to make those people happy
[12:59] <JEEB> lol
[12:59] <rcombs> (A actually did; B took a fair bit of explaining to understand that PCM is, in fact, lossless)
[12:59] <wm4> <rcombs> of course, dialnorm is just stream-global fixed gain, so& <- could export that as replaygain data
[12:59] <nevcairiel> we get our fair share of audiophools on the support forum, i have to bite my tongue way too often
[12:59] <rcombs> wm4: huh, that could work
[13:00] <nevcairiel> WAV sounds better than FLAC, etc
[13:00] <wm4> rcombs: someone would just have to get the math right
[13:00] <rcombs> I wonder, how's it exported now?
[13:00] <wm4> which probably involves woodoo and secret constants
[13:00] <wm4> voodoo even
[13:00] <wm4> rcombs: side data
[13:00] <rcombs> "Dialnorm is an integer value with range 1 to 31 corresponding to a playback gain of -30 to 0 dB (unity) respectively"
[13:01] <rcombs> well that's simple enough
[13:02] <wm4> h
[13:02] <wm4> m
[13:04] <cone-560> ffmpeg.git 03Thomas Volkert 07master:6821a5a4adcb: rtpenc: HEVC/H.265 support
[13:05] <nevcairiel> but if its negative values, doesnt it make stuff quieter
[13:05] <nevcairiel> or i'm missing some part of it :D
[13:11] <rcombs> nevcairiel: I think it's meant to represent the average dialogue level in dBFS, so you'd apply (-dialnorm)dB of gain if you wanted dialogue level to match between multiple streams
[13:16] <rcombs> 'Dialnorm is defined in ATSC A/85 as An AC-3 metadata parameter, numerically equal to the absolute value of the Dialog Level, carried in the AC-3 bit stream. This unsigned 5-bit code indicates how far the average Dialog Level is below 0 LKFS. Valid values are 1-31. (zero value is reserved) The dialnorm values of 1 to 31 are interpreted as -1 to -31LKFS.'
[13:16] <wm4> holy wat https://github.com/git/git/pull/107
[13:16] <michaelni> Loriker, maintainers get OP in ffmpeg-devel and as you maintain rtpdec/enc_h261 and rtpdec_hevc, ...
[13:16] <rcombs> "The loudness unit of LKFS is dB and is used the same way as a dB of gain. For example, a -15 LKFS program can be made to match the loudness of a -22 LKFS program by attenuating 7 dB."
[13:17] <Loriker> okay, thx
[13:18] <rcombs> wm4: wat
[13:19] <wm4> I wonder why that repo has 15 PRs, even if the repo info says they accept no PRs
[13:20] <wm4> and then I saw this
[13:20] <wm4> oh well
[13:26] <rcombs> because ~Linus~
[14:23] <ubitux> heh, found this in an old mkv http://b.pkh.me/touch-ssa.ssa
[14:23] <ubitux> ("Command:" but not actually one)
[14:23] <ubitux> also "JACOsub" :)
[14:36] <wm4> ubitux: wat
[14:36] <ubitux> ah and finally found a mkv sample with some Marked=<X> thing in it
[14:37] <wm4> so it has a jacosub script embedded or so
[14:37] <wm4> as comment events
[14:37] <ubitux> wm4: no not really, it was probably converted and hackdjusted
[14:37] <ubitux> mmh wait yeah
[14:37] <wm4> so ass is inspired by jacosub? lol
[14:37] <ubitux> indeed it looks like jacosub
[14:38] <ubitux> wm4: yeah of course
[14:38] <wm4> lesson of history
[14:38] <ubitux> so yeah anyway there is some jacosub embedded in the comments for some reason
[14:39] <ubitux> but with ass markup
[14:39] <ubitux> i have no idea what's going on here
[14:39] <cone-560> ffmpeg.git 03Hendrik Leppkes 07master:ff34b2d6d35b: mlpdec: support major sync headers with optional extension blocks
[14:39] <cone-560> ffmpeg.git 03Hendrik Leppkes 07master:36bf549b2706: mlpdec: support TrueHD streams with an Atmos substream
[14:39] <ubitux> i see some jacosub timestamps
[14:40] <ubitux> oh whatever :)
[14:40] <wm4> yeah
[14:41] <ubitux> "Central Anime - Kansas - Fansubbing since 1992 -"
[14:42] <ubitux> yeah right ok.
[14:42] <nevcairiel> they started with vhs subbing
[15:18] <cone-560> ffmpeg.git 03wm4 07master:6c7f1155bb64: avformat/mp3dec: avoid early EOF with concatenated gapless mp3s
[15:18] <cone-560> ffmpeg.git 03Thomas Volkert 07master:dcdc1cbf4321: rtpdec_hevc: do not print an error message if the received packet has a valid header but lacks additional bytes as payload
[17:15] <cone-560> ffmpeg.git 03Pascal Massimino 07release/2.4:b7f271995137: libavcodec/webp: treat out-of-bound palette index as translucent black
[17:15] <cone-560> ffmpeg.git 03Gianluigi Tiesi 07release/2.4:3b57d7769a76: avcodec/libilbc: support for latest git of libilbc
[18:22] <ubitux> hum
[18:23] <ubitux> av_bprint_is_complete() should take a const parameter
[18:23] <ubitux> is it safe to change that without a major bump?
[18:24] <nevcairiel> personally i would say yes, adding a const to a parameter should be save, but i believe we tried that before and for some reason it was changed later to be version dependent and only activate on the bump
[18:24] <nevcairiel> although i have no clue as to why
[18:24] <ubitux> iirc last time it happened was because of cb pointers assignment or something along these lines
[18:25] <ubitux> i doubt something using a cb system on top of bprint is set up somewhere
[18:25] <ubitux> also, it's an inline function here
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:d210c0e777c1: avcodec/ass: add ff_ass_add_rect_bprint() helper
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:4c85073044a6: avcodec/jacosubdec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:ac95b436db73: avcodec/microdvddec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:e833b02f2fb5: avcodec/movtextdec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:27a9bee243c7: avcodec/mpl2dec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:8e7808b524d1: avcodec/realtextdec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:6a65da3a182c: avcodec/samidec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:592716227c5f: avcodec/srtdec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:947a5111dd58: avcodec/subviewerdec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:36c3a0167a32: avcodec/textdec: add some memory checks
[18:46] <cone-560> ffmpeg.git 03Clément BSsch 07master:ce8dc93aefb4: avcodec/webvttdec: add some memory checks
[18:50] <cone-560> ffmpeg.git 03Clément BSsch 07master:e60770679b56: avformat/assenc: return correct error code
[18:58] <cone-560> ffmpeg.git 03Clément BSsch 07master:08e2b0da2ca9: avformat/assenc: mux all extradata at once
[19:02] <BBB> so no vdd summary?/
[19:02] <BBB> :(
[19:03] <ubitux> i suppose we'll get one after everyone is back home
[19:04] <ubitux> i don't see beastd, compn, saste, nicolas, ... here on irc :p
[19:08] <jamrial> libav sent their own summary already. which is basically "these are the things we'll remove, and these the things we will port from ffmpeg" :p
[19:09] <BBB> well there was also an email about opw right?
[19:09] <BBB> I was just looking at their list
[19:09] <BBB> one wrote an unfinished rm demuxer; one wrote an unfinished asf demuxer; one made all kind of cosmetic patches; yay!"
[19:10] <BBB> (I think thats what it said)
[19:10] <wm4> oh you're so mean
[19:10] <wm4> I can totally understand that something related to asf or rm can remain unfinished
[19:10] <wm4> that they trained someone to make cosmetic patches is rather idiotic though
[19:10] <BBB> I started the fork, remember?
[19:10] <BBB> we had such great goals
[19:10] <BBB> to see that these are the accomplishments of the current state of the fork
[19:11] <BBB> ...
[19:11] <wm4> look at it this way: michaelni can now maintain things
[19:11] <wm4> but yeah if you can go back in time and unfork, maybe that's a good idea
[19:12] <wm4> libavtimemachine
[19:13] <ubitux> jamrial: porting is going to be a real pain for them if they actually try to do it
[19:15] <iive> why are they going to remove get_buffer?
[19:17] <wm4> iive: because it was replaced with get_buffer1
[19:17] <wm4> err
[19:17] <wm4> get_buffer2
[19:17] Action: iive facepalm
[19:18] <wm4> nothing to facepalm about
[19:18] <wm4> get_buffer2 is the refcounted version, and it's awesome
[19:19] <BBB> so what does get_buffer do that is not refcounted?
[19:21] <wm4> it simply isn't refcounted
[19:21] <wm4> it's for applications which use the old method
[19:21] <wm4> they expect that the decoder calls release_buffer
[19:23] <michaelni> get_buffer/release_buffer() left the buffers to the user application which could implement ref counting, get_buffer2() moves the ref counting into libavutil 
[19:23] <michaelni> dunno if any user apps did implement ref counting with get_buffer(), ffmpeg itself didnt
[19:24] <BBB> I think chrome did
[19:24] <wm4> mplayer
[19:24] <wm4> vlc (now uses get_buffer2 I'm sure)
[19:25] <wm4> yeah mplayer still uses get_buffer
[19:25] <wm4> so I guess ffmpeg will keep it, hurr
[19:28] <BBB> or you could send a patch to fix mplayer
[19:29] <wm4> hahaha
[19:29] <wm4> yeah that "should be easy"
[19:30] <wm4> in my mplayer fork I've replaced that stuff with refcounting before even libavcodec had it
[19:31] <iive> i'm not familiar with the new api changes.
[19:31] <iive> let's say the app allocates 16 buffers and ffmpeg get_buffer2() alll.
[19:32] <iive> how the program would know what buffer is free when get_buffer2() is called again?
[19:32] <wm4> AVBuffer has a release callback
[19:33] <wm4> but it's called asynchronously, and may happen in foreign threads
[19:34] Action: iive doublefacepalm
[19:35] <wm4> ?
[19:38] <iive> so, basically the new api adds a flag and moves release to another structure...
[19:39] <wm4> it's a saner design
[19:40] <wm4> you could emulate refcounting int eh old api (ffmpeg.c did for libavfilter), but it was very complicated
[19:42] <wm4> it was "fun" http://git.videolan.org/?p=ffmpeg.git;a=blob;f=cmdutils.c;h=27e01307d20d7b2a63658cb0a24dd10b21a4d5e8;hb=refs/heads/release/1.0#l1485
[19:44] <iive> i don't see the improvement...
[19:44] <iive> i actually fail to see a difference.
[19:45] <wm4> compared to this highly hacky code, ffmpeg.c/cmdutils.c now needs only 1 line of code to setup refcounting
[20:47] <cone-560> ffmpeg.git 03Nicolas George 07master:eb7a6d0813ff: lavu/bprint: add const to av_bprint_is_complete() argument.
[20:50] <ubitux> wtf burek 
[20:51] <burek> hmh?
[20:52] <nevcairiel> if gcc crashes, report it to gcc :P
[20:53] <burek> :)
[20:53] <ubitux> it looks totally unrelated to ffmpeg
[20:54] <ubitux> burek: cc just got oom killed because the compilation ate too much memory
[20:54] <wm4> lolwut
[20:54] <ubitux> there is nothing we can do about it
[20:54] <burek> well ok, we can always delete the report, but it might be the issue with make file and dependencies not sorted out properly: http://stackoverflow.com/questions/1564195/gnu-makes-j-option
[20:54] <nevcairiel> oom would be a decent explanation
[20:54] <wm4> how much memory does it use?
[20:54] <burek> could be, let me try with more mem
[20:54] <burek> 1gb
[20:58] <jamrial> dependencies not being sorted properly would give errors like missing objects (because they haven't been compiled yet) and such, but not internal compiler bug errors
[20:58] <burek> you're probably right, i'll give it a try in a sec
[21:00] <ubitux> burek: while you're here, could you fix fflogger so rcombs has his trac nickname (11rcombs) properly displayed?
[21:00] <ubitux> (the number at the start of the nickname are altering the color displayed on irc)
[21:01] <burek> sure
[21:36] <burek> ubitux, can irc nicknames ever begin with a comma character?
[21:37] <burek> -irc +trac
[21:37] <ubitux> i don't know the range of characters
[21:37] <ubitux> you might even be able to put utf-8
[21:38] <BtbN> Only plain ascii characters iirc
[21:38] <burek> because there is no neutral background color code and i really would like to avoid specifying bckgnd color
[21:38] <BtbN> I'm not even sure if it allows numbers in front
[21:38] <burek> wouldn't
[21:38] <burek> would.. man.. i need some sleep obviously
[21:38] <ubitux> BtbN: trac nicknames, not irc
[21:39] <burek> trac, yes, i didn't type correctly my question
[21:39] <ubitux> burek: you just need to put a space after the color change tag
[21:40] <burek> i prefixed the single-number color codes with 0, that should do it
[21:43] <burek> i guess we'll have to wait for rcombs to do something :)
[21:45] <ubitux> thx
[21:45] <burek> :) :beer:
[22:36] <ubitux> http://uselessd.darknedgy.net/ hehe
[22:36] <ubitux> (yeah, sorry, unrelated to ffmpeg, but i heard ppl like systemd drama around here)
[23:05] <jamrial> BBB, ubitux: some low hanging fruit i picked up https://github.com/jamrial/FFmpeg/commit/eb9e527ca4fe81ac47f51eef13a74c018dd0d948
[23:07] <BBB> is vbroadcasti128 slower than just extending the arrays?
[23:07] <BBB> (for filter coeffs)
[23:07] <BBB> it seems to me we should be able to keep using mova and just x2 the array
[23:07] <BBB> (?)
[23:08] <nevcairiel> ymm registers are weird sometimes
[23:08] <jamrial> I guess extending the arrays would be faster, yeah. vbroadcasti128 ymm, m128 is afaik slower than a mova ymm, m256
[23:09] <BBB> ok so lets do that
[23:09] <BBB> LOCAL_ALIGNED_16 -> 32, just make that a macro parameter
[23:09] <BBB> i.e. only use LOCAL_ALIGNED_32 for avx2, keep using 16 for ssse3
[23:10] <jamrial> ok
[23:10] <BBB> (since you already know the size in the macro, so that should be trivial)
[23:10] <BBB> so what functions exist in yasm and which are the C wrappers?
[23:11] <BBB> it looks like 16/32 (width) are raw yasm, and 64 is a c wrapper?
[23:11] <jamrial> yeah, fox avx2 32 is yasm, 64 a wrapper. ssse3 is 16 yasm, 32/64 wrapper
[23:11] <jamrial> there's no 16 avx2
[23:12] <BBB> can 16 be avx2 also?
[23:12] <BBB> or does that suck because of the laning?
[23:12] <jamrial> the separate lanes thingy from ymm registers would kill any gain
[23:12] <jamrial> yeah
[23:12] <BBB> hm.. ok
[23:12] <BBB> thats all I have
[23:12] <BBB> some numbers on speedup would be nice
[23:12] <BBB> (in commit msg)
[23:13] <jamrial> it was around 20% to 25% faster in my tests
[23:13] <BBB> for mc functions right?
[23:13] <BBB> so total gain is & 10% rougly then?
[23:13] <BBB> roughly*
[23:13] <jamrial> yeah. benching it was a PITA, btw. finding the calls to mc and makings sure to only check the 32/64 cases and such
[23:13] <BBB> yes I remember that, its a pain
[23:14] <BBB> (sorry I didnt make that easy, this way the code is sweet and small, but benching becomes kind of nightmarish)
[23:14] <BBB> I do feel its worth it though, since we dont micro-bench very often so ...
[23:15] <BBB> actually 10% doesnt make sense since it only affects part of the mc functions
[23:15] <BBB> maybe 5-7% overall?
[23:15] <BBB> (which is still cool btw)
[23:15] <jamrial> no idea, didn't check overall decoding times or fps as reported by ffmpeg
[23:16] <BBB> maybe nice to include in commit msg& but yeah rest is ok
[23:18] <jamrial> the timer macros showed changes like 1784 cycles -> 1221 cycles on a single function (16k runs total on a 10 seconds 1080p sample)
[23:18] <jamrial> So i don't really expect it will make that much of a difference overall :p
[23:25] <BBB> Id test it, mc tends to be the biggest cpu consumer in video decoding
[23:25] <BBB> along with coefficient decoding, I guess
[23:26] <BBB> so if mc goes down by a significant bit, it should affect overall decoding time
[23:26] <BBB> also depends on content ofc& that is, content with smoother motion fields is more likely to use the big blocks that profit from this
[23:43] <cone-560> ffmpeg.git 03Michael Niedermayer 07release/2.4:d38943829649: swscale: Allow chroma samples to be above and to the left of luma samples
[23:43] <cone-560> ffmpeg.git 03Michael Niedermayer 07release/2.4:bb5c0ac922ef: avfilter/vf_scale: Allow chroma samples to be above and to the left of luma samples
[23:43] <cone-560> ffmpeg.git 03Michael Niedermayer 07release/2.4:e1ce4f805f31: update for 2.4.1
[00:00] --- Mon Sep 22 2014