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

[burek]

[00:04:36 CEST] <ubitux> alright, i confirm it works
[00:04:47 CEST] <ubitux> now bitexactness & fate test and i'm done.
[00:08:19 CEST] <ubitux> ...and maybe 10-bit support while i'm at it
[00:08:41 CEST] <ubitux> i'll see that in the following days
[00:08:55 CEST] <durandal_1707> nlmeans
[04:03:11 CEST] <cone-048> ffmpeg 03Michael Niedermayer 07master:1e7e4f13f952: avcodec/pngdec: Check blend_op.
[05:45:12 CEST] <cone-048> ffmpeg 03Ganesh Ajjanagadde 07master:971d12b7f9d7: avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm
[05:45:13 CEST] <cone-048> ffmpeg 03Michael Niedermayer 07master:2a4d1a66e853: avutil/intmath: Change debruijn_ctz64 to use 8bit elements
[06:06:58 CEST] Action: rcombs dabbles in SAMI decryption
[06:16:04 CEST] <Daemon404> what year is it
[06:22:55 CEST] <rcombs> the year of Hulu simulcasts
[10:14:26 CEST] <nevcairiel> why would one encrypt subtitles
[10:16:08 CEST] <mateo`> wild guess: "because one can fear that it could be stolen and used somewhere else for free"
[11:08:02 CEST] Action: rcombs pokes AESNI
[11:08:28 CEST] <rcombs> nevcairiel: because a manager got a hold of just enough information to be dangerous
[11:08:40 CEST] <rcombs> nevcairiel: and said "everything should be encrypted!"
[11:30:24 CEST] <ubitux> durandal_170: yeah, just after selectivecolor :)
[11:35:06 CEST] <ubitux> rcombs: wat, hulu uses... SAMI? for real?
[11:35:14 CEST] <rcombs> yup!
[11:35:32 CEST] <ubitux> even jacosub would have been a better choice&
[11:35:46 CEST] <ubitux> rcombs: do they use multilang sami btw?
[11:35:49 CEST] <rcombs> SAMI with the contents of the <SYNC>s encrypted with hardcoded AES keys and encoded in hex
[11:36:01 CEST] <ubitux> lol yeah that's what i see 
[11:36:36 CEST] <rcombs> ffmpeg -key 4878b22e76379b55c962b18ddbc188d82299f8f52e3e698d0faf29a40ed64b21 -iv_str WA7hap7AGUkevuth -i http://assets.huluim.com/captions/652/60625652_US_ja_en.smi sami.ass
[11:40:31 CEST] <ubitux> ah, it's simplified SAMI though
[11:40:39 CEST] <ubitux> no css & shit
[12:26:59 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07master:14573b9b7cb0: Revert "Merge commit '8b830ee9a26d47b138f12a82085cdb372f407f1e'" (avconv: Do not try to configure filter outputs without streams)
[13:20:40 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07master:47c5a3058eea: avcodec/pngdec: Alloc buffer after blend_op check in handle_p_frame_apng()
[13:44:43 CEST] <cone-214> ffmpeg 03Clément BSsch 07master:49f4967dd0b3: avfilter: add selectivecolor filter
[13:56:02 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20151011053515&slot=x86_64-archlinux-gcc-valgrind
[13:56:09 CEST] <ubitux> any idea what's going on here?
[13:57:12 CEST] <ubitux> apparently it's not failing only on valgrind
[14:23:29 CEST] <nevcairiel> Finally setup vs2015 fate systems. I think once I also ran Clang/C2 in a couple months, the VS2012 systems have to go .. its getting too long of a list =p
[14:47:36 CEST] <ubitux> michaelni__: re 47c5a3058eeae2043bd0dc2704b024cac8adcb3b; unrelated but maybe av_malloc_array while at it? 
[15:03:33 CEST] <BBB> so guys
[15:03:49 CEST] <BBB> were not seriously considering adding jni support inside libavwhatever right?
[15:04:24 CEST] <BBB> imo that shouldnt be remotely near our codebase; if anyone wants to interface with java, that must live in the application
[15:04:36 CEST] <BBB> it can be opensource and stuff, Im sure github can host such code, but not inside libavwhatever
[15:04:46 CEST] <BBB> (again, imo)
[15:04:56 CEST] <Mavrik> Yeah, also people should use JNA to make binding easier.
[15:05:06 CEST] <ubitux> it's not intrusive imo
[15:05:09 CEST] <ubitux> it's still C
[15:05:22 CEST] <ubitux> ...compared to c++ and c# we already have in the codebase
[15:05:51 CEST] <ubitux> also obviously optional
[15:06:14 CEST] <BBB> its in libavutil
[15:06:27 CEST] <BBB> its public api, installed and everything, with av_ namespacing
[15:06:48 CEST] <ubitux> only if you have jni
[15:07:13 CEST] <wm4> BBB: I don't think it should be part of libavutil at all
[15:07:23 CEST] <BBB> ubitux: I have jni
[15:07:32 CEST] <wm4> and the existing patch is unacceptable because of global state
[15:07:35 CEST] <BBB> ubitux: it has no use anywhere except for an android app thing
[15:08:00 CEST] <durandal_170> I'm against it too
[15:08:18 CEST] <ubitux> we have a shit ton of windows & osx specific stuff
[15:08:25 CEST] <ubitux> why should android be an exception?
[15:08:35 CEST] <J_Darnley> Does that just let people write more crappy players that use ffmpeg in violation of the license?
[15:08:51 CEST] <wm4> ubitux: well we have dxva2 support, but we don't have directshow interop for example
[15:09:07 CEST] <wm4> J_Darnley: that's an odd way to look at it
[15:09:09 CEST] <ubitux> wm4: libavdevice/dshow.c ?
[15:09:29 CEST] <wm4> ubitux: that's just for A/V capture
[15:09:32 CEST] <J_Darnley> Well I don't know jack about mobile only that it seems to be full of knockoff apps
[15:09:44 CEST] <wm4> J_Darnley: because all the money is there
[15:09:59 CEST] <ubitux> your problem is not android, it's jni
[15:09:59 CEST] <Mavrik> Why is "number of knowckoff apps" even relevant for technical conversation?
[15:10:03 CEST] <J_Darnley> Bloody sheeple!
[15:10:26 CEST] <ubitux> and the problem is, jni is mandatory for about 80% of the androids
[15:10:28 CEST] <J_Darnley> It isn't so I'll fuck off.
[15:10:51 CEST] <J_Darnley> Mavrik^
[15:10:58 CEST] <Mavrik> ^^
[15:11:13 CEST] <Mavrik> JNI is mandatory for Android period, you can't talk to libav without it
[15:11:42 CEST] <Mavrik> Even though technically I'd argue that people on Android should really use MediaCodec, since ffmpeg really isn't all that good of a fit for that platform.
[15:11:43 CEST] <ubitux> i meant if you want mediacodec support in ffmpeg for instance
[15:11:47 CEST] <Gramner> you can always sue google if they're selling software that uses your code illegally ;)
[15:12:32 CEST] <durandal_170> who will pay my lawyer?
[15:13:07 CEST] <Mavrik> Hmm, the process of Java<-->C buffer handling to support MediaCodec in ffmpeg just boggles my mind.
[15:13:17 CEST] <Gramner> durandal_170: kickstarter, I heard that's popular for everything nowadays
[15:14:32 CEST] <BBB> why did j_darnley just get angry?
[15:14:46 CEST] <wm4> Mavrik: can't be worse than what I had with mmal?
[15:19:31 CEST] <wm4> BBB: maybe just some nerd rage?
[15:20:10 CEST] <wm4> I think this JNI thing is a good example that ffmpeg shouldn't be so monolithic
[15:20:24 CEST] <wm4> surely it would be nice to have some community-shared code for android interop
[15:20:34 CEST] <wm4> but it _shouldn't_ be part of libavutil or libavcodec
[15:21:05 CEST] <wm4> the whole ecosystem should be more modular and less tightly coupled
[15:21:27 CEST] <wm4> a good start would be not having a single git repo for Everything
[15:22:16 CEST] <iive> you want libavcodec and libavformat in separate git repos?! are you kidding?
[15:23:25 CEST] <Gramner> avcodec and avformat kinda belong together
[15:24:10 CEST] <wm4> iive: decoupling them is work in progress for certain devs
[15:24:19 CEST] <wm4> while other devs try to connect them tighter
[15:24:24 CEST] <wm4> (this sure is fun)
[15:24:58 CEST] <wm4> but no, a repo split would make sense for things like, say, libavdevice
[15:25:20 CEST] <iive> i fail to see how having them in different repos would bring anything but problems.
[15:26:00 CEST] <ubitux> same
[15:26:19 CEST] <ubitux> merging them into a single lib is IMO a wiser solution
[15:26:43 CEST] <ubitux> and runtime modularity to allow external "plugins" is fine
[15:26:54 CEST] <ubitux> but it's unrelated to decoupling libs
[15:28:19 CEST] <wm4> depends how you look at it
[15:28:44 CEST] <wm4> [FFmpeg-devel] [PATCH] os2threads: Add pthread_once emulation
[15:28:45 CEST] <wm4> haha
[15:28:49 CEST] <ubitux> BBB: android io is exactly the same as file; the jni is only used to get a fd
[15:29:04 CEST] <ubitux> which make it very convenient to have it there
[15:29:09 CEST] <nevcairiel> wm4: i mailed the guy, what did you expect
[15:29:22 CEST] <durandal_170> it makes no sense to recompile everything when only one codec or demuxer or filter is added
[15:30:09 CEST] <JEEB> wm4: so the guy did show up 8)
[15:30:16 CEST] <JEEB> oh
[15:30:18 CEST] <JEEB> nev mailed him
[15:30:20 CEST] <JEEB> löl
[15:30:30 CEST] <wm4> JEEB: as it has been foretold
[15:30:46 CEST] <wm4> I'm mostly fascinated that this guy is still alive
[15:30:51 CEST] <wm4> or rather OS/2, not this guy
[15:31:21 CEST] <JEEB> yes
[15:43:10 CEST] <mateo`> Mavrik: Java<-->C buffer handling is done using the direct ByteBuffers
[15:44:42 CEST] <mateo`> for the output i was considering supporting only surface output, so the application will have to handle that part of the code
[15:44:59 CEST] <Mavrik> Playback only?
[15:45:00 CEST] <mateo`> as i don't really want to deal with all the alignement stuff
[15:45:25 CEST] <mateo`> Mavrik: for a first start yes
[15:46:31 CEST] <Mavrik> My comment was mostly about how messy would it be to get a full transcoding working using MediaCodec - at least efficiently. Since the API just loves to pass you it's internal buffers and copying those to AVFrame etc. would be rather expensive. As I said, I'm not sure if ffmpeg is the right tool for that kind of job :/
[15:50:26 CEST] <wm4> Mavrik: ffmpeg already deals with opaque buffers in a lot of places
[15:50:30 CEST] <wm4> starting with hwaccels
[15:50:30 CEST] <mateo`> it would be possible to wrap that memory in an avframe
[15:50:54 CEST] <Mavrik> True enough.
[15:53:19 CEST] <wm4> though there's no consistent idea how to do transcoding with this
[15:54:32 CEST] <mateo`> wm4: I'm familiar to using this api for transcoding, i'm even feeding the output of mediacodec to lavf on the application level
[15:56:40 CEST] <mateo`> to reply to BBB question about the jni the stuff, does the project want to support hw acceleration on android (and for devices < 5.0) through mediacodec ?
[15:57:03 CEST] <mateo`> because it depends on supporting jni
[16:03:47 CEST] <wm4> I think having mediacodec support in any form would be awesome, but I'm not sure if the price isn't too high
[16:03:58 CEST] <wm4> anyway, having JNI support in this form and in lavu is still unacceptable
[16:04:54 CEST] <mateo`> wm4: how would you see that support ?
[16:05:16 CEST] <wm4> if it has to exist, at least make it fully private, and thread-safe
[16:05:17 CEST] <mateo`> wm4: the other option is only supporting the mediacodec c api
[16:05:25 CEST] <wm4> that sounds much better too
[16:06:27 CEST] <ubitux> except it covers 20% of the use cases
[16:07:02 CEST] <mateo`> wm4: by fully private what do you mean ? the application will need to register the java vm as well as its application context
[16:07:54 CEST] <mateo`> it is its responsability to call av_register_java_vm (as well as av_register_all)
[16:08:37 CEST] <mateo`> so registering the java vm should be locked ? and only called once
[16:11:39 CEST] <wm4> mateo`: consider that there could be multiple libs inside of the same process which all use libavcodec
[16:11:53 CEST] <wm4> and this should not break if they all somehow use the java interop
[16:12:05 CEST] <wm4> that's the minimum that should not break IMHO
[16:12:29 CEST] <wm4> mateo`: so why can't ffmpeg create its own jni context
[16:13:52 CEST] <mateo`> the jni context is tied to the java vm
[16:14:06 CEST] <wm4> so, create a new vm
[16:14:14 CEST] <wm4> does this not work for some reason?
[16:14:18 CEST] <mateo`> outside of android you can create java vm, on android you are not supposed to do it
[16:15:35 CEST] <mateo`> you can retreive the vm through the use of libnative helper on android
[16:16:38 CEST] <mateo`> and it leads to that kind of code
[16:16:40 CEST] <mateo`> https://github.com/mbouron/gst-plugins-bad/blob/master/sys/androidmedia/gstjniutils.c#L515
[16:16:53 CEST] <mateo`> and i don't want to do that
[16:17:10 CEST] <mateo`> i though it was easier for the application to provide the vm
[16:18:06 CEST] <mateo`> easier and cleaner
[16:19:58 CEST] <mateo`> av_jni_register_java_vm is meant to be called in JNI_OnLoad, so only once per application
[16:20:57 CEST] <wm4> I don't know what the gst code does exactly here, but it looks like there might be a clean solution to be foudn there
[16:21:00 CEST] <wm4> *found
[16:23:02 CEST] <mateo`> the gst code look for symbols from the nativehelper lib, this lib exposes helpers to create / get java vms
[16:23:35 CEST] <wm4> so why can't the helper just be loaded directly?
[16:23:37 CEST] <mateo`> but on android, only one java vm is allowed
[16:24:11 CEST] <mateo`> the helper is not guaranteed to be installed everywhere
[16:25:12 CEST] <mateo`> this is what i've told
[16:25:25 CEST] <ubitux> if (!g_module_symbol (module, "_ZN13JniInvocation15jni_invocation_E",
[16:25:27 CEST] <ubitux> lol
[16:25:30 CEST] <ubitux> i don't want to read one more line
[16:26:54 CEST] <mateo`> and doing that would introduce a dependency over it
[16:28:28 CEST] <wm4> mateo`: is that dependency a problem?
[16:29:21 CEST] <mateo`> to be honest i don't know
[16:29:35 CEST] <mateo`> maybe it is in fact available on all the phone
[16:29:36 CEST] <mateo`> +s
[16:39:18 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07master:c08b06c22579: avcodec/jpeg2000dec: Check that step_x/y are valid before use in JPEG2000_PGOD_PCRL
[16:40:28 CEST] <mateo`> wm4: i see your point, if you use some lib that uses ffmpeg internally the lib has to tell explicitely its user either to call av_jni_register_java_vm function or its own init function that calls the register function, if there are multiple libs, multiple calls to that function
[16:42:31 CEST] <mateo`> but since only one java vm is allowed to run per process on android / and i think on some other java vm implementations too (not all though), i think it would be safe to only allow one call to this function (meaning successive calls will output a warning and does nothing)
[16:44:03 CEST] <wm4> I think this should be done in a way that pretends the problem doesn't even exist, and this nativehelper lib seems to allow doing it
[16:55:29 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07master:98b8bf12bcf5: avcodec/pngdec: Use av_malloc_array()
[17:23:53 CEST] <mateo`> wm4: i'll make some experiment with JNI_GetCreatedJavaVMs and see how it goes (i'm not huge fan of looking for that symbol in the current process / libdvm / libart though)
[17:38:09 CEST] <RiCON> hm, forgot to put a   in the webvtt sample
[17:49:33 CEST] <wm4> does anyone know if or how ff_h264_decoder.pix_fmts is initialized?
[17:54:11 CEST] <wm4> maybe this code is just for the old vdpau h264 thing (lol)
[18:19:33 CEST] <wm4> michaelni__: why is this code needed:
[18:19:35 CEST] <wm4>     if (h->avctx->pix_fmt == AV_PIX_FMT_NONE
[18:19:35 CEST] <wm4>         || (no n_j_pixfmt(h->avctx->pix_fmt) != non_j_pixfmt(get_pixel_format(h, 0))))
[18:19:35 CEST] <wm4>         must_reinit = 1;
[18:19:45 CEST] <wm4> I think you added it in ffd77f94a26be22b8ead3178ceec3ed39e68abc5
[18:20:03 CEST] <wm4> or does it come from the merged parent
[18:20:14 CEST] <wm4> (gitk being shit)
[18:20:35 CEST] <wm4> michaelni__: at this point, the profile is not necessarily set, so it can cause init failure in the hwaccel
[18:20:40 CEST] <wm4> or maybe worse, undefined behavior
[18:20:55 CEST] <wm4> (not in the C sense, but still)
[18:28:23 CEST] <wm4> and of course Libav still doesn't have this code, so everything works there
[18:28:24 CEST] <wm4> sigh
[18:34:29 CEST] <michaelni__> i think this check was needed to avoid crashes and its there since 2013, why is it causing a problem now ?
[18:35:23 CEST] <michaelni__> also what part of the API is violated by calling get_format() ?
[18:36:03 CEST] <wm4> I've removed it and fate still passes
[18:36:11 CEST] <wm4> the hwaccels are initialized with get_format
[18:36:41 CEST] <michaelni__> that sounds like a ugly hack honestly
[18:36:45 CEST] <wm4> but this code makes it somehow happen before the profile is set
[18:37:13 CEST] <wm4> yes I've complained about it before, but for now this is how get_format is supposed to work
[18:37:18 CEST] <nevcairiel> personally i have removed all references of J codecs in my local fork, at least from h264 and hevc, they cause all sorts of headaches with hwaccel re-init
[18:37:35 CEST] <wm4> meaning all information required to init a decoder needs to be known at get_format time
[18:38:41 CEST] <michaelni__> how can i reproduce that profile is not available when get_format is called ?
[18:39:08 CEST] <michaelni__> or rather ff_thread_get_format() in the current code
[18:39:12 CEST] <wm4> trying to upload a sample
[18:40:02 CEST] <cone-214> ffmpeg 03Paul B Mahol 07master:a99226133e07: avformat/rsd: support XADP tag
[18:40:53 CEST] <cone-214> ffmpeg 03Paul B Mahol 07master:f226c25a3740: avcodec/sipr: use AVERROR return code instead of -1
[18:43:46 CEST] <wm4> sample: https://0x0.st/io1.mp4
[18:48:24 CEST] <wm4> michaelni__: how can I reproduce a crash?
[18:49:42 CEST] <michaelni__> it was probably with a fuzzed file and a revission from 2013, i doubt the very same fuzed file would crash with master 
[18:52:30 CEST] <wm4> then I'm sending a patch
[18:57:14 CEST] <durandal_170> nevcairiel: what codecs?
[18:57:46 CEST] <nevcairiel> pixfmts, whatever
[18:58:53 CEST] <durandal_170> You sure everything sets colorrange?
[18:59:33 CEST] <nevcairiel> everything that i removed the pixfmts from
[18:59:43 CEST] <nevcairiel> i dont care if its always set to a J format
[18:59:51 CEST] <nevcairiel> i care if it causes a re-init to switch from or to J
[19:00:14 CEST] <wm4> durandal_170: yes our code does it properly, and pretends that J doesn't exist
[19:00:22 CEST] <wm4> but somehow ffmpeg itself can't get this done
[19:01:10 CEST] <jamrial> durandal_170: nice, rsd love :p
[19:21:39 CEST] <durandal_170> it sucks that I need to download complete 7z to test one file
[19:24:24 CEST] <cone-214> ffmpeg 03James Almer 07master:d2bf2d094ed6: x86/vf_w3fdif: move pxor outside the loop in w3fdif_complex_low
[19:25:40 CEST] <cone-214> ffmpeg 03Jean-Yves Avenard 07master:f05ff057ff41: configure: fix configure when using gcc
[19:48:05 CEST] <ubitux> jamrial: my boxes don't seem to report the aac issue
[19:48:08 CEST] <ubitux> +anymore
[19:48:14 CEST] <ubitux> though, the complain in h264 now.
[19:48:27 CEST] <ubitux> s/boxes/instances/
[19:49:33 CEST] <jamrial> yeah, noticed
[19:49:41 CEST] <jamrial> doesn't make much sense
[19:49:44 CEST] <ubitux> :(
[20:07:55 CEST] <BBB> durandal_170: poke
[20:08:14 CEST] <BBB> why does w3fdif_simple_high use movu and mova interchangeably for the same data pointers?
[20:31:25 CEST] <cone-214> ffmpeg 03Ganesh Ajjanagadde 07master:624057df3fd5: avfilter/buffersrc: add av_warn_unused_result attributes
[20:59:55 CEST] <durandal_170> BBB: I guess its not needed
[21:41:59 CEST] <n1n2> hi! is the demuxer itself responsible for maintaining timestamps (pts / dts)?
[21:54:20 CEST] <wm4> n1n2: yes
[21:54:44 CEST] <wm4> libavformat has some common code to make up timestamps for simple formats too
[21:54:47 CEST] <wm4> (like mp3)
[21:55:17 CEST] <n1n2> wm4, https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/aadec.c <-- is there a way to do timestamps with such demuxers?
[21:55:51 CEST] <wm4> don't know what you mean
[21:56:03 CEST] <wm4> but aacdec.c uses the common timestamp code
[21:56:23 CEST] <nevcairiel> (thats aa, not aac)
[21:56:27 CEST] <wm4> ooh
[21:56:49 CEST] <nevcairiel> pure audio formats dont really need timestamps fwiw
[21:56:52 CEST] <n1n2> wm4, aadec is somewhat tricky, and it has no notion of timestamps or pts / dts things.
[21:56:59 CEST] <nevcairiel> i think the common code will just generate a continous timestamp
[21:57:08 CEST] <wm4> n1n2: does it not return timestamps? pts at least
[21:57:31 CEST] <n1n2> nevcairiel, right, the underlying stream has something known as chapters (which are essentially marked in the data stream itself)
[21:57:46 CEST] <wm4> nevcairiel: well, for audio, pts is simply based on the sample number, isn't it
[21:58:06 CEST] <wm4> oh no are you the chapters-have-no-timestamps guy again
[21:58:13 CEST] <n1n2> nevcairiel, how do I see those common timestamps from within the aa_read_packet function itself? I would like to print them.
[21:58:36 CEST] <n1n2> wm4, maybe :-), sorry :)
[21:58:55 CEST] <wm4> you seem to be coming here every once in a while, and start asking these questions from scratch
[21:59:04 CEST] <wm4> from what I remember there's no easy solution
[21:59:21 CEST] <n1n2> av_log(s, AV_LOG_DEBUG, "Chapter %d (%" PRId64 " bytes)\n", c->chapter_idx, c->current_chapter_size); <--- if I can print the "common timestamp" here then my problems will be solved.
[21:59:46 CEST] <wm4> in this case, the demuxer itself exports no timestamps
[21:59:46 CEST] <nevcairiel> you cannot
[22:00:10 CEST] <wm4> and libavformat common code will make up timestamps by adding up the sample count each audio packet produces
[22:00:20 CEST] <n1n2> wm4, nevcairiel ah OK, I am pretty knew to ffmpeg, and wanted to make sure that I am not missing something obvious.
[22:00:31 CEST] <wm4> it does so by asking a codec parser (which analyzes each packet and returns how many samples there are in)
[22:00:43 CEST] <n1n2> s/knew/new
[22:01:10 CEST] <wm4> so unless there is some guarantee about how many bytes produce how many samples (like using a CBR codec), or there's an index, or you scan the whole file on opening
[22:01:14 CEST] <wm4> ...there's no solution
[22:01:16 CEST] <n1n2> wm4, would it be OK to introduce calls to "avcodec_decode_audio4" in aa_read_packet so that I can keep track of time?
[22:01:39 CEST] <wm4> n1n2: you could in theory do this
[22:01:49 CEST] <wm4> maybe better if you'd open a codec parser
[22:01:55 CEST] <wm4> but how would it help you with chapters?
[22:02:26 CEST] <n1n2> wm4, right, I could print these timestamps, and an external script can make a nice .cue file. I don't have a better idea :(
[22:03:39 CEST] <wm4> n1n2: what does the chapter data actually contain?
[22:04:10 CEST] <n1n2> wm4, the length of the current chapters in bytes, and the offset of the next chapter. 
[22:04:50 CEST] <n1n2> s/current chapters/current chapter
[22:04:54 CEST] <wm4> so are these chapters even any meaningful information?
[22:05:34 CEST] <wm4> or does the demuxer skip interesting extra information
[22:05:57 CEST] <n1n2> wm4, oh, the official software(s) are able to jump between chapters (which is super nice), but they jump in the data stream world (not in the timestamp world). hope this makes sense.
[22:06:19 CEST] <wm4> seems to be a really stupid format
[22:06:37 CEST] <wm4> supported codecs are mp3 and realaudio?
[22:06:48 CEST] <n1n2> wm4, 1990's were weird :P .. this format is from then :P
[22:07:10 CEST] <n1n2> wm4, mp3, and something called ACELP.net
[22:07:59 CEST] <wm4> I don't really know what CODEC_ID_SIPR is, I just remember it from realaudio mkv support
[22:08:03 CEST] Action: wm4 shudders
[22:08:28 CEST] <n1n2> oh, some proprietary crappy codec for human voice, I don't know anything else about it.
[22:09:31 CEST] <n1n2> I heard that mp3 generates variable frame sizes even in CBR mode. this might add also cause some problems (if we decide to calculate timestamps by using the length of the chapters only)
[22:59:52 CEST] <durandal_170> anyone reversing xma?
[23:04:10 CEST] <cone-214> ffmpeg 03Claudio Freire 07master:01ecb7172b68: AAC encoder: Extensive improvements
[23:04:32 CEST] <JEEB> \o/
[23:04:34 CEST] <nevcairiel> guess he gave up splitting it, huh
[23:05:24 CEST] <cone-214> ffmpeg 03Claudio Freire 07master:323d37521d66: AAC encoder: cosmetics from last commit
[23:08:23 CEST] <BBB> nevcairiel: whats the point of splitting for the sake of splitting
[23:08:40 CEST] <nevcairiel> i like small atomic commits
[23:09:00 CEST] <nevcairiel> easier to find and  pinpoint regressions that way
[23:09:34 CEST] <rcombs> \o/
[23:09:40 CEST] <Gramner> cool
[23:09:42 CEST] <rcombs> time to remove experimental flag?
[23:09:52 CEST] <JEEB> but because of hysterical raisins I guess the patch wasn't split
[23:10:03 CEST] <iive> nevcairiel: but if the blow up... they cause a lot of damage!
[23:10:12 CEST] <iive> ;)
[23:10:16 CEST] <rcombs> *rimshot*
[23:10:32 CEST] <nevcairiel> rcombs: they'll probably want to validate everything is working fine still
[23:10:49 CEST] <nevcairiel> iirc atomnuker said something about PNS or TNS breaking from one of the recent  changes last week
[23:12:30 CEST] <atomnuker> finally I can start merging my changes in as well
[23:12:37 CEST] <JEEB> :)
[23:33:06 CEST] <ubitux> omg aac
[23:35:38 CEST] <JEEB> yup
[23:35:41 CEST] <wm4> so uh what's the state of the aac encoder in git master
[23:35:49 CEST] <rcombs> better
[23:35:50 CEST] <ubitux> zomg state
[23:36:02 CEST] <rcombs> Tennessee
[23:36:11 CEST] <wm4> I mean
[23:36:14 CEST] <wm4> is that THE patch?
[23:36:21 CEST] <JEEB> yes
[23:36:29 CEST] <JEEB> that is THE patch from THE thread
[23:36:34 CEST] <ubitux> i think we're waiting for the ending touch from atomnuker?
[23:36:52 CEST] <ubitux> ...and probably the HA hord to make some tests to mature that code a bit
[23:37:36 CEST] <wm4> seeing that this stuff exists and got in is pretty awesome
[23:37:47 CEST] <jamrial> we were so close from 500 replies
[23:37:48 CEST] <JEEB> yeah, HA folk to rip it off
[23:37:55 CEST] <JEEB> and we'll see how it ends up
[23:38:33 CEST] <wm4> sometimes I feel libav* is too much about annoying-refactor-guys and accepting-substandard-patches-from-corporate-devs
[23:38:45 CEST] <wm4> instead of real codec dev
[23:39:28 CEST] <jamrial> maybe it's just that the former gets your attention more often than the latter
[23:40:23 CEST] <klaussfreire> It is THE patch. I have a few bugs identified that remain to be resolved though
[23:42:36 CEST] <klaussfreire> Sorry for the bigness of the patch. There was a lot of testing involved, and spliting it required exponential testing (I tried splitting it a bit, but the changes on their own didn't work well, so I would have been forced to tweak them so that they work well in isolation, retest everything, which means hours and hours of ABX testing - horrible)
[23:44:00 CEST] <cone-214> ffmpeg 03Ganesh Ajjanagadde 07master:3ae98497c2fc: ffmpeg: modify tty state when stderr is redirected
[23:45:15 CEST] <ubitux> klaussfreire: if you can do it incrementally from now on, that would be great though :)
[23:46:21 CEST] <klaussfreire> Yeah
[23:46:40 CEST] <wm4> well, it is hard to maintain a huge set of patches for a longer time
[23:48:31 CEST] <klaussfreire> Just a heads-up: the encoder is a lot slower now. We're hoping to improve performance slowly in the future, or at least provide a flag to make it faster (at the expense of some quality)
[23:50:37 CEST] <BBB> klaussfreire: how slow? like, how many seconds does it take to encode one second of audio at default settings?
[23:51:17 CEST] <klaussfreire> On my computer, it goes 4-7x realtime speed. On others 2x.
[23:51:30 CEST] <klaussfreire> I haven't seen it fall below realtime, but it's a possibility, especially for embedded processors
[23:51:35 CEST] <jamrial> why is there so much custom c code in the mips aac files?
[23:53:02 CEST] <BBB> jamrial: youd probably want to ask the mips people
[23:53:17 CEST] <BBB> reminds me of years ago, we had that same for one of the other platforms that I think was subequently removed
[23:53:24 CEST] <klaussfreire> Yeah. I'm just following what the original code seems to do: loop pipelining. I honestly don't get MIPS optimization as well, so the original mips people are welcome to go over it.
[23:53:52 CEST] <klaussfreire> I just had to do it in order to keep it working
[23:53:54 CEST] <kurosu> klaussfreire, is the slowness due to some search space, or eg the fact it needs to reencode if the previous result was too far from the target rate ?
[23:54:15 CEST] <klaussfreire> Search space most often
[23:54:34 CEST] <klaussfreire> It does 4x the iterations, and the iterations are more complex
[23:54:48 CEST] <BBB> I dont think 4x realtime is an issue really
[23:54:49 CEST] <BBB> I mean
[23:54:59 CEST] <BBB> have you seen 1080p vp9/hevc encoding times at top quality?
[23:55:30 CEST] <klaussfreire> Yes, exactly, but I thought I'd warn about the drop in performance anyway
[23:56:34 CEST] <kurosu> well, it's still interesting for people doing live encoding using this encoder
[23:56:54 CEST] <kurosu> *interesting to know
[23:58:03 CEST] <cone-214> ffmpeg 03Claudio Freire 07master:79f2014f1264: AAC encoder tests: increase fuzz for pred test
[00:00:00 CEST] --- Mon Oct 12 2015