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

[burek]

[00:49:03 CET] <kierank> michaelni: ever looked at in-place idwt?
[02:52:50 CET] <cone-361> ffmpeg 03Marton Balint 07master:97795ba6c3a5: lavf/mxfdec: fix seeking before the first keyframe
[03:56:58 CET] <cone-361> ffmpeg 03foo86 07master:704654ea170c: avcodec/libdcadec: fix request_channel_layout
[03:56:59 CET] <cone-361> ffmpeg 03foo86 07master:704b278361ad: avcodec/libdcadec: implement logging callback
[03:57:00 CET] <cone-361> ffmpeg 03foo86 07master:de12aa51b6bf: avcodec/libdcadec: add some useful options
[03:57:01 CET] <cone-361> ffmpeg 03foo86 07master:ff6dd5851bff: avcodec/libdcadec: honor -err_detect option
[05:06:50 CET] <rcombs> ubitux: still sitting on a branch
[08:14:06 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:bd0a9f603d0c: fate/api-codec-param: fix codec context leak
[08:14:06 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:102842d5fbb7: fate/api-{jpeg,png}-codec-param: add missing codec dependencies
[08:14:06 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:5aca33c2cfc3: swscale/arm: add ff_nv{12,21}_to_{argb,rgba,abgr,bgra}_neon_16
[09:43:57 CET] <cone-607> ffmpeg 03Luca Barbato 07master:5f3a081b42b8: avi: Spin out the logic to position to the next non-interleaved stream
[09:43:58 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:6a6cfeb2e7c3: Merge commit '5f3a081b42b84404a40a52c80ef7a354cf048c56'
[09:50:19 CET] <cone-607> ffmpeg 03Kylie McClain 07master:bf12a81cc67d: configure: Replace `pr` since it is not provided by busybox
[09:50:20 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:d1b7cafae149: Merge commit 'bf12a81cc67d62dd45c58e29fa0e9177331cc151'
[09:51:02 CET] <cone-607> ffmpeg 03Martin Storsjö 07master:1077d8c8455b: configure: Add -framework CoreVideo when building the avfoundation indev
[09:51:03 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:8076711d4cf9: Merge commit '1077d8c8455b27688de37cd04f8cc253fb37944d'
[09:51:39 CET] <cone-607> ffmpeg 03Luca Barbato 07master:c5eb279e240a: g723: Add missing header
[09:51:40 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:3f9c64831cac: Merge commit 'c5eb279e240af6b7228a624cd7193732f2d5adaa'
[10:01:44 CET] <cone-607> ffmpeg 03Luca Barbato 07master:b805482b1fba: aac: Provide more information on the failure message
[10:01:45 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:92186f2d1006: Merge commit 'b805482b1fba1d82fbe47023a24c9261f18979b6'
[10:04:37 CET] <cone-607> ffmpeg 03Luca Barbato 07master:f7edcac040f7: avpicture: Suppress warning from deprecated code
[10:04:38 CET] <cone-607> ffmpeg 03Luca Barbato 07master:7d36474d1908: imgconvert: Re-enable the deprecation warnings
[10:04:39 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:68cb0dc8a3e8: Merge commit 'f7edcac040f73635fc1127489c9bb29ca8b43532'
[10:04:40 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:c9dbff60c69d: Merge commit '7d36474d1908d6267d4e11d4d9909f9604bd0c81'
[10:06:45 CET] <cone-607> ffmpeg 03Luca Barbato 07master:6788baebb368: log: Use a do {} while (0) for dlog
[10:06:46 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:8142daca44d8: Merge commit '6788baebb3680d447eabdadf3f5743c8470a4611'
[10:38:35 CET] <xhpohanka> Hi, I need to reencode raw bitstream, where two 12bit pixels are packed into three bytes (pixel0[7:0] | pixel0[11:8] pixel1[3:0] | pixel1[11:4]). It seems to me that such pix_fmt is not yet supported so I'm trying to add it. If I understand it correctly I need to add format into avutil and also conversion function into swscale. Am I right, please?
[10:39:18 CET] <nevcairiel> yes, however note that handling such packed formats in swscale is rather annoying, to say the least.
[10:44:09 CET] <xhpohanka> I'm looking at monow format. It is at least similar (copying single bits). How do I now that output buffer is 16bit to store my 12bit pixels?
[10:58:30 CET] <xhpohanka> Or maybe better posed question. I see that most of pix_fmts provide lumToYV12 function but I need to keep all 12 bits. Can I handle that somehow?
[11:05:55 CET] <nevcairiel> depending on how your format is defined, it would expect to get a 16 bit buffer in which you can store your 12-bits entirely
[11:14:41 CET] <xhpohanka> at first i need to view the stream in ffplay, which functions should I implement in swscale? lumToYV12? YV12 has three planes (8bit Y and subsampled UV), I do not understand how to handle monochrome 12 bit there
[11:15:34 CET] <nevcairiel> lumToYV12 only handles the luma, there is a separate function for chroma, so its only the first plane
[12:07:24 CET] <ubitux> lol
[12:07:38 CET] <ubitux> the behaviour of this guy is surreal :)
[12:08:32 CET] <nevcairiel> speaking of surreal, why is it that adding an input format to swscale was relatively easy, but trying to support the same format as an output is making me give up
[12:20:42 CET] <nevcairiel> luckily i dont really need the output format support
[13:25:11 CET] <michaelni> kierank, yes, inplace idwt is fun
[13:27:26 CET] <kierank> michaelni: Is it hard?
[13:29:37 CET] <michaelni> no but coefficients must be initially placed in a somewhat fragmented way IIRC (like vertical + horizontal interlacing in multiple levels)
[13:30:33 CET] <michaelni> there are possibly also other ways to do it
[13:31:44 CET] <michaelni> IIRC snows idwt does use that funny ordering for the vertical idwt
[13:32:15 CET] <michaelni> i think i didnt do it horizontally to avoid fragmented memory accesses
[13:42:08 CET] <nevcairiel> 15 minutes wondering why my hwaccel doesnt work, just to remember that mingw just doesnt have the headers <.<
[13:55:04 CET] <nevcairiel> I faintly remember some discussion about concerns when using the same hwaccel pixfmt for different underlying pixel formats (ie. 420 and 444, or 420 and 420p10), anyone remember anything more concrete?
[13:55:08 CET] <nevcairiel> wm4 maybe?
[14:04:08 CET] <nevcairiel> The problem of course is that weird things happen when avcodec would now suddenly want to start decoding 10-bit hevc content through dxva2 but the user-app isn't aware of this
[14:32:37 CET] <cone-607> ffmpeg 03Rostislav Pehlivanov 07master:6e5dbe7267fc: aacenc_tns: use 4 bits for short windows
[14:32:38 CET] <cone-607> ffmpeg 03Rostislav Pehlivanov 07master:4c5136a48ba8: aacenc_ltp: disable LTP with high lambda values
[14:43:21 CET] <BBB> nevcairiel: hm, so & for hevc simd, I think keeping things as-is for now is probably ok
[14:43:44 CET] <BBB> nevcairiel: sse2 would be nice to have, but I think the curve of what kind of system has tends to trend towards higher-end, so sse4 baseline may just be ok
[14:43:55 CET] <BBB> avx2 certainly does help our appeal
[14:44:42 CET] <nevcairiel> who cares about appeal, is it actually faster?
[14:45:09 CET] <nevcairiel> personally I would like to see the 32-bit support though, even when most people pretend to not care, many of my users still run it
[14:45:28 CET] <ubitux> yes, i saw that in the last survey
[14:46:00 CET] <ubitux> some ppl saying avx2 (which is not that spread) doesn't matter but for low end pc optims are actually useful
[14:46:00 CET] <nevcairiel> but unfortunately my SIMD fu is too limited to try to do this on my own in any realistic timeframe
[14:46:32 CET] <BBB> I dont care enough about hevc to spend time on it, sadly
[14:48:27 CET] <nevcairiel> jamrial and kuroso once showed a bit of interest, maybe adapting existing simd is more something they would get into than writing new stuff
[14:49:06 CET] <ubitux> so we have these optims since ~ may 2014, right?
[14:49:44 CET] <nevcairiel> i think so
[14:49:49 CET] <ubitux> actually april
[14:49:54 CET] <ubitux> ok
[14:50:01 CET] <nevcairiel> but the MC optims are a bit in the rough
[14:50:20 CET] <nevcairiel> most of the others have been cleaned up and optimized, while the MC stuff is mostly verbatim from OpenHEVC
[14:50:33 CET] <nevcairiel> which shows in some areas
[14:52:11 CET] <BBB> the idct is the outstanding area
[14:52:20 CET] <nevcairiel> that doesnt exist at all, yes
[14:56:10 CET] <atomnuker> just heard from someone the ffmpeg flac encoder is better than libflac
[14:56:20 CET] <atomnuker> how much truth is there in that statement?
[14:56:26 CET] <nevcairiel> define better
[14:56:34 CET] <nevcairiel> faster? smaller files? sounds better?
[14:56:35 CET] <atomnuker> compression
[14:56:40 CET] <nevcairiel> (hint: one of those is a trap)
[14:56:47 CET] <atomnuker> rotational velocidensity degradation too
[15:02:24 CET] <TD-Linux> this sounds trivial to test
[15:07:59 CET] <RiCON> wasn't the flac adapted from flake?
[15:08:04 CET] <RiCON> native flac encoder*
[15:09:38 CET] <ubitux> same author
[15:10:39 CET] <RiCON> it was faster and had 4 extra compression levels compared to libflac at the time
[15:15:20 CET] <BtbN> I wonder which nvidia driver still supports NVENC SDK 6.
[15:23:04 CET] <durandal_1707> why morons close git pull requests?
[15:29:50 CET] <rcombs> nevcairiel: I suggested a while back in #libav that there should be some way to specify the stream's actual bit depth, planes, subsampling, etc&, independently of the pixel format it's actually being decoded to
[15:31:15 CET] <rcombs> like, you might decode an H.264 High bitstream to yuv420p or nv12 or any number of opaque formats, but regardless the actual stream is still 4:2:0 8bit/sample YUV
[15:31:52 CET] <BBB> thats not as easy as it sounds
[15:32:24 CET] <BBB> like, for vp9, the residual is completely differently coded between the two, that is, the techniques are the same, but the meaning of specific integer values is different and not easily translated without a performance hit
[15:32:50 CET] <rcombs> I have no idea what any of that means
[15:36:07 CET] <BBB> its not trivial to decode a 10bit vp9 bitstream to 8bit
[15:36:15 CET] <BBB> I believe for h264 its slightly easier but still not exactly trivial
[15:37:27 CET] <rcombs> sure, makes sense
[15:39:13 CET] <rcombs> not sure what that has to do with this, though
[15:39:45 CET] <BBB> youre suggesting to decode a high h264 bitstream to 8bpp yuv420p
[15:39:51 CET] <BBB> Im saying thats not as easy as it looks :)
[15:40:53 CET] <rcombs> I said High, not High 10
[15:41:18 CET] <rcombs> (and that was just an example)
[15:42:17 CET] <BBB> oh sorry misunderstood
[15:42:31 CET] <BBB> sorry about that
[15:42:57 CET] <BBB> so youd like to add, say, nv12 decoding into the decoder?
[15:50:39 CET] <rcombs> BBB: the software decoder? I mean, I guess that might be useful but it's not what I'm saying
[15:51:02 CET] <rcombs> BBB: I'm just saying that lavc should expose the stream's characteristics separately from the pixel format being decoded to
[15:54:29 CET] <nevcairiel> for hwaccel you can kinda look at sw_pix_fmt
[15:55:02 CET] <nevcairiel> not that its that important, or well, was until now, since all hwaccels only decoded 420p8
[15:55:58 CET] <nevcairiel> but what I'm really after I suppose is a flag to allow hwaccels to expose formats other than 420p8
[15:56:14 CET] <nevcairiel> so a user app could say "I know of these things", and wont just cause issues
[15:57:17 CET] <nevcairiel> the dxva2 specific hwaccel context has a flags field, i could throw one in there
[15:57:26 CET] <nevcairiel> however, it might be nice to have something central for all hwaccels
[15:58:42 CET] <BBB> agreed
[15:59:09 CET] <BBB> I found it kind of strange that we use pix_fmt to indicate that something is a hardware decoded picture
[15:59:53 CET] <rcombs> this came up originally because I wanted parsers to set pix_fmt
[15:59:54 CET] <nevcairiel> i dont mind that part, it describes the format of the AVFrame, which is accurate in that sense
[15:59:58 CET] <BtbN> Well, it kind of does make sense
[16:00:25 CET] <rcombs> but someone pointed out that that doesn't really make sense, because lavu/lavc pixel formats aren't inherent to a stream
[16:05:03 CET] <nevcairiel> in other news my P010 processing in swscale in plain  dumb C sure is slow :D
[16:06:10 CET] <wm4> nevcairiel: yes; courmisch was a fan of creating a new pixfmt for each hw format, but nobody else liked it
[16:07:44 CET] <nevcairiel> adding new formats is the cheap way out
[16:08:21 CET] <nevcairiel> the  current hevc dxva2 hwaccel supports everyhting required for 10-bit decoding
[16:08:33 CET] <nevcairiel> its just not turned on because I'm not sure how to protect it from breaking everywhere :D
[16:12:25 CET] <nevcairiel> unfortunately, we don't seem to have a logical place to add such a flag - other than making it hwaccel specific
[16:14:53 CET] <nevcairiel> we already have AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH
[16:14:57 CET] <nevcairiel> but no field to really set it on
[16:27:22 CET] <kierank> where do all these ffmpeg frame drops come from?
[16:27:26 CET] <kierank> what does it even mean
[16:27:35 CET] <kierank> drop=166?
[16:28:38 CET] <durandal_1707> pts?
[16:29:40 CET] <wm4> nevcairiel: well I don't know, maybe pixfmts should really be dynamic instead of fixed (so new pixfmts can be dynamically created at runtime with various specific attributes ike chroma subsampling, depth, hw format, etc.)
[16:30:01 CET] <wm4> and if not that, at least create a common mechanism to identify hw formats for hw accels
[16:30:02 CET] <nevcairiel> that sounds like an api change i dont want to do now :p
[16:30:52 CET] <kierank> it's raw video
[16:31:37 CET] <wm4> g-b wanted to do something like this (and actually unify all hwaccel pixfmts into 1)
[16:33:37 CET] <nevcairiel> there is always some sort of long-term plan to fix everything :)
[16:33:46 CET] <nevcairiel> in the meantime, i guess i'll just fix it dxva2 specific :p
[16:34:46 CET] <nevcairiel> I could just not fix it and force user apps to their hwaccel code by actually checking the formats they support
[16:34:50 CET] <nevcairiel> but thats probably evil
[16:37:23 CET] <wm4> why would user apps need to change something?
[16:37:29 CET] <wm4> they have to do the profile mapping themselves
[16:37:57 CET] <nevcairiel> i'm sure there is plenty apps that dont check any profiles
[16:38:10 CET] <wm4> these are buggy then
[16:38:16 CET] <nevcairiel> get_format is only called for 420 8-bit after all, so the need to check a profile is not really given
[16:38:25 CET] <wm4> but having profile mapping in lavc would be nice too
[16:38:29 CET] <wm4> (like vdpau has)
[16:38:48 CET] <wm4> wait what
[16:38:55 CET] <wm4> get_format is not called for 10 bit?
[16:39:10 CET] <nevcairiel> strictly speaking it is, but the list of formats does not include the hardware formats then
[16:39:36 CET] <nevcairiel> it only offers to use a hardware format on 420 8-bit
[16:40:08 CET] <nevcairiel> so if you just assume it can decode it fine, it'll work on 99% of all content anyway
[16:41:06 CET] <nevcairiel> now enter hevc 420 10-bit decoding, which requires you to pick a different decoder device and a different surface format for dxva2, and if you don't, everything breaks
[16:41:48 CET] <wm4> that sounds fucked up
[16:41:59 CET] <wm4> shouldn't it add the dxva hwaccel pixfmt?
[16:42:19 CET] <nevcairiel> I have no clue what you are saying
[16:43:45 CET] <nevcairiel> All I'm saying is that any half-naive dxva2 hwaccel user app will likely break if it suddenly starts to offer 10-bit decoding without any safeguards
[16:44:11 CET] <wm4> if I understand this right, the decoder entry point GUID is different for 10 bit formats?
[16:44:16 CET] <nevcairiel> yes
[16:44:32 CET] <wm4> so where's the problem? an API user would have to use that to cause real problems
[16:45:12 CET] <nevcairiel> the problem is that they just see "codec id HEVC, pixfmt DXVA_VLD, lets set up the default hevc dxva2 decoder"
[16:45:13 CET] <wm4> I recently had to fix profile checking in my own dxva code (which is really stolen from ffmpeg_dxva.c btw.), and it simply decoded 10 bit as 8 bit (with the usual artifacts)
[16:45:25 CET] <wm4> their own fault then
[16:45:42 CET] <wm4> you get equally fucked with h264 if you do this
[16:45:44 CET] <nevcairiel> get_format does not offer you the dxva pixfmt if its a 10-bit stream
[16:45:49 CET] <nevcairiel> not for hevc or h264
[16:45:55 CET] <nevcairiel> never has
[16:46:53 CET] <wm4> I don't remember when this happened, then
[16:47:12 CET] <wm4> but still, including the dxva format with 10 bit is less broken than not doing it
[16:47:21 CET] <wm4> if you really want to go this way, you have to add a new dxva pixfmt
[16:48:07 CET] <nevcairiel> I could just add a flag in the dxva_context which the user can set to indicate he knows wtf he is doing
[16:48:49 CET] <nevcairiel> or somewhere else
[16:49:01 CET] <wm4> isn't that what vdpau does?
[16:49:06 CET] <nevcairiel> it is
[16:49:14 CET] <nevcairiel> well kind of
[16:50:42 CET] <nevcairiel> the thing is, you can get away just fine without any profile checks right now
[16:51:00 CET] <nevcairiel> you would need a rather specific bitstream to run into that is not "Main" profile but still 4:2:0 8-bit
[16:51:47 CET] <nevcairiel> I could just enable it and claim that it always was the callers responsibility to check profiles
[16:52:23 CET] <wm4> I certainly didn't get away without a check
[17:01:53 CET] <nevcairiel> what profiles are there, maybe lossless?
[17:02:44 CET] <nevcairiel> technically you could use any higher profile and encode 4:2:0 8-bit in it, using some of the extra features
[17:02:49 CET] <nevcairiel> but i dont think i've ever seen this
[17:05:05 CET] <wm4> well, I think I just decoded 10 bit as 8 bit with dxva, but now I'm not so sure anymore
[17:05:33 CET] <nevcairiel> unless you hacked up avcodec, it wont let you do that
[17:08:01 CET] <nevcairiel> changes to user-code arent that complex https://github.com/Nevcairiel/FFmpeg/commit/264b3aaa99a70fde0f2664eb8fd26e14485fe78e
[17:08:14 CET] <nevcairiel> (P010 is not in master, support is added in an earlier commit)
[17:09:38 CET] <wm4> where does it tell lavc to allow 10 bit?
[17:09:52 CET] <nevcairiel> nowhere, that branch just enabled it
[17:10:14 CET] <wm4> what's P010 anyway? 10 bit packed in 16 bit MSB?
[17:10:58 CET] <nevcairiel> pretty much, MS has a page with images and everything https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx
[17:11:12 CET] <nevcairiel> that github branch also adds P010 pixfmt and swscale input support
[17:11:54 CET] <wm4> hm looks like this format can be interpreted exactly like 16 bit yuv
[17:12:11 CET] <nevcairiel> not really, the chroma is interleaved, like NV12
[17:12:26 CET] <wm4> I mean, looking at its components
[17:12:46 CET] <nevcairiel> you could pretend its 16-bit and avoid a shift
[17:12:53 CET] <nevcairiel> i opted to actually shift in swscale however
[17:13:27 CET] <wm4> I assume that gives you room for SIMD overflow bits (like it was discussed so often)
[17:15:00 CET] <kierank> yup
[17:15:06 CET] <wm4> hm, there's also crap like Y210
[17:15:13 CET] <wm4> "Packed, 4:2:2, 10-bit."
[17:15:18 CET] <nevcairiel> yeah these fully packed formats are magic
[17:15:23 CET] <nevcairiel> but i've not seen them used for anything
[17:15:31 CET] <wm4> good
[17:16:15 CET] <nevcairiel> although Y210 isnt too bad
[17:16:25 CET] <nevcairiel> its just 16-bit YUY2
[17:16:34 CET] <nevcairiel> 2 byte per component
[17:16:36 CET] <nevcairiel> no bit packing
[17:16:39 CET] <wm4> (bad enough)
[17:16:52 CET] <nevcairiel> Y410 is really evil, where they pack 3x 10-bit into 32-bit
[17:16:54 CET] <nevcairiel> with 2 bits of alpha
[17:16:55 CET] <nevcairiel> :D
[17:17:09 CET] <wm4> with subsampling?
[17:17:17 CET] <nevcairiel> nah, the 4 in the name suggests 444
[17:17:24 CET] <wm4> then it's not that bad either
[17:17:52 CET] <nevcairiel> the numbers are pretty nice, 0/2/4 for the subsampling (420, 422, 444), followed by the bitdepth
[17:18:00 CET] <nevcairiel> P for planar, Y for packed
[17:18:08 CET] <nevcairiel> easy to remember ;)
[17:20:43 CET] <nevcairiel> in any case, P010 is the only of interest for a while, hardware is unlikely to adopt any higher formats for the next couple years
[17:37:34 CET] <jamrial> oh hey, conflicting hevc mc prototypes and assembly
[17:37:56 CET] <nevcairiel> i commented on that on the ML
[17:38:03 CET] <nevcairiel> if you want to recycle some of their asm, go ahead :D
[17:38:33 CET] <Daemon404> dont forget conflicting avfoundation impl
[17:40:06 CET] <jamrial> their asm can be improved somewhat. but the fact the prototypes are completely different makes it kinda hard to measure which implementation is faster
[17:40:34 CET] <jamrial> on sse2 cpus like Phenom theirs is faster, for obvious reasons
[17:41:39 CET] <jamrial> we can't even use the checkasm units they wrote, heh
[17:42:05 CET] <nevcairiel> their hevc decoder is years behind in features
[17:42:13 CET] <nevcairiel> they got the initial dump and not one single feature afterwards
[17:42:23 CET] <nevcairiel> probably dont even have 422/444 decoding
[17:42:28 CET] <nevcairiel> or 12-14 bits
[17:42:55 CET] <nevcairiel> 14 bits isnt actually a thing is it? maybe only h264
[17:43:50 CET] <nevcairiel> ah the 444 intra profile goes up to 16 even
[17:45:38 CET] <nevcairiel> Daemon404: that one was easy to skip, Thilo asked me to simply not merge anything as he wants to work on some improvements =p
[17:45:50 CET] <Daemon404> ;p
[18:00:43 CET] <cone-607> ffmpeg 03Clément BSsch 07master:503d8bf74a38: lavu/frame: use AVPALETTE_SIZE instead of 1024
[18:10:10 CET] <cone-607> ffmpeg 03Sebastian Dröge 07master:9aebea0a4de1: avcodec/h264: Set CORRUPT flag on output frames that are not fully recovered
[19:00:28 CET] <atomnuker> any analog of svq3_get_ue_golomb() which encodes instead?
[19:01:52 CET] <nevcairiel> dont think we really have golomb writing code
[19:10:42 CET] <atomnuker> nevcairiel: ffv1 and flac encoders use golomb
[19:11:40 CET] <nevcairiel> ah
[19:11:50 CET] <nevcairiel> well if its not in golomb.h, then invent it in there :)
[19:23:10 CET] <andrey_utkin> Hi! Could please anybody look at MJPEG RTP encoder issue with yuvj422p https://trac.ffmpeg.org/ticket/3823#comment:17 ? This pixel format becomes popular for IP cameras having no RTSP, and there are constantly issues with RTPizing it. I consider donation for fixing this.
[20:51:48 CET] <nevcairiel> wasnt that particular assertion supposed to go away with recent aacenc changes
[20:51:54 CET] <nevcairiel> or was that one that looked similar :D
[20:53:46 CET] <kierank> nevcairiel: not the same crash I believe
[20:53:52 CET] <kierank> well the same assert but a different sample
[20:54:03 CET] <nevcairiel> well, not that recent changes
[20:54:11 CET] <nevcairiel> slighty older
[20:54:16 CET] <kierank> fuzzing aac enc is awfully slow
[20:54:56 CET] <nevcairiel> " and fixing delta-SF-related assertion failures,
[20:54:56 CET] <nevcairiel> since now the limitation is enforced rather than asserted.
[20:55:02 CET] <nevcairiel> may have been a different assert ^^
[20:56:01 CET] <nevcairiel> or the patch lied/was out of date
[21:05:26 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:3d090653168c: fate/api-jpeg-codec-param: rename to api-mjpeg-codec-param
[21:10:13 CET] <llogan> it's been 6 months since i've had to update BadContent
[21:12:21 CET] <llogan> atomnuker: user on twitter is wondering if the aac VBR "worse results" comments on wiki are (still) accurate. https://twitter.com/Bardnet/status/673999220383350784
[21:13:23 CET] <nevcairiel> VBR is probably still not as good as CBR
[21:13:34 CET] <nevcairiel> but the "even" could be removed =p
[21:34:52 CET] <ubitux> haha who posted https://twitter.com/FFmpeg/status/667443251553636353 ?
[21:35:55 CET] <llogan> i did
[21:36:20 CET] <llogan> i simply liked how it looked even better than the output GIF
[21:45:03 CET] <ubitux> ok :)
[21:45:28 CET] <nevcairiel> why does the palette look like it has dupes
[21:45:35 CET] <nevcairiel> but its probably just similar colors
[21:48:02 CET] <kierank> atomnuker: lol carl closed ticket
[21:53:54 CET] <atomnuker> llogan: yes, vbr is still always going to be worse than cbr
[21:55:11 CET] <BtbN> That sounds strange, shouldn't vbr make it easier to achive a good quality?
[21:56:27 CET] <fritsch> it's not so easy to get that done correctly with a single pass
[21:56:40 CET] <TD-Linux> it requires a lot of tuning
[21:56:44 CET] <fritsch> as one needs to estimates and predict
[21:56:57 CET] <fritsch> I think one could create a sample where vbr fails heavily
[21:56:59 CET] <llogan> nevcairiel: i lazily checked in the GIMP and they were all slightly different, AFAICT
[21:57:12 CET] <TD-Linux> it's not impossible, libopus does open loop unconstrained VBR by default and it works great
[21:58:23 CET] <fritsch> yeah, nobody said it would be impossible - but doing cbr is much easier
[21:59:24 CET] <nevcairiel> you would think encoding to some quality target is easier than trying to hit a specific bitrate exactly
[22:53:55 CET] <TD-Linux> nevcairiel, the problem is specifying the quality target
[22:55:47 CET] <cone-607> ffmpeg 03Andreas Cadhalpun 07master:5b0da6999fdd: aacenc: update max_sfb when num_swb changes
[00:00:00 CET] --- Wed Dec  9 2015