[00:00] <BBB> I was about to say, smush sounds super-familiar [00:00] <BBB> actually, so wait, libav is now back porting all of ffmpeg? [00:00] <BBB> isn't that ... kind of a waste of time? [00:01] <BBB> so you have now two identical projects, not just double-merging each other's patches, but active double-reviewing and sometimes even double-developing? [00:01] <BBB> now to mention double-indenting [00:01] <BBB> omg [00:05] <iive> :) [00:21] <cone-625> ffmpeg.git 03Carl Eugen Hoyos 07master:3d5c859fa6dc: Set Matroska private data when muxing Prores. [00:21] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:01a5d7178914: Merge remote-tracking branch 'cehoyos/master' [01:34] <Plorkyeran_> double-reviewing is probably useful [01:34] <Plorkyeran_> more people looking over changes is rarely a bad thing [02:15] <cone-625> ffmpeg.git 03Stephan Hilb 07master:5dae3cf35729: lavc/cpia: fix typo in log message [02:15] <cone-625> ffmpeg.git 03Stephan Hilb 07master:541bebd41401: lavc/cpia: use avpriv_report_missing_feature() [02:51] <cone-625> ffmpeg.git 03Janne Grunau 07master:8675bcb0addb: aarch64: add armv8 CPU flag [02:51] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:4c57c6a7655f: Merge commit '8675bcb0addb1c7fb0b04682d1f3f95d5b8dae14' [02:58] <cone-625> ffmpeg.git 03Janne Grunau 07master:d3789eeeed34: aarch64: implement videodsp.prefetch [02:58] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:190106e884a2: Merge commit 'd3789eeeed3423bd1ca9dc40030a2f7a21ea5332' [03:18] <cone-625> ffmpeg.git 03Timothy Gu 07master:5ce7ca68b868: libxvid: add working lumimasking and variance AQ [03:18] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:072278c77798: Merge commit '5ce7ca68b86856ee8e9d6530dffdadc4eca4f8d1' [03:27] <cone-625> ffmpeg.git 03Timothy Gu 07master:c389a8049430: libxvid: Add SSIM displaying through a libxvidcore plugin [03:27] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:a7a82f2f22af: Merge commit 'c389a804943095ebf078daec6b64690d2c97069c' [04:05] <cone-625> ffmpeg.git 03Luca Barbato 07master:e10fd08aa7fb: h264: Refactor decode_nal_units [04:05] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:0ecb3075c1c2: Merge commit 'e10fd08aa7fbe8645545ad2e8721f0ed03c8e06a' [04:16] <cone-625> ffmpeg.git 03Timothy Gu 07master:f73495686d10: adler32: Fix doxy group definition [04:16] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:a6fa3a476afb: Merge commit 'f73495686d109ffffaa8c0387e790e7997326229' [04:18] <cone-625> ffmpeg.git 03Timothy Gu 07master:486e3649cef5: xtea: Add Doxy @file and group [04:18] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:13aa5757643e: Merge remote-tracking branch 'qatar/master' [04:57] <cone-625> ffmpeg.git 03Michael Niedermayer 07master:a75ba1e116a4: avcodec/h264/find_start_code: factorize addition out [05:22] <cone-625> ffmpeg.git 03Thilo Borgmann 07master:fdaf8372c27e: configure: Check for generated output in check_header_oc. [05:24] <cone-625> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:0c5a6ef886da: ffserver: nits & typos [05:24] <cone-625> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:5267a5d78312: rtspcodes: add full list of RTSP status codes [05:24] <cone-625> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:02497a5dc8c9: ffserver: don't hardcode RTSP status codes [10:39] <ubitux> wm4: btw, about you utf16 question, maybe we should try to ask opensubtitles.org or a similar website [10:39] <ubitux> they probably have tons of shit wandering [10:41] <ubitux> > opensubtitles.org is supporting these subtitle formats: *.srt, *.sub, *.smi, *.txt, *.ssa, *.ass, *.mpl - please don't upload UTF 16/32 files [10:41] <ubitux> heh. [10:42] <ubitux> > utf32 [10:42] Action: ubitux shivers [10:42] <wm4> how do you ask a website [10:42] <wm4> anyway, *.mpl is actually used? [10:43] <ubitux> dunno, we could contact the staff [10:43] <ubitux> wm4: seems so [10:43] <ubitux> maybe they provide some stats [10:44] <ubitux> http://www.opensubtitles.org/en/statistics nothing really interesting here.. [10:57] <ubitux> http://halide-lang.org/?#overview opinions? [12:10] <tmartiro_> hi folks! [12:10] <tmartiro_> I need your help [12:10] <tmartiro_> is there any example how to cut video by startime and endtime using C API ? [12:10] <Compn> did you check the wiki ? [12:10] <Compn> in any case, i dont know :) [12:12] <tmartiro_> this is dev channlel , isn't this? [12:13] <Compn> yes [12:13] <Compn> stick around , maybe one of the devs knows the example [12:13] <tmartiro_> ok, thanks [12:14] <Compn> its a bit early in the morning for everyone (on the east coast of usa anyways) [12:14] <tmartiro_> Compn, I will wait for the answer [12:15] <wm4> <tmartiro_> is there any example how to cut video by startime and endtime using C API ? <- uh the API is so low level that this question doesn't make sense [12:15] <wm4> libavformat can demux video and seek, libavcodec can decode video... [12:15] <wm4> there's no such thing as "cutting" video on time boundaries [12:16] <wm4> so the example you want would basically require a full-fledged transcoder [12:16] <tmartiro_> working with command line, there is the option to copy video from input file using startime and duration into output file [12:17] <tmartiro_> I need same functionality usin C api, to port it on android [12:17] <tmartiro_> as library [12:17] <Compn> ffmpeg runs on android, you dont want to just run it that way ? :P [12:17] <ubitux> if stream copy, then it's using seek for initial time, and then stop when reaching a given ts [12:18] <ubitux> that's all, rest is a simple classic packet copy loop which you can find in the examples [12:19] <tmartiro_> thanks folks! [12:48] <BBB> nice troll ubitux. and so true [12:48] <ubitux> i'm trolling? :( [12:49] <BBB> "instead of wasting our time, please keep wasting yours" [12:49] <BBB> so true [12:49] <BBB> that was you right? [12:49] <ubitux> indeed [12:49] <BBB> I think that's a troll, right? [12:49] <BBB> very good one too [12:50] <ubitux> :p [12:50] <Compn> koda will think you are biting him on the mailing list [12:51] <Compn> because of your mean words :P [12:54] <ubitux> Compn: so what? it's not like he's trying to improve the situation, he just want ffmpeg to stop merging by taking a fake good samaritan posture [12:57] <pross-au> "whats good for the goose, is good for the gander" [13:09] <wm4> ubitux: these days, everything slightly provocative is called "trolling" [13:13] <Compn> difference of opinion is trolling now :( [13:14] <Compn> ubitux : yes i realized that and i apologize for bugging everyone about working with libav. i thought it was an honest attempt but nope [13:14] <Compn> its the same 'do everying libav way , no negotiation, no change' [13:15] <pross-au> granted vittorio is the nkob [13:19] <wm4> ok I can't tell whether I'm joking or not in the last part of the mail I just sent [13:20] <kierank> wm4: i was about to say [13:20] <kierank> that's nuts [13:21] <pross-au> wm4: isnt that whats happening now? its just really s-l-o-w. [13:21] <wm4> yeah, and Libav is still pretty different from FFmpeg in some parts [13:22] <pross-au> do you think the have the manpower to do it? [13:24] <Compn> i dont think libav wants to merge from ffmpeg [13:24] <Compn> or review+merge whatever [13:25] <Compn> like ubitux said, its been 3 years, why start now ? [13:25] <pross-au> they just want the patchez [13:26] <wm4> Compn: recently they did start to cherry-pick more stuff [13:26] <pross-au> yeah vittorio is doing it [13:26] <wm4> probably panic due to debian picking up ffmpeg again [13:26] <Compn> only koda (vittorio) , not the whole dev team [13:26] <pross-au> what happened to the libav devs? [13:26] <Compn> has started merging [13:28] <pross-au> i recall there being many more. [13:29] <Compn> pross-au : mans and jason (x264 guy) left [13:30] <JEEB> the latter I think just mostly is being less involved in OSS in general, at least on these sides of things [13:30] <Compn> they gained a few more people, it does seem less quiet [13:31] <pross-au> fair enough [13:31] <JEEB> mans was well... his usual self, and I'm actually rather happy that he no longer is around :P [13:32] <Compn> developer numbers do fluctuate in both projects [13:32] <JEEB> otherwise it's usual folk, elenril, kostya, lu, diego [13:32] <JEEB> yeah [13:36] <cone-285> ffmpeg.git 03Matt Oliver 07master:158a80cc0b51: Remove leal op to fix icl inline asm. [13:38] <kurosu_> Justin Ruggles also did/was the last to do things nobody among them is really able to do (asm, audio stuff) [13:42] <JEEB> talking about asm, janne's accomplishments on that field seem nice? he has mostly been playing around with ARM, though [13:42] <JEEB> for audio there's still peloverde, mostly for review purposes as he's not overly active :) [13:42] <JEEB> (he's one of the AAC maintainers) [13:43] <kurosu_> I have only a narrow view on this topic [13:43] <kurosu_> but currently, janne is the only one that makes some things possible [13:43] <kurosu_> ie adapt arm code to change things in the C part [13:44] <kurosu_> and yes, he has been very helpful to me - but that's, again, a small topic [13:44] <kurosu_> peloverde contributed recently some missing stuff to the aac decoder - actually some unused dsp stuff is now tested [13:45] <kurosu_> so probably but he looks inactive to me [13:45] <JEEB> there's always plenty of lurkers [13:45] <JEEB> didn't take long for me to get a review on a patch I was asked to poke around [13:46] <nevcairiel> half of the active dev power goes into cosmetics though, so the actual-code-writing seems lower due to that [13:46] <kurosu_> you mean, some lurker here reviewed it, you consider yourself as a lurker, or peloverde is actually lurking and reviewing? [13:47] <nevcairiel> if you find a patch that directly hits the spot of some lurker, they might be motivated to review it at the very least, that includes peloverde and a bunch of others [13:47] <JEEB> yeah [13:48] <kurosu_> I personnally find this an inefficient use of several people (but who am I to judge?) - refactoring may be somewhat ok in the long term (difficult to judge) [13:48] <kurosu_> but that's never a valid reason to cause regressions in things that worked in the first place [13:48] <JEEB> if you're talking about stuff like TEP etc [13:48] <JEEB> that was rather useful methinks [13:49] <JEEB> same goes for some other API changes that come from libav [13:49] <nevcairiel> there is a difference between API refactoring and just style [13:49] <nevcairiel> some changes actually add useful functionality [13:49] <nevcairiel> some just reshuffle things because someone thinks it has to change [13:49] <kurosu_> I don't know what TEP is. What I meant is just that hypothertically K&R-only things have more drawbacks for me [13:50] <nevcairiel> TEP was the refactor of the AVFrame based APIs to support reference counting [13:50] <kurosu_> I can't recall everything - but there were (re)factoring and reducing the possibilities of bugs is ok to me [13:51] <kurosu_> yeah, this one may have caused a lot of regressions initially (I don't know) but I believe it is better in the long term [13:51] <nevcairiel> huge changes like that are rarely without a regression in this code base [13:51] <kurosu_> anyway, I'm neither a ffmpeg/libav developper nor user [13:53] <kierank> 12:49 PM <"nevcairiel> some just reshuffle things because someone thinks it has to change --> yeah like av_reverse [13:53] <kierank> completely pointless deprecation [13:56] <ubitux> wbs: you (not singular you) should really test the patches from koda before allowing him to push the commits [13:56] <ubitux> it's not the first time he's pushing stuff he hasn't even compiled [13:56] <ubitux> that happened with frei0r as well not long ago [13:57] <nevcairiel> which was broken? [13:57] <ubitux> https://lists.libav.org/pipermail/libav-devel/2014-April/058794.html [13:57] <nevcairiel> oh [13:58] <ubitux> ...and he's bragging review process on ffmpeg-devel after stuff like that [13:58] <nevcairiel> i'm ignoring that thread, its so full of BS [14:00] <Compn> nevcairiel : good idea [14:15] <wm4> nevcairiel: taking the easy way out, huh [14:16] <wm4> apropos, is this part of the topic still true: We need a volunteer Debian Package Maintainer. [14:16] <wm4> wasn't there progress on this? [14:18] <ubitux> wm4: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 [14:27] <BBB> wbs: have you noticed the c89-to-c99 bugs? are we interested in maintaining it or have we stopped caring now that msvc14 supports ffmpeg natively? [14:28] <BBB> wbs: I'm wondering what to do with the project [14:28] <BBB> and anyone else that cares [14:28] <nevcairiel> (its msvc12) [14:28] <wbs> BBB: I've seen them yes... it would of course be nice to fix the bugs, although I dunno how much work it is to fix them [14:29] <nevcairiel> didnt one of the reporters even post a patch to address his issues [14:29] <wbs> BBB: I've got a few usecases where I still can't upgrade to msvc13 myself so there's still some need for life support, but libav at least doesn't trigger any of the issues [14:30] <wbs> BBB: so basically, if easily fixable it would of course be nice, but other than that I wouldn't put too much effort into it [14:30] <BBB> wbs: right, same for ffmpeg... I guess the question thus becomes do we care about non-ffmpeg/libav code compiling? or is it "send a patch"? [14:30] <BBB> and yes one had a patch [14:31] <BBB> maybe should merge [14:31] <BBB> looked ok to me but I'm not the only person maintaining it - shall I just merge it anyway? [14:31] <BBB> oh work, bbl tonight [14:32] <wbs> BBB: I can have a look but unless I object sometimes soon, don't hesitate to merge it [14:41] <Daemon404> curious, whats the usecase? [14:45] <wbs> Daemon404: no idea, I guess you can ask in those posts [14:53] <Daemon404> true [15:09] <cone-285> ffmpeg.git 03Schenk, Michael 07master:b0a8521383e0: avformat/mov: reset drefs_count in close [15:09] <cone-285> ffmpeg.git 03Schenk, Michael 07master:845414bbb122: avformat/oggdec: reset nstreams in close [17:17] <wm4> getting an invalid free when seeking in some h264 files with ffplay: http://privatepaste.com/e733deecff [17:17] <wm4> looks pretty scary [17:19] <wm4> basically it's hard to check the sanity of the code because h264 uses AVFrame incorrectly [17:20] <ubitux> ah nice gmx.de is refusing mails now [17:20] <ubitux> gmx.* actually [17:20] <wm4> ubitux: kind of bad for a mail provider [17:21] <ubitux> :/ [17:21] <ubitux> wm4: regression i guess? [17:21] <wm4> the seek issue? maybe [17:21] <wm4> I only get a valgrind error, the original reporter had a crash [17:26] <wm4> the command for the issue is: ffplay -rtmp_live recorded -rtmp_pageurl "http://www.canalplus.fr/c-divertissement/pid1784-c-les-guignols.html?vid=104..." -rtmp_swfverify http://player.canalplus.fr/site/flash/player.swf rtmp://vod-fms.canalplus.fr/ondemand/videos/1404/nip_NIP_9077_1500k.mp4 [17:26] <wm4> and then do a seek once it's started [17:44] <wm4> updated to git HEAD, and I can't reproduce it anymore [17:44] <wm4> but it's probably still in 2.2 [17:45] <wm4> 8710ee11d75eeb could be a candidate [19:06] <cone-616> ffmpeg.git 03Carl Eugen Hoyos 07master:993a5afaada4: Read aspect ratio from tiff image files. [19:06] <cone-616> ffmpeg.git 03Carl Eugen Hoyos 07master:836b60ce2b49: Fix standalone compilation of vp7 and vp8 decoder. [20:54] <cone-616> ffmpeg.git 03Vittorio Giovara 07master:17a75a8c0902: libxvid: fix missing end of line character [20:54] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:0d225863f2c9: Merge remote-tracking branch 'qatar/master' [00:00] --- Tue Apr 8 2014