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

[burek]

[00:19:50 CET] <darkapex> atomnuker: ping
[00:22:19 CET] <atomnuker> darkapex: pong?
[00:23:21 CET] <darkapex> Hi, I was working on updating the mlpenc.c file in the latest master of ffmpeg, some of my commits are here https://github.com/jailuthra/FFmpeg/tree/mlpencoder
[00:23:58 CET] <darkapex> It would be cool if you could review it and tell me if there are some glaring errors or if I'm doing something wrong
[00:25:41 CET] <darkapex> Plus the old encoder file is accessing some FilterParams members that never existed, I haven't exactly figured what should I exactly use in place of them.
[00:26:18 CET] <atomnuker> that malloc/free gets called on every frame, right?
[00:26:42 CET] <atomnuker> better do it in the init/close functions for the maximum filter count
[00:26:46 CET] <darkapex> Yep, I had some doubts here too, whether it would be suboptimal
[00:27:09 CET] <darkapex> Okay
[00:38:45 CET] <darkapex> Most of the compiling errors got fixed by fixing all the VLA issues, still some remain, and I think the git-history of ramiro's soc repo will point me to how to use coeff_bits. Here's the current make output http://pastebin.com/raw/XNrVcDTs 
[00:39:21 CET] <darkapex> *FilterParams.coeff_bits and coeff_shift
[00:39:32 CET] <darkapex> I'll ping you if I need help, thanks :)
[00:47:58 CET] <atomnuker> cool, nice progress
[00:48:53 CET] <atomnuker> if in doubt, just look at what the decoder does
[00:52:03 CET] <darkapex> sure thanks a lot :)
[02:57:10 CET] <cone-792> ffmpeg 03Michael Niedermayer 07master:de1de4932419: avformat/utils: fix dts from pts code in compute_pkt_fields() during ascending delay
[05:34:10 CET] <rcombs> how long has sofacoustics.org been down
[05:34:19 CET] <rcombs> (it's mentioned in the filters docs)
[05:38:52 CET] <cone-792> ffmpeg 03Michael Niedermayer 07master:50615791ca8c: fate: Add test similar to ticket 1242
[07:08:46 CET] <Timothy_Gu> Daemon404, nevcairiel: speak of the devil: https://github.com/FFmpeg/FFmpeg/pull/185/files
[07:28:51 CET] <twid> what is the exact purpose of libpostproc?
[07:33:53 CET] <sprkv5> hello durandal_1707 , i presume you're the mentor for "motion interpolation in libavfilter"
[07:34:36 CET] <sprkv5> I am Subhashish, CS undergrad and I am interested in taking up this project.
[07:43:24 CET] <twid> what is libpostproc is exactly used for?
[09:20:42 CET] <durandal_1707> sprkv5: questions?
[09:39:45 CET] <sprkv5> hello again durandal_1707 
[09:41:27 CET] <durandal_1707> sprkv5: hello
[09:42:55 CET] <sprkv5> Motion interpolation, I read about it here - https://github.com/mpv-player/mpv/wiki/Interpolation
[09:44:36 CET] <sprkv5> So my first question is - am looking at the right explanations? Or does libavfilter require something different?
[09:46:34 CET] <wm4> that wiki article briefly compares different types of interpolation
[09:46:48 CET] <wm4> I assume what's wanted here is "Motion-based interpolation"
[09:51:19 CET] <durandal_1707> sprkv5: yes, it even lists existing implementations
[09:53:47 CET] <sprkv5> Second, I would like to learn the architecture of libavfiilter, the way to hack and learn would be? would it be better if I try to solve bugs related to libavfilter or start with the implementation?
[09:56:46 CET] <sprkv5> this should help right? https://www.ffmpeg.org/ffmpeg-filters.html
[09:57:08 CET] <wm4> try to find out how simple filters work
[09:57:27 CET] <wm4> maybe things like vf_crop and vf_lut are good places to start
[09:57:41 CET] <sprkv5> okay
[09:57:58 CET] <sprkv5> what would be the test files if any?
[09:59:08 CET] <durandal_1707> sprkv5: the only thing you need to create for qualification task is creating frame side data with motion vectors
[09:59:46 CET] <durandal_1707> sprkv5: any nonstatic video file
[10:00:55 CET] <wm4> that sounds like a quite heavy qualification task
[10:01:49 CET] <durandal_1707> the motion vectors don't need to be perfect
[10:03:18 CET] <durandal_1707> but project is really non trivial one
[10:03:45 CET] <ubitux> sprkv5: http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/writing_filters.txt;hb=HEAD
[10:05:19 CET] <sprkv5> okay, the writing filters doc is a path ahead, i'll look into it;
[10:06:01 CET] <sprkv5> i'll also look into the generation of motion vectors from the frames of the video and report back with simple implementations
[10:06:37 CET] <ubitux> you might want to have a look at the codecview filter 
[10:08:07 CET] <sprkv5> thanks!
[10:09:01 CET] <sprkv5> my contact mail is sprkv5 at gmail.com, i've subscribed to the ffmpeg-devel mailing list
[10:22:36 CET] <BtbN> "bobobo-at-google.com at ffmpeg.org" huh, does the ML do that, or is this his actual email address?
[10:24:28 CET] <ubitux> i saw that with mats as well
[10:24:45 CET] <ubitux> maybe a privacy option in the ml?
[10:25:01 CET] <BtbN> well, it's kinda useless as the real bobobo at google.com is in the mail headers
[10:26:02 CET] <ubitux> i don't think scammers often register to ml to get mails
[10:26:15 CET] <ubitux> more likely they're crawling archives etc
[10:26:30 CET] <BtbN> hm, yeah. So i wonder which E-Mail I should put as git author
[10:27:39 CET] <ubitux> Author: Wan-Teh Chang <wtc-at-google.com at ffmpeg.org>
[10:27:44 CET] <ubitux> Author: Mats Peterson <matsp888-at-yahoo.com at ffmpeg.org>
[10:28:08 CET] <ubitux> probably mistakes but a common one
[10:28:12 CET] <ubitux> :)
[10:28:57 CET] <BtbN> I can't figure out a propper workflow to apply E-Mail based patches, so I apply them manualy. Probably wouldn't have noticed otherwise either.
[11:09:29 CET] <michaelni> ubitux, alot of your fate clients seem to have an issue with iv8-demux, not sure but ive not seen this locally ...
[11:11:43 CET] <ubitux> huh yeah wtf is wrong
[11:14:54 CET] <michaelni> ubitux, btw, about <wtc-at-google.com at ffmpeg.org> <-- that from rewriting is needed due to DMARC otherwise the mail will bounce as our mail server is not authorized to send @google.com mails
[11:15:15 CET] <michaelni> it will become more common likely and sadly
[11:21:56 CET] <cone-836> ffmpeg 03Lucas Cooper 07master:fd55470c657f: avcodec/nvenc: Add encoder stats
[11:21:56 CET] <cone-836> ffmpeg 03Timo Rothenpieler 07master:f2bdf9d26a23: avcodec/nvenc: Fix typo and preset error message
[11:32:59 CET] <BtbN> So does ffmpeg now redirect all mails it gets in response to such addresses, or do they just bounce?
[11:39:52 CET] <cone-836> ffmpeg 03Lior Mualem 07master:baec6d8affc6: ffserver: Fixed ffserver to support large ffm files
[11:40:01 CET] <ubitux> michaelni: http://sprunge.us/OXOd
[11:40:10 CET] <ubitux> this should be 7a97e6e1d0c79d4c5687f5b552e33a0d
[11:40:22 CET] <ubitux> rsync might be broken either client or server side
[11:42:00 CET] <ubitux> there is like 1 bit off
[11:42:42 CET] <michaelni> ubitux, maybe try -c, --checksum              skip based on checksum, not mod-time & size
[11:43:05 CET] <ubitux> rsync: The server is configured to refuse --checksum (-c)
[11:43:28 CET] <ubitux> was that file introduced recently btw?
[11:43:41 CET] <BtbN> maybe some bitrot on the hdd?
[11:43:51 CET] <ubitux> i checked dmesg, no i/o errors
[11:44:09 CET] <BtbN> well, a bit flipping wouldn't cause any errors
[11:44:19 CET] <ubitux> i just want to check if it's a fs issue (maybe raid bug)
[11:44:26 CET] <ubitux> or if it's a transmission issue
[11:46:21 CET] <ubitux> so iv8-demux wasn't introduced recently, so it's unlikely a transmission issue (i didn't remove the samples recently)
[11:46:45 CET] <ubitux> so i guess that's a raid issue of some sort...  
[11:48:39 CET] <ubitux> anyway, i rm'ed the file and updated the samples again
[11:51:56 CET] <BtbN> A single bit flipping in files isn't very uncommon.
[11:53:28 CET] <BtbN> Since i migrated my server to ZFS it already corrected 2 checksum errors.
[12:12:46 CET] <cone-836> ffmpeg 03Paul B Mahol 07master:f78ef2d885aa: avfilter/vf_vectorscope: short for Magenta is Mg
[13:42:15 CET] <durandal_1707> michaelni: this format negotiation in lavfi needs to be extended
[13:49:45 CET] <ismail> finally sent the schannel configure patch
[13:49:51 CET] <ismail> please review :)
[14:02:17 CET] <J_Darnley> You claim that it won't break because Windows is case insensitive.  I must try it then.
[14:05:12 CET] <ismail> please
[14:08:17 CET] <J_Darnley> Oh you said msvc.  I guess I can't test that part then.
[14:08:23 CET] <J_Darnley> sorry
[14:09:15 CET] <nevcairiel> you could still try whatever is on your mind
[14:09:21 CET] <ismail> J_Darnley: do you have msys on windows? That would be also good to test
[14:10:02 CET] <J_Darnley> No.  I use cygwin or cygwin's mingw64 compilers and my libraries are lowercase
[14:10:16 CET] <ismail> J_Darnley: ok thats the same case as Linux
[14:10:24 CET] <ismail> so it'll work for you too
[14:10:34 CET] <nevcairiel> cygwin is actually smart though, it ignored the case before already
[14:10:57 CET] <ismail> true
[14:11:04 CET] <J_Darnley> Except I am looking to make it fail because I enabled case sensitivity long ago.
[14:12:20 CET] <ismail> it would already fail for you before the patch.
[14:12:28 CET] <ismail> it looks for uppercase Secur32 lib
[14:13:07 CET] <nevcairiel> because thats how the microsoft sdk lib is named :D
[14:13:18 CET] <ismail> nevcairiel: yes true.
[14:13:58 CET] <nevcairiel> security.h is lowercase even in the ms sdk though
[14:14:08 CET] <nevcairiel> the docs just have it uppercase
[14:14:24 CET] <ismail> so we are halfway there already ;)
[14:26:43 CET] <Daemon404> Timothy_Gu, you make me sad
[14:28:44 CET] <guest___> @michaelni: Sir can you tell me which type of bugs are we related to the project in ffmpeg
[14:36:20 CET] <durandal_1707> guest___: which project?
[14:37:55 CET] <guest___> @durandal_1707: Project which you are in involving in the GSoC. I am asking about the kind of bugs we have to deal with within this project?
[14:39:25 CET] <durandal_1707> I'm still confused, for list of bugs see trac.ffmpeg.org
[14:41:15 CET] <guest___> @durandal_1707: Can you tell me more that how can i contribute in your open source projects?
[14:41:40 CET] <toot> maybe you mean this list? https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016
[14:43:44 CET] <guest___> @toot: Yes,I am talking about one of your project named Improve Selftest coverage. I wanted to know more about it?
[14:48:35 CET] <arthcp> For GSOC I would like to work on the project to implement missing features in AAC decoder
[14:48:50 CET] <arthcp> It doesn't have a mentor
[14:49:01 CET] <arthcp> how exactly should I proceed?
[14:49:55 CET] <arthcp> Do I search for a mentor first or do I directly start working on the qualification task?
[14:53:09 CET] <wm4> arthcp: you should first make sure that you have a mentor
[14:53:48 CET] <cone-836> ffmpeg 03Muhammad Faiz 07master:fd0c9789cfe8: avfilter/avf_showcqt: add performance debugging log
[14:55:20 CET] <arthcp> wm4: do i ask people individually for mentor me?
[15:00:22 CET] <BBB> find people who know something about aac
[15:00:37 CET] <atomnuker> IMO that project is challenging
[15:00:38 CET] <BBB> e.g. git log libavcodec/aacdec.c and look at authors of relevant patches touching actual coding technology
[15:00:44 CET] <atomnuker> too challenging
[15:00:46 CET] <BBB> atomnuker is one of them :)
[15:01:41 CET] <Daemon404> im pretty sure asking people to find their own mentor is not gsoc olicy
[15:01:43 CET] <Daemon404> policy*
[15:01:49 CET] <Daemon404> that's supposed to be our job
[15:02:04 CET] <arthcp> I talked to thilo regarding another project about implementing mpeg4 als encoder
[15:02:15 CET] <arthcp> he said that too is very challenging
[15:02:32 CET] <atomnuker> everything in the encoder and decoder assumes that the window sizes are 128 or 1024, so it'd be hard to actually fit support for 960/120 without huge amounts of duplication and/or breakages
[15:03:01 CET] <Daemon404> or giant macros
[15:03:16 CET] <Daemon404> a simple way is to do something like
[15:03:27 CET] <Daemon404> #define WINDOW_SIZE 960
[15:03:31 CET] <Daemon404> #include "implementayion.c"
[15:03:33 CET] <Daemon404> in 2 files
[15:03:35 CET] <Daemon404> or w/e
[15:04:01 CET] <atomnuker> that file would be templated 4 times over even in that case (for fixed and float decoders)
[15:04:14 CET] <Daemon404> blame the people who 
[15:04:18 CET] <Daemon404> made aac
[15:04:18 CET] <Daemon404> ?
[15:04:22 CET] <atomnuker> SSR would be just as challenging
[15:05:59 CET] <arthcp> I have worked with audio previously
[15:06:34 CET] <arthcp> and my college has a multimedia teacher who could help me out if needed
[15:07:05 CET] <arthcp> I think i'll give the project a try
[15:08:19 CET] <arthcp> is there anybody here who could mentor me?
[15:15:17 CET] <guest___> quit
[15:17:09 CET] <durandal_1707> arthcp: and what would be your qualification task?
[15:18:00 CET] <arthcp> I need to fix a bug related to AAC
[15:18:16 CET] <arthcp> I haven't selected a bug yet
[15:20:46 CET] <durandal_1707> well, if you really want aac project you would need to complete that qualification task, I can be your mentor. 
[15:21:40 CET] <durandal_1707> and isn't policy that you code alone?
[15:21:48 CET] Action: rcombs points at PCEs
[15:22:35 CET] <rcombs> ^ fair bit of that is already done thanks to atomnuker, in general it shouldn't be too complex, and it'd probably at least give you a good look around at least some parts of the encoder
[15:22:44 CET] <arthcp> durandal_1707: i'll code alone i was just saying he could mentor me if need be
[15:23:51 CET] <arthcp> but now that i have a mentor, it wouldn't be required
[15:24:41 CET] <arthcp> durandal_1701: do you want me to work on any specific bug?
[15:27:32 CET] <durandal_1707> no, feel free to pick any aac related
[15:28:14 CET] <durandal_1707> tell me which so I could tell you if its fine
[15:28:34 CET] <arthcp> okay! i'll inform you in some time.
[15:33:47 CET] <cone-836> ffmpeg 03Mats Peterson 07master:e1aa88dc09a7: lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
[16:43:49 CET] <cone-836> ffmpeg 03Moritz Barsnick 07master:72babb8566bd: lavc/mjpegdec: avoid printing useless message in default log level
[17:03:10 CET] <cone-836> ffmpeg 03Moritz Barsnick 07master:8a90e0fd21f7: lavf/mp3dec: avoid printing useless message in default log level
[17:38:29 CET] <cone-836> ffmpeg 03Shivraj Patil 07master:b59d06d5f415: configure: add check_inline_asm_flags()
[17:38:30 CET] <cone-836> ffmpeg 03Shivraj Patil 07master:8ca2c872b650: configure: build fix for P5600 with mips code restructuring
[17:48:57 CET] <nevcairiel> rcombs: dont get your hopes up, the task is about decoding =p
[17:49:04 CET] <rcombs> ah
[17:57:49 CET] <atomnuker> yes, we can decode PCEs, but no idea whether the channel mapping will be correct
[18:02:07 CET] <kierank> peloverde: quite interesting what these argon people have done
[18:02:11 CET] <kierank> with their "spec compiler"
[18:02:19 CET] <Daemon404> argon?
[18:19:09 CET] <nevcairiel> Daemon404: http://www.argondesign.com/products/argon-streams-hevc/
[18:19:38 CET] <nevcairiel> also vp9 i think
[18:49:16 CET] <Zeranoe> Are there H.264 decoder features that are GPL only and thus will be disabled with an LGPL build?
[18:49:58 CET] <Daemon404> i dont think so
[18:51:20 CET] <Zeranoe> Does it support other profiles than Main?
[18:51:29 CET] <JEEB> yes
[18:51:30 CET] <Zeranoe> (If built for LGPL)
[18:51:54 CET] <JEEB> there's actually not that much GPL-specific stuff in general within libavcodec
[18:52:00 CET] <JEEB> some MPEG-2 asm from libmpeg2 I think?
[18:52:03 CET] <JEEB> some FLAC asm?
[18:52:15 CET] <nevcairiel> there is like one optimized DSP function thats GPL only
[18:52:23 CET] <Daemon404> and its mmx or something
[18:52:24 CET] <nevcairiel> so it might be minimally faster in GPL
[18:52:35 CET] <jamrial> Zeranoe: h264 doesn't care what license you choose
[18:53:53 CET] <Shiz> i always wondered if there was a list of gpl stuff...
[18:54:02 CET] <jamrial> license.md
[18:54:20 CET] <nevcairiel> most gpl components are avfilter things
[18:54:23 CET] <jamrial> but it's not 100% correct. it mentions a libavcodec/x86/idct_mmx.c file that doesn't exist
[18:54:35 CET] <nevcairiel> it keeps being forgotten when things are refactored
[18:54:49 CET] <JEEB> http://up-cat.net/p/6c73933c
[18:55:21 CET] <JEEB> although I guess those are just things that get changed during compilation
[18:55:34 CET] <JEEB> configure just disables something altogether if the license is not compatible
[18:55:35 CET] <Zeranoe> So to summarize: The internal H.264 decoder will preform the same (speed wise) and contain the same features regardless of the licenses FFmpeg is built with?
[18:55:47 CET] <JEEB> Zeranoe: yes
[19:01:22 CET] <Zeranoe> Thank for the clarification. I asked because ramiro seems to have been under a different opinion: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=311#p991
[19:02:01 CET] <JEEB> that probably includes all of the rest around it
[19:02:34 CET] <JEEB> I'm not sure if the AVC decoder uses those libmpeg2 optimizations that you can notice being matched in my grep :P
[19:02:55 CET] <Timothy_Gu> JEEB: in ppc optim there's a comment on libmpeg2
[19:03:08 CET] <Timothy_Gu> the author seems to have released it under LGPL for FFmpeg
[19:04:00 CET] <JEEB> Timothy_Gu: isn't the me_cmp stuff under GPL from there?
[19:04:26 CET] <Timothy_Gu>  /shrug
[19:04:29 CET] <JEEB> ok, so this definitely is one thing under GPL
[19:04:31 CET] <JEEB> SET_CMP_FUNC(dct264_sad)
[19:04:36 CET] <JEEB> in me_cmp.c
[19:04:44 CET] <Timothy_Gu> It's not used anywhere though
[19:05:03 CET] <Timothy_Gu> See http://coverage.ffmpeg.org/src/libavcodec/me_cmp.c.gcov.html
[19:05:09 CET] <Timothy_Gu> l. 388
[19:05:11 CET] <JEEB> hah
[19:05:56 CET] <Daemon404> BBB, you are talking to a wall
[19:24:49 CET] <BBB> Daemon404: ?
[19:24:59 CET] <Daemon404> mats
[19:25:05 CET] <Daemon404> in one ear, out the other
[19:25:08 CET] <Daemon404> spam keeps coming
[19:26:50 CET] <BBB> very frustrating
[19:34:44 CET] <jamrial> if he doesn't stop just force unsubscribe him from the ml so his emails have to be moderated. that way all the nonsense self replies can be ignored and only the latest iteration of every patch is allowed to pass through at the end of the day
[19:35:00 CET] <Daemon404> thats a huge workload for the mod
[19:35:07 CET] <Daemon404> remember 20% of all ML traffic is him
[19:35:58 CET] <thardin> mats list
[19:36:06 CET] <BBB> mats-list at ffmpeg.org?
[19:36:26 CET] <Daemon404> whats with his email btw
[19:36:39 CET] <Daemon404> its like his-email-at-yahoo-dot-com at ffmpeg.org
[19:36:41 CET] <Daemon404> or something
[19:37:22 CET] <JEEB> seemingly mail servers have an issue with ffmpeg.org MX sending e-mails for random addresses
[19:45:56 CET] <nevcairiel> mailing lists arent exactly a new invention, you would think there would be a proper solution to those
[20:00:48 CET] <ubitux> huh
[20:00:56 CET] <ubitux> someone kept the subtitles thing in the gsoc page?
[20:02:13 CET] <durandal_1707> yes, smth wrong?
[20:03:11 CET] <ubitux> it's not up-to-date at all
[20:03:44 CET] <ubitux> well, not that much mentioned actually
[20:29:37 CET] <rcombs> JEEB: well yeah, of course they would
[20:30:01 CET] <rcombs> JEEB: that's all kinds of SPF violation and we obviously don't have the DKIM signing keys for everybody's domains
[20:30:07 CET] <JEEB> yup
[20:41:10 CET] <Gramner> something something X-Original-Authentication-Results to deal with SPF. not sure how well it works though
[20:50:29 CET] <rcombs> relies on the receiving mail server explicitly trusting the forwarder (here, ffmpeg's mailing list server)
[20:58:55 CET] <qiubit> Hey, I'm fairly new to ffmpeg and I want to do some fuzz testing on libavformat, libavcodec... Any suggestions on some new/untested features that might hide some bugs? Maybe users complaining about something recently?
[21:01:03 CET] <llogan> kierank might be able to answer your questions about that. also, if you qualify for Outreachy or GSoC you may be interested in https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#CreateafuzzingtestsuiteforFFmpeg
[21:01:37 CET] <jamrial> qiubit: look at changelog for recently commited decoders. things like Cineform HD, dxv, VC-2 HQ profile
[21:02:32 CET] <kierank> qiubit: hello, was it you who emailed me today?
[21:02:44 CET] <qiubit> kierank: yup, that's me :)
[21:06:47 CET] <wm4> ubitux: you want a beginner parse a XML format (that _nobody_ on this earth uses) with smil helper functions?
[21:07:31 CET] <ubitux> wm4: https://en.wikipedia.org/wiki/Universal_Subtitle_Format walking through subtitles should be doable
[21:07:59 CET] <wm4> I mean more like that parsing XML with those smil helpers is total crapshoot
[21:08:00 CET] <ubitux> check the sami demuxer, it's not that much work
[21:08:12 CET] <ubitux> well, using xml lib might be tricky
[21:08:22 CET] <ubitux> since as soon as you shit a tag, it's often a nightmare
[21:08:30 CET] <ubitux> but i might be wrong
[21:08:48 CET] <ubitux> i'm fine with using an xml lib though
[21:09:04 CET] <ubitux> it was just a suggestion
[21:09:07 CET] <ubitux> again, i'm not a mentor
[21:09:25 CET] <qiubit> kierank: BTW, I've been thinking about how to approach this fuzzing issue (never done that before). From what I read, to get good results, I would need a lot of testcases, so I need to create them somehow. I've been thinking about looking at code coverage stats, latest commits, then based on that create a list of potentially bugged features, and then take a bunch of files that would test them...
[21:09:27 CET] <Daemon404> ubitux, parsing xml is a nightmare regardless
[21:09:35 CET] <JEEB> ^this
[21:09:49 CET] <Daemon404> hope you like trees
[21:09:53 CET] <ubitux> we are able to parse broken html
[21:09:58 CET] <JEEB> esp. with user based input
[21:10:00 CET] <ubitux> we should be able to deal with clean xml
[21:10:08 CET] <Daemon404> >subtitles
[21:10:10 CET] <Daemon404> >clean
[21:10:11 CET] <Daemon404> pick one
[21:10:17 CET] <qiubit> kierank: ...split them into a lot of smaller files (for example 1 minute video to a lot of 5 seconds segments) and then start fuzzing software. What do you think? Does that sound good?
[21:10:30 CET] <kierank> qiubit: I would do it for now based on the most recent commit
[21:10:42 CET] <kierank> Like we do with fate testing fate.FFmpeg.org
[21:11:01 CET] <kierank> The easiest way is to use short videos
[21:11:14 CET] <kierank> And other samples from the internet or samples.videolan.org
[21:11:40 CET] <kierank> samples.FFmpeg.org I mean
[21:11:55 CET] <qiubit> hmmm, ok, will check that out, thanks for the suggestions
[21:13:12 CET] <wm4> <ubitux> we should be able to deal with clean xml <- but getting this right is tricky
[21:13:22 CET] <wm4> which is why XML libs are _always_ bloated and broken
[21:13:27 CET] <ubitux> who cares about usf anyway
[21:13:32 CET] <ubitux> it's just as an exercise anyway
[21:13:50 CET] <ubitux> approximately locating the text and the timing is enough to cover 90% of the case
[21:13:50 CET] <wm4> ok, just don't merge it into lavc
[21:14:16 CET] <ubitux> wm4: look at the sami demuxer
[21:14:31 CET] <ubitux> pretty sure we can do something similar
[21:14:47 CET] <wm4> well what this demuxer does is Wrong
[21:15:02 CET] <ubitux> yeah, it can be improved
[21:15:20 CET] <ubitux> but it's not proper xml
[21:15:38 CET] <ubitux> it's 90' broken html handly edited madness
[21:15:54 CET] <ubitux> so... you can't rely on a structure
[21:16:19 CET] <wm4> oh right, sami is not proper xml
[21:16:50 CET] <wm4> but SMIL is
[21:22:34 CET] <BBB> please dont write your own xml parser
[21:22:35 CET] <BBB> please
[21:22:38 CET] Last message repeated 1 time(s).
[21:22:38 CET] <BBB> please pretty
[21:24:35 CET] <ethe> Why write a parser, when you can write a regex?
[21:25:17 CET] <Shiz> please don't use xml
[21:27:33 CET] <BBB> Shiz: input can be xml
[21:37:08 CET] <ubitux> BBB: too late
[21:37:10 CET] <ubitux> :s
[21:37:20 CET] <BBB> crapcrapcrapcrapcrap
[21:37:28 CET] <BBB> its not in a release yet can we rm -fr it?
[21:37:36 CET] <ubitux> it's used in multiple demuxers
[21:38:56 CET] <BBB> ff_htmlmarkup_to_ass?
[21:39:20 CET] <Compn> iirc we didnt want to pull in any xml libs to convert our subtitles ?
[21:39:28 CET] <Compn> or not
[21:39:30 CET] Action: Compn runs
[21:39:40 CET] <ubitux> BBB: ff_smil*
[21:41:00 CET] <BBB> :'(
[21:41:35 CET] <ubitux> :(
[21:41:43 CET] <TD-Linux> ooh can I write mmx for it
[21:41:55 CET] <ubitux> for ff_smil* functions?
[21:42:00 CET] <ubitux> that will please BBB 
[21:42:06 CET] <BBB> no it won't
[21:42:08 CET] <ubitux> :D
[22:00:43 CET] <rcombs> so Slack introduced audio calling
[22:00:48 CET] <rcombs> with webrtc and opus
[22:01:30 CET] <rcombs> nothing really ffmpeg-related in there, but I thought it was pretty neat
[22:01:43 CET] <rcombs> and it sounded excellent despite being very low-bandwidth
[22:03:06 CET] <rcombs> and they're spending more CPU doing an animated effect around the speaker's avatar than on actually processing audio
[22:07:46 CET] <rcombs> "The audio quality was so good, I could actually hear an echo of myself through someone elses computer and easily recognize that it was me instead of a garbled mess."
[22:08:49 CET] <cone-905> ffmpeg 03Paul B Mahol 07master:209cff2d9ca1: avfilter/vf_waveform: make sure that x/y for text position is positive
[22:10:19 CET] <jkqxz> That's a brilliant way of saying "the echo cancellation sucks epically".
[22:10:56 CET] <rcombs> well that's tangential to the actual audio quality
[22:11:03 CET] <rcombs> (and I didn't hear any echo myself)
[22:57:00 CET] <Timothy_Gu> 3500 stars on GitHub today
[23:16:04 CET] <cone-905> ffmpeg 03Paul B Mahol 07master:b3e037181891: avfilter/vf_waveform: make it possible to draw dots instead of lines
[23:16:17 CET] <ethe> Could low throughput be a cause of noise in a realtime muxer?
[23:17:26 CET] <nevcairiel> you mean like a jack output which feeds an actual hardware buffer in realtime? then sure, if  you cant keep the buffers full, its going to give you glitches
[23:18:25 CET] <ethe> nevcairiel: that's awfully specific, and yes... exactly like that.
[23:18:43 CET] <nevcairiel> well i do remember what you are working on =p
[00:00:00 CET] --- Wed Mar  9 2016