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

[burek]

[00:04:39 CET] <J_Darnley> :)
[00:04:44 CET] <J_Darnley> having fun?
[02:04:10 CET] <cone-072> ffmpeg 03Michael Niedermayer 07master:56ec8f85e2b8: avcodec/ac3enc: Remove duplicate #include
[02:04:10 CET] <cone-072> ffmpeg 03Mats Peterson 07master:71f73ee3250a: lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME private data
[04:08:05 CET] <tmm1> ubitux: yea that should work
[04:08:25 CET] <tmm1> are there docs on ass positioning tags?
[04:08:32 CET] <tmm1> might take a stab at that
[04:09:10 CET] <tmm1> so captions show up under the person speaking
[04:31:22 CET] <tmm1> aha found it
[09:09:23 CET] <tmm1> ubitux: got positioning working: https://github.com/tmm1/FFmpeg/commit/bd71d74f0
[09:54:58 CET] <ubitux> tmm1: not sure that's a really good idea :p
[09:55:39 CET] <ubitux> but about an7, if that's indeed the default alignment, can you put it in the default style?
[10:18:44 CET] <wm4> note that mpv discards the default style
[10:25:36 CET] <ubitux> huh? why?
[10:34:50 CET] <wm4> because the user is supposed to control the tsyle via settings
[10:38:09 CET] <ubitux> but that's only if the user has settings, right?
[10:38:39 CET] <ubitux> ccaption uses white on black monospace by default typically, you probably want to retain that style
[10:44:35 CET] <wm4> no, always
[10:44:51 CET] <ubitux> sad.
[10:45:50 CET] <wm4> ?
[10:47:53 CET] <ubitux> well, you're saying the default style is not honored, while it technically should, so that's sad :)
[10:51:06 CET] <wm4> no way I'm letting hardcoded ffmpeg things dictate what the user should see
[10:51:27 CET] <fritsch> do you also discard keyframes, cause they are hardcoded? :-)
[10:53:34 CET] <ubitux> i don't understand the reasoning, but whatever
[10:54:06 CET] <wm4> ubitux: arbitrary positioning, font and font size
[10:54:20 CET] <wm4> in mostcases (srt etc.)
[10:54:29 CET] <wm4> I'm shocked you don't understand this
[10:54:47 CET] <ubitux> it's probably fine for srt and basic subtitles
[10:54:57 CET] <ubitux> but it's not in case of more advanced ones like ccaption
[10:55:11 CET] <kierank> http://www.theregister.co.uk/2016/01/11/math_bug_splatters_skylake_intel_working_on_fix/
[10:55:33 CET] <wm4> should have gone with haswell after all huh
[10:56:33 CET] <rcombs> hah, nice
[11:54:47 CET] <wm4> ubitux: also, considering that CCs can apparently do layouting by putting characters on a grid, you could argue ASS is really not a right representation for them
[11:54:57 CET] <ubitux> sure
[11:57:16 CET] <wm4> in fact, just using some sort of bitmap font would save a lot of pain (except that you'd have to get this font from somewhere)
[13:10:27 CET] <kierank> wm4: how does ass deal with rollup captions?
[13:10:40 CET] <wm4> well ass does have animations
[13:10:42 CET] <kierank> i remember there was a long brouhah about this in webvtt
[13:11:11 CET] <wm4> although it seems modern insane ass subtitles (as seen in the anime scene) use multiple ass events per videoframe now?
[13:17:57 CET] <fritsch> anime scene, that's the hi10p + 7.1 flac guys ...
[13:18:00 CET] <fritsch> what did you expect?
[13:19:04 CET] <wm4> yeah, the subtitle renderer becomes the bottleneck, instead of video decoding
[13:19:23 CET] <wm4> libass had to get asm optimizations etc.
[13:21:31 CET] <kierank> j-b showed me some anime madness once
[13:23:53 CET] <ubitux> you're saying this like it's an exception
[13:24:32 CET] <ubitux> i don't consider this like such bad thing though
[13:25:30 CET] <fritsch> i consider the anime scene acting totally insane ...
[13:25:52 CET] <fritsch> audio / video codec chosen
[13:25:57 CET] <fritsch> and so on
[13:26:02 CET] <fritsch> that sub stuff just matches
[13:27:09 CET] <nevcairiel> flac isnt that insane of a codec
[13:50:17 CET] <fritsch> nevcairiel: if your target audio system is spdif based and can only do ac3/ dts for multichannel ...
[13:50:22 CET] <fritsch> you got an issue
[13:50:44 CET] <nevcairiel> you always got an issue if your system is limited like that ;)
[13:50:44 CET] <fritsch> remember: they made their decision at the time an ION-2 was the perfect media center
[13:50:57 CET] <fritsch> yeah we talk 2009/2010
[13:51:14 CET] <nevcairiel> but ac3 live encoding is a common feature in many media software if you really must
[14:00:44 CET] <fritsch> yeah, yeah, we have it
[14:00:50 CET] <fritsch> since several years
[14:00:52 CET] <kierank> nevcairiel: there are neckbeards who specifically want dolby or dts encoders
[14:01:08 CET] <fritsch> in nowadays android world all want passthrough
[14:01:12 CET] <fritsch> cause of the licences ...
[14:02:29 CET] <wm4> when they could just use flac or vorbis
[14:02:45 CET] <nevcairiel> or even opus these days
[14:03:52 CET] <fritsch> "but my receiver supports dts-hd and is not used ..."
[14:04:16 CET] <fritsch> technical folks are easy to explain that matter, but everyday joe with his big amp at home - starts whining
[14:04:43 CET] <wm4> then educate gim
[14:04:46 CET] <wm4> him
[14:05:23 CET] <wm4> well the real problem is that hardware essentially stops working if you don't feed it the "usual"
[14:44:40 CET] <durandal_1707> anyone know good book about audio resythesis from spectrogram?
[15:46:28 CET] <tmm1> ubitux: why not a good idea?
[16:37:05 CET] <J_Darnley> I *have* found a "bug" in yasm.  Nasm will exit with an "interminable macro recursion" error.  Yasm won't.
[16:38:25 CET] <ubitux> tmm1: because the playres might not match the real one?
[17:36:20 CET] <wm4> nevcairiel: do you happen to know if mingw-w64's latest release includes updated hevc headers yet?
[17:37:10 CET] <BtbN> It took them several years to include dx10/11 headers
[17:37:15 CET] <nevcairiel> latest release? is that still 4.0? then no
[17:37:24 CET] <wm4> 4.0.4
[17:37:37 CET] <wm4> also why are they still on SF, jesus christ
[17:37:49 CET] <BtbN> because money
[17:37:55 CET] <wm4> I hope that native C99 clang or whatever it is is coming along
[17:42:02 CET] <wm4> yeah, no hevc stuff in there
[17:42:04 CET] <wm4> what the hell
[17:42:20 CET] <nevcairiel> mingw moves slower than anyone else
[17:43:46 CET] <nevcairiel> i use a patched mingw-w64 4.0.4 myself now because the official one has a broken mkstemp that makes binutils break randomly
[17:44:27 CET] Action: Daemon404 used to use HEAD
[17:44:50 CET] <wm4> nevcairiel: do you have that patch handy? I was about to patch 4.0.4 for hevc stuff
[17:45:01 CET] <jamrial> that's what i use since it's what's shipped as msys2's mingw64 package
[17:45:20 CET] <nevcairiel> wm4: https://files.1f0.de/mingw/patches/mingw-w64-4.0.4-fix-mkstemp.patch
[17:45:22 CET] <jamrial> a relatively rencet trunk snapshot
[17:45:46 CET] <wm4> nevcairiel: thanks
[17:46:26 CET] <wm4> also that dxva main 10 patch, do you plan on updating/posting it, or should I continue this? (maybe adding a private option to allow extended profiles?)
[17:47:00 CET] <jamrial> and mingw isn't slow. what seems slow is calling it as part of a make recipe
[17:47:27 CET] <jamrial> on windows, that is. cross compiling from linux is fast
[17:47:32 CET] <nevcairiel> slow to add things, not slow in building or whatnot
[17:48:48 CET] <jamrial> ah right
[17:50:30 CET] <nevcairiel> wm4: where would you add a private option, i thought about it and didnt see an obvious spot
[17:50:50 CET] <wm4> didn't think much about it - to the hevc decoder?
[17:55:34 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:c71999ef97b7: avformat/dfa: Fix packet leak on error
[17:55:34 CET] <durandal_1707> anybody played with spectrumsynth?
[17:56:36 CET] <nevcairiel> wm4: that sounds odd, maybe rather go without one then
[17:58:31 CET] <wm4> nevcairiel: what else would you suggest for keeping absolute API compatibility?
[17:59:05 CET] <nevcairiel> thats why i didnt add one,  there was no natural field :D
[17:59:51 CET] <wm4> we could add a new pixfmt, but that's IMHO too radical
[18:32:38 CET] <J_Darnley> Shit!  Trying to work around that infinite loop I cause others.
[18:45:26 CET] <durandal_1707> J_Darnley: where?
[18:47:12 CET] <J_Darnley> In yasm
[18:47:48 CET] <J_Darnley> User error causes an infinite loop trying to expand a define
[18:55:01 CET] Action: J_Darnley sighs
[18:55:11 CET] <J_Darnley> x264asm has so much indirection
[19:12:48 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:26757b0279b4: avcodec/wavpackenc: Headers are per channel
[19:12:49 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:59c915a403af: avcodec/wavpackenc: Check the number of channels
[19:27:17 CET] <tmm1> ubitux: seems to work as expected on 1080p so i assume libass is scaling the coordinates up
[20:12:52 CET] Action: J_Darnley facepalms
[20:13:09 CET] <J_Darnley> I just moved the bug elsewhere of course
[20:14:30 CET] <Daemon404> bugs are like energy, you cant destroy them
[20:16:15 CET] <wm4> lol
[20:16:49 CET] <wm4> so ffmpeg got a bit piece of the big bang?
[20:17:45 CET] <J_Darnley> I wonder how different the nasm and yasm code bases are.
[20:19:33 CET] <nevcairiel> isnt it independently implemented
[20:20:59 CET] <nevcairiel> ie. based on nasm behavior and syntax, but not code?
[20:21:27 CET] <J_Darnley> I thought it was a fork
[20:21:28 CET] <J_Darnley> :(
[20:21:54 CET] <J_Darnley> "Yasm is a complete rewrite of the NASM assembler" :(
[20:23:54 CET] <J_Darnley> And the bug is already in their system: https://tortall.lighthouseapp.com/projects/78676/tickets/156-infinite-loop-in-recursive-define
[20:24:11 CET] <J_Darnley> Hey, its from Loren!
[20:25:56 CET] <wm4> wow 4 year old bug?
[20:26:07 CET] <Daemon404> ... pretty sure the only way the last bug we found in yasm got fixed was by loren sending a patch
[20:26:17 CET] <Daemon404> in fact i found a bug in my (very limited) yasm usage
[20:26:21 CET] <wm4> wasn't it that yasm is dead now and nasm is back to life?
[20:26:22 CET] <Daemon404> in the preproc
[20:26:26 CET] <Daemon404> and it was never fixe
[20:26:27 CET] <Daemon404> d
[20:26:39 CET] <Daemon404> wm4, it had a release in 2014 or 2015 or something
[20:27:00 CET] <nevcairiel> yasm 1.3 is relatively new
[20:27:09 CET] <J_Darnley> Maybe I should go back to nasm then?
[20:30:07 CET] <J_Darnley> They've had 6 releases in 2014 and 2 in 2015
[20:31:03 CET] <Daemon404> ping/bump the bug?
[20:32:40 CET] <J_Darnley> I could.  I would have to make an account though.
[20:33:17 CET] <wm4> tmm1, ubitux: yes, all coordinates in ASS tags use the PlayResX/Y as virtual resolution... but you still could get problems if the aspect ratio mismatches
[20:33:52 CET] <Daemon404> [19:32] <+J_Darnley> I could.  I would have to make an account though. <-- reason #1 i rareky file bugs
[20:33:56 CET] <Daemon404> rarely*
[20:34:21 CET] <J_Darnley> I'll start with an email to their devel list.
[20:41:57 CET] <J_Darnley> Oh fuck!
[20:42:07 CET] <J_Darnley> I subscribed just fine
[20:42:28 CET] <J_Darnley> but then my email got returned
[21:28:46 CET] <durandal_1707> ubitux: is phase addition to showspectrum ok?
[21:31:23 CET] <ubitux> durandal_1707: can't tell if the math are correct, so probably
[21:31:44 CET] <ubitux> no performance hurting?
[21:32:21 CET] <ubitux> you might want to "constify" the function mode (trick the compiler into creating two functions, one for magn one for phase)
[21:32:31 CET] <ubitux> btw, since you're on showspectrum
[21:32:47 CET] <ubitux> it might be time to fix the highest and lowest freq computation
[21:33:39 CET] <ubitux> (im(1) actually being im(n))
[21:33:54 CET] <ubitux> (im(0) sorry)
[21:48:03 CET] <durandal_1707> ubitux: i use its output for ifft input in spectrumsynth
[21:49:18 CET] <durandal_1707> with it you can modify frequency with gimp
[21:51:20 CET] <durandal_1707> it looks like noise but if its not same resynthesis sound awful
[21:52:47 CET] <durandal_1707> ubitux: do I need to replace im0 even if doing ifft?
[23:18:37 CET] <cone-652> ffmpeg 03Andreas Cadhalpun 07master:63c9b30f98ce: qtpalette: make the color_* variables unsigned again
[23:18:38 CET] <cone-652> ffmpeg 03Andreas Cadhalpun 07master:f6e1c96730eb: ffmdec: change type of len to ptrdiff_t
[23:21:07 CET] <cone-652> ffmpeg 03Ganesh Ajjanagadde 07master:07a11ebcab9b: lavc/cbrt_tablegen: speed up tablegen
[00:00:00 CET] --- Tue Jan 12 2016