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

[burek]

[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=1046901" -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