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

[burek]

[00:18] <J_Darnley> Really?  I read that alignment was not nessecary for avx
[00:25] <J_Darnley> Oh wait.  That says "most".  How the heck do you which need alignment then?
[00:25] <jamrial> aligment is still necessary with avx and above for instructions that read 16 or 32 bytes
[00:26] <J_Darnley> Then Intel's own manual should state that!
[00:27] <J_Darnley> That is clear!
[00:27] <jamrial> usually, if it doesn't state somewhere that an instruction works with unaligned data, then it doesn't :P
[00:27] <J_Darnley> "Most VEX-encoded 128-bit and 256-bit AVX instructions (with both load and computational operation semantics) are not restricted to 16-byte or 32-byte memory alignment"
[00:27] <jamrial> i use this https://prd1idz.cps.intel.com/sites/default/files/managed/68/8b/319433-019.pdf
[00:32] <J_Darnley> I've been reading "Intel® 64 and IA-32 Architectures Software Developers Manual" volumes 1, 2a, 2b
[00:38] <J_Darnley> More rebasing then
[00:45] <J_Darnley> In that case I also shouldn't need a separate condition for avx.  The x86inc abstraction should do what I need.
[00:55] <jamrial> huh, seems that you were right after all. just tested the vex versions of some instructions and they can read unaligned memory
[00:55] <jamrial> wonder why i ran into crashes before
[00:55] <J_Darnley> the abstraction emulating with aligned loads?
[00:56] <jamrial> no, i tested on an avx enabled machine, x86util didn't do anything in that regard
[00:57] <J_Darnley> okay
[00:57] <jamrial> the xop code you wrote should be ok then. still, it would be better if you keep the order of instructions for the sse4 version intact
[01:06] <J_Darnley> Now how do I change my branch back to that old commit?
[01:07] <J_Darnley> Ah just an uppercase B in git checkout -B
[01:18] <ubitux> michaelni: so is this coccinelle this time? :)
[01:20] <wm4> looking at the first change of the first patch, I'm not sure if fclose(NULL) works (although it's implied it's called)
[01:20] <wm4> ubitux: have you ever used coccinelle?
[01:21] <ubitux> yes, one or two times
[01:21] <ubitux> for 1ec94b0f066f14153d86395980a31b7466de3d9d last time
[01:22] <wm4> how is it? was it hard to get started/to get it work=
[01:22] <ubitux> interesting, not mature
[01:22] <ubitux> i retested a few hours ago actually
[01:22] <ubitux> it took 40 sec to process ffmpeg.c (4k LoC)
[01:23] <ubitux> so i gave up on looking any further
[01:23] <ubitux> the documentation seems to still sucks hard 
[01:24] <wm4> :(
[01:24] <michaelni> ubitux, yes
[01:25] <wm4> also, 0 is a valid null pointer constant
[01:25] <michaelni> sure
[01:26] <michaelni> question is should the patch be applied or not
[01:26] <wm4> probably should
[01:28] <J_Darnley> is fclose(0 or NULL) really safe?
[01:29] <wm4> J_Darnley: I'm pretty sure it's not
[01:42] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:65f05eff0a5d: avfilter/lavfutils/ff_load_image: Return error if no frame could be decoded
[01:46] <J_Darnley> Reaching EOF without closing an if statement.  Surely that must be some syntax error, yasm?
[02:11] <Timothy__Gu> Did anyone watch the CodeJam final?
[02:15] <Timothy__Gu> michaelni: how did you find a need for commits like http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=9c712d0b1608ec998dbe41d81a79f3fb7ea32b4d ?
[02:16] <Timothy__Gu> Do you use some kind of static analyzer or did you encounter a clip that causes memleak?
[02:16] <Timothy__Gu> Oh never mind
[02:17] <Timothy__Gu> It's just a fix-up of the parent commit
[02:20] <michaelni> Timothy__Gu, yes, i just spoted then when reviewing the patch
[02:20] <Timothy__Gu> Alright
[02:23] <Timothy__Gu> Huh? I'm already op how can I be +v again?
[02:25] <BBB> Timothy__Gu: theyre different flags
[02:26] <BBB> its like being u+rwx and getting g+rwx for a file with group rbultje user rbultje on my laptop
[02:27] <BBB> not very useful, but strictly speaking theyre different flags so semantically it makes sense
[02:27] <Compnn> run as root anyways.
[02:27] <Compnn> screw permissions
[02:27] <BBB> am I the only one whos getting mildly frustrated with all the kind advice on how to run a project from our dearest friends in debian
[02:28] <BBB> youshoulddothis and youshoulddothat
[02:28] <BBB> I wish they didnt do that
[02:28] <wm4> they don't really have an idea what the problem is
[02:29] <Compnn> its mostly 'you should get back together and be friends' or some iteration thereof
[02:29] <Compnn> feels like 2011 all over again
[02:29] <wm4> so did debian decide yet whether they want ffmpeg or libav
[02:29] <Compnn> rather avoid bikesheds like this
[02:39] <jamrial> wm4: users want ffmpeg. debian security team doesn't really care but would rather stick with libav since it's already there and tested
[02:39] <jamrial> that's more or less what i could gather from this thread and earlier discussions
[03:03] <Plorkyeran> re fclose(0): The fclose() function does not handle NULL arguments; they will result in a segmentation violation.
[03:03] <Plorkyeran> also I'm always amused by the os x man pages saying things are FreeBSD implementation details (such as that)
[03:57] <Compn> j-b : like i said, i dont think ffmpeg and libav will be reuniting
[03:57] <Compn> i'm not really interested in libav's developer rules either
[12:12] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:82e0cb360aaa: avformat/thp: dont mix integers with pointers
[12:33] <cone-714> ffmpeg.git 03Reimar Döffinger 07master:c2829dc925ff: dict.c: Add av_dict_set_int helper function.
[12:33] <cone-714> ffmpeg.git 03Reimar Döffinger 07master:a0941c8a2b3e: Use new av_dict_set_int helper function.
[12:52] <cone-714> ffmpeg.git 03Reimar Döffinger 07master:bddc592001bd: dict.c: empty dictionaries should be a NULL pointer.
[13:53] <Compn> michaelni : i dont think your mail was insulting :(
[13:54] <Compn> sigh
[13:54] <Compn> j-b : you name caller you!
[13:54] <Compn> like 4th grade all over again
[13:55] <wm4> hue
[13:56] <wm4> that reminds me, didn't michaelni agree to step down if there's another non-evil person who wants to be maintainer?
[13:56] <wm4> so, volunteers, take a step forward
[13:56] Action: wm4 takes a step backwards
[14:00] Action: ubitux wonders what's this overreacting mail all about again
[14:21] <wm4> so who here is against Libav commit rules
[14:21] <wm4> reminder: it means that each patch must be reviewed by 2 maintainers (or something) before it can be pushed
[14:22] <J_Darnley> I don't really know and I'm not sure I care?
[14:22] <nevcairiel> if its really 2, its not like they really follow it, usually one vague "probably OK" is all it needs
[14:23] <michaelni> wm4, yes iam happy to resign if this resolves the situation
[14:28] <nevcairiel> hm, reimar pushed from the future, all his commits are at least stamped 20 minutes from now
[14:28] <ubitux> wm4: i'm against
[14:28] <michaelni> can someone review a few patches btw, there are a few on the list that need reviews
[14:28] <wm4> time traveling has its perks
[14:29] <wm4> ubitux: why and what would you want changed
[14:29] <michaelni> from v4l2, over fic to a few really trivial ones from me
[14:30] <ubitux> wm4: i want to be able to push trivial stuff like ee7ee9b the minute i see them without generating ml noise, and i also want to be able to work on code i maintain freely as long as it's not affecting some other people code
[14:32] <ubitux> wm4: also, i want to be able to push after 3 days if i see no comment on patches i submit
[14:32] <ubitux> i make a personal exception for myself concerning api changes, but i don't think it should be applied to anyone
[14:32] <ubitux> basically... i like how it currently is in ffmpeg
[14:33] <ubitux> (by exception i mean i won't push after 3 days if i see no review, because i'm not comfortable doing this, and i'm fine if other ppl prefer to push in such situation)
[14:34] <ubitux> i think that way of handling the project has proven to be effective so far
[14:36] <ubitux> (this also means that developers who care should register to -cvslog, or follow the git log)
[14:37] <kurosu> is there an lav utility function converting a known-length, non-null-terminated buffer into a string, in particular for metadata ?
[14:37] <wm4> and you don't think temporarily losing these rules would be worth for merging the two projects?
[14:37] <wm4> kurosu: av_strndup
[14:38] <wm4> for metadata, an av_dict_snprintf() would have been useful
[14:38] <ubitux> wm4: not so sure, because i don't think i'm the only one to share a similar opinion on the matter
[14:39] <ubitux> wm4: if i need to send a patch for ee7ee9b, i won't do it
[14:39] <ubitux> wm4: if i can't push something on my code because no one care about giving a meaningful or meaningless review, it will drives me away from the project
[14:40] <wm4> also the commit message of that commit has a typo
[14:40] <wm4> not the best way to demonstrate your point
[14:40] <ubitux> wm4: also, i saw the level of review slightly decrease on libav side especially because review became a core
[14:40] <wm4> chore?
[14:40] <ubitux> yes, +h sorry
[14:40] <ubitux> wm4: the "vissible" typo is what i fix
[14:40] <wm4> oh, I see, the typo in the commit message is intentional
[14:41] <wm4> but really, what patches that don't need review are there, aside from typos
[14:41] <ubitux> anyway, i believe the strict rules from libav are an hindrance to the progress of the project
[14:41] <wm4> which could actually be not typos...
[14:42] <ubitux> small spaces shuffles
[14:42] <ubitux> or small indent fixup or whatever
[14:42] <ubitux> wm4: this one for instance: 7ac7e879
[14:45] <ubitux> the 3-days timeout is very important too
[14:45] <ubitux> basically, it doesn't force people to do meaningless review on stuff they don't know
[14:45] <ubitux> we can't make a distinction between meaningful and meaningless reviews on libav because they are all force to do them
[14:47] <ubitux> so when someone who works only on formats and protocol says OK to an ASM change in libavcodec, there is no way to know if it's just been reviewed on the way the code looks or if he has expertize in the matter
[14:47] <ubitux> this happens less in ffmpeg, because people don't feel the need to review stuff they don't know
[14:48] <wm4> well, I don't know, I like that each change has to be looked at by someone else, even if that someone else is not necessarily an expert
[14:48] <ubitux> this is what -cvslog is for
[14:49] <ubitux> i don't read all the patches that go on the ml, but i actually do read cvslog as a matter of curiosity on areas i don't know
[14:50] <wm4> getting a commit reverted is much harder than just nacking a patch
[14:50] <ubitux> that way, i don't need to irresponsably review stuff i don't know nor prevent its inclusion
[14:50] <J_Darnley> michaelni: okay, I'll start by looking at your trivial NULL check patches
[14:51] <michaelni> if a commit is crap it should be reverted, it shouldnt be hard.
[14:51] <ubitux> wm4: probably yes, but i think it's less important than the drawbacks i listed, especially if the people of the project are relatively wise
[14:51] <michaelni> J_Darnley, thx
[14:52] <ubitux> wm4: you might arguee we're all stupid kids though ;)
[14:52] <ubitux> wm4: the only place where i see this problematic is when a maintainer pushes stuff in a gray area where some other people would disagree
[14:53] <ubitux> typically if Carl pushes stuff on the lib detections in configure ;)
[14:53] <ubitux> but honestly, it's of relative importance
[14:54] <ubitux> i aknowledge the current disagreements and problems, i just think they are way less a problem than the hindrance of forced review
[14:54] <ubitux> wm4: should we review all the merges from michael? :)
[14:54] <ubitux> if we do, we do it on cvslog
[14:55] <wm4> no, but all commits from michael
[14:56] <ubitux> i believe michael learned when to send patches (api changes, another maintainer area), and when not to (mainly non sensible fixes)
[14:56] <ubitux> i like how it is currently
[15:00] <iive> ubitux: were you around here during the time of the take-over?
[15:01] <ubitux> i arrived in the project around that time
[15:01] <ubitux> i read the threads daily, but didn't participate
[15:01] <wm4> at the time I was just watching from the outside
[15:01] <wm4> but I agreed with the fork
[15:02] <wm4> it was just later that the fork business turned out as disaster
[15:02] <nevcairiel> it turned out a disaster because they didnt fork, they tried to do a hostile takeover
[15:03] <wm4> which turned into a fork after it didn't work
[15:03] <wm4> (lol)
[15:03] <nevcairiel> but thats the reason its a disaster
[15:03] <wm4> yeah
[15:03] <ubitux> i'd suggest to get over it for now and instead focus on the current state & methods of each project
[15:03] <wm4> I see subtle differences in the review process
[15:03] <ubitux> IMO these 3 years have shown the limits of forced reviews
[15:03] <iive> well, imho, it turned out a disaster, because the new rules were not enforced honestly
[15:03] <wm4> which emerged _after_ the fork
[15:04] <ubitux> OTOH i think the ffmpeg project became wiser, even though the rules haven't changed much
[15:04] <iive> developers who didn't support the take-over were pushed away, patches delayed and not reviewed.
[15:04] <nevcairiel> to me it seems the other side seems to not even be open to discuss any changes, their way or the high way, etc
[15:05] <iive> the new FFmpeg methodology to a bigger extent completely avoid the possibility of this happening here.
[15:05] <iive> libav rules were created with intent of manipulating them.
[15:05] <ubitux> i think it's more important to have a discussion when a problem occurs than forcing strict rules
[15:06] <iive> absolutely
[15:06] <ubitux> michael didn't change his way on working on ffmpeg because we setup new rules
[15:06] <BBB> <ubitux> so when someone who works only on formats and protocol says OK to an ASM change in libavcodec, there is no way to know if it's just been reviewed on the way the code looks or if he has expertize in the matter
[15:06] <BBB> that ^^
[15:06] <wm4> nevcairiel: actually nobody seems to be ready to accept change
[15:06] <BBB> that is exactly my problem with peer review
[15:07] <iive> rules are just mementos of past mistakes, with the purpose to avoid them in the future.
[15:07] <BBB> (at least the way opensource people do it)
[15:07] <ubitux> wm4: i think ffmpeg is open to changes, but it has to be justified and proven effective
[15:07] <ubitux> forced review wasn't IMO
[15:08] <ubitux> if i'm the only one to think that, then be it, i'll leave this to people in charge
[15:08] <ubitux> but i don't think that's the case
[15:09] <ubitux> wm4: it's an intereting discussion, i think you could share that backlog with libav devels if they're willing to remove their blinkers for a moment
[15:09] <wm4> well the log is public
[15:10] <saste> ubitux, +1, no-review for trivial patches, no need for reviews for patches under maintainer's area, API and controversial patches sent for review to the ML as exception
[15:10] <ubitux> yes, it's basically common-sense vs strict rules
[15:10] <ubitux> you have strict rules with people you can't trust
[15:10] <BBB> you havent discussed patch blocking yet
[15:10] <iive> +1
[15:10] <saste> in general the maintainer is empowered and trusted, this limits the review chore and avoids fake-reviewing
[15:10] <BBB> if you wnt to share this with libav anyway
[15:11] <BBB> the way baptiste used to block patches was beyond disgusting
[15:11] <BBB> libav does the same nowadays
[15:11] <wm4> blocking by not replying in any way?
[15:11] <BBB> oh, your whitespace isnt up to gods standards, let me block your patch
[15:11] <wm4> ooh.
[15:11] <BBB> and other stuff complete irrelevant to the functionality of the patch
[15:12] <ubitux> do we have such problems currently?
[15:12] <wm4> so there's a bit too much micromanagement about things that don't matter
[15:12] <wm4> (hurrr cosmetics)
[15:12] <BBB> patch review should be deep and meaningful, such a to help the quality of the project, not show off the incompetence of the reviewer or non-bugs by the developer
[15:12] <BBB> ubitux: we dont; we did, though
[15:12] <BBB> baptiste was a terrible example of this
[15:12] <BBB> he was truly horrible
[15:12] <ubitux> i'm not sure i have an answer to patch blocking, but i don't think a general rule can do something about it
[15:13] <BBB> its a concept we have to be aware of and prevent it from occurring again
[15:13] <ubitux> i guess it all goes down a human issue
[15:13] <ubitux> +to
[15:13] <ubitux> also, having a "dictator" helps in that matter, as it acts as a mediator
[15:14] <ubitux> assuming he's wise enough, and technically up to
[15:14] <wm4> ubitux: michaelni is a terrible mediator though
[15:14] <iive> i don't agree
[15:14] <ubitux> i'm not so sure about that
[15:14] <iive> he is entirely focused on the code side, not on the human side.
[15:15] <wm4> and utterly incompetent in social issues
[15:15] <ubitux> you can't put someone too emotionnally sensible as a mediator
[15:16] <iive> well, diego is excellent as social mediator.
[15:17] <ubitux> that's the kind of mediator i would be extremely afraid to have
[15:18] <iive> that's my point.
[15:29] <ubitux> wm4: how does it work in mpv btw? do you get review for all your patches?
[15:30] <wm4> ubitux: no, there are not enough developers for that, I just push whatever I feel like pushing (it's great)
[15:31] <wm4> other developers which "own" a subsystem are free to push too, though
[15:31] <wm4> but it's a very very tiny project, but a ffmpeg
[15:31] <wm4> *not
[15:32] <ubitux> yes, there are a lot of differences
[15:32] <ubitux> note thought that pushing directly to ffmpeg is backed up by several things
[15:32] <ubitux> such as tests, in addition to people following cvs-log
[15:33] <Compn> wm4 : me, i like committing directly :P
[15:33] <Compn> but i'm not a big devel...
[15:34] <ubitux> Compn: actually, i wouldn't mind if *you* could send some patches instead sometimes ;)
[15:34] <Compn> ;P
[15:36] <Compn> i think we should try examples
[15:37] <Compn> there are going to be differences of opinions on patches
[15:37] <Compn> who decides which party is correct ? when one devel says its ok, and one rejects it ?
[15:37] <ubitux> discussion
[15:37] <saste> Compn, in practice it worked fine most of the times
[15:37] <ubitux> and if it leads to nowhere, mediator
[15:38] <Compn> hey saste :)
[15:38] <saste> we have to manage a (relatively) small project, not a country
[15:38] <Compn> i remember commit war
[15:38] <Compn> but ok , it did work for the most part
[15:38] <saste> I don't remember serious flames after the fork
[15:39] <Compn> right, i mean if we get back together
[15:39] <ubitux> it should be progressively
[15:39] <Compn> the ml is currently very calm :)
[15:39] <ubitux> otherwise it won't work
[15:39] <saste> basically the internal tensions were resolved when the disagreeing contributors left the project
[15:39] <Compn> right
[15:40] <Compn> saste : j-b wants us to get back together and be friends
[15:40] <ubitux> yes, naruto want that too
[15:40] <ubitux> +s
[15:40] <saste> Compn, uhm, start convincing libav to join
[15:40] <iive> yes, it would save a lot of code merging 
[15:41] <saste> i'm for merging back too, but i'm not too positive about the fact that it can be done in practice
[15:41] <saste> starting from choosing the new repository
[15:41] <ubitux> easy, the one that has both ffmpeg and libav changes ;)
[15:42] <saste> also, i've been told many times from libav developers that they are happy the way we are
[15:42] <saste> and ffmpeg developers seem also to be mostly happy about the current situation
[15:42] <saste> so the main problems are for users
[15:42] <iive> actually
[15:43] <iive> it would help if ffmpeg and libav developers talk more about how to solve problems
[15:43] <iive> even if at the end there is no agreement, there is still a chance for having technical discussion
[15:44] <ubitux> yes, maybe they should join here
[15:44] <ubitux> like some of us do on their channel
[15:44] <ubitux> it may help communicating a bit
[15:45] <ubitux> we're not really welcome there though
[15:59] <kierank> Compn: it's not going to happen all of a sudden
[15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:2d7cec14beb5: avcodec/dvdsubdec: Dont mix integers with pointers
[15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:0014541e9a23: avcodec/dvbsubdec: dont mix integers with pointers
[15:59] <kierank> there will be a shared mailing list of some sort
[15:59] <kierank> and then it'll go from there imo
[15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:7916053cedb4: avformat/udp: dont mix integers with pointers
[15:59] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:74c81106d231: avformat/udp: remove unneeded variable initialization
[16:00] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:97bb456b6b78: avcodec/hevc_mvs: dont redundantly initialize ref_idx_curr
[16:00] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:e7f3b507a343: avcodec/mips/compute_antialias_float: remove unused variable
[16:00] <kierank> http://www.slate.com/features/2014/07/middle_east/graphics/graphical_version.png
[16:14] <funman> flfimbpaevg
[16:18] <wm4> kierank: should make such a chart for ffmpeg/libav
[16:27] <kierank> wm4: yeah
[16:27] <ubitux> lol durandal_1707 
[16:27] <ubitux> (re: missing signed-off)
[16:30] <durandal_1707> why is VDD so far away?
[16:39] <wm4> "Social people not having any empathy for non-social ones really is a joke."
[16:39] <wm4> heh
[16:58] <saste> yeah i'm tired by that attitude
[16:58] <saste> also if they feel the need to communicate with michaelni maybe they can remove the ban on the ML/IRC
[16:58] <saste> that would be a start
[16:59] <saste> the rest is hypocrisy
[16:59] <ubitux> they don't want to, because michael is stealing open source code
[17:00] <kierank> it's the other way round
[17:00] <kierank> michael complains he can't communicate with libav
[17:01] <ubitux> why would they impose the worst possible medium for such thing?
[17:01] <saste> kierank, and the usual reply from libav is, only RL matters
[17:01] <kierank> ubitux: irc and emails have made so much progress you know
[17:01] <kierank> look at where we are now compared to 2011...
[17:01] <saste> that is they only admit the only mean that michaelni will surely avoid
[17:02] <saste> kierank, where are we now? 
[17:02] <kierank> nowhere
[17:02] <kierank> we have moved a total of 0m
[17:02] <kierank> from 2011
[17:02] <saste> i'd say at the same point, but at least there are no internal flames
[17:02] <saste> we have no major internal management issues in ffmpeg, that's at least something
[17:03] <kierank> true
[17:03] <saste> we lack on PR and on organization, that was never a strong point of ffmpeg
[17:03] <saste> much less after the fork
[17:03] <ubitux> we lack manpower, and distribution :)
[17:03] <kierank> raising money for OPW because libav did OPW is totally unnecessary
[17:04] <kierank> it's pure jealousy
[17:04] <ubitux> it's part of being a superset on all levels
[17:04] <kierank> lol
[17:04] <saste> kierank, that's a legitimate standing, but it's your personal position
[17:04] <nevcairiel> Didn't they just leverage the money out of the opw organization somehow
[17:05] <kierank> I don't have an objection with OPW itself
[17:05] <kierank> I have an objection with ffmpeg doing from what appears to be just because libav did it
[17:05] <saste> i dislike OPW because i consider it discriminatory on a sexual basis, but others consider that an opportunity to gain new contributors
[17:06] <ubitux> kierank: i see no difference with patch picking/merging
[17:06] <ubitux> it's all about competition
[17:06] <ubitux> "jealousy" is your interpretation
[17:06] <saste> ubitux, competition sucks
[17:06] <ubitux> maybe
[17:07] <saste> but it is culturally hardwired in us, so deal with it
[17:07] <saste> cooperation is much better, but we can't manage that
[17:07] <saste> so let's just kill each other, it's easier
[17:07] <ubitux> :))
[17:08] <ubitux> cooperation between two projects with the same codebase will lead to a merge, that's probably what some people want to avoid
[17:09] <ubitux> i think all we can do is just keep honoring all their changes, and welcome those who want to contribute
[17:26] <kierank> ubitux: I can't tell if you are serious or not about opw
[17:34] <iive> imho, the opw from ffmpeg was a mistake
[17:35] <iive> ffmpeg didn't had the cash, so it would likely fail. there is already somebody working on it in libav.
[17:37] <durandal_1707> are you referring to K&R and splitting?
[17:46] <saste> iive, we had a few chat meetings with OPW admin (me, michaelni, and reynaldo)
[17:46] <saste> the bottom line is that if we don't gather enough money, we'll join the next round
[17:47] <saste> so time is not a problem, also we just need to find one or two commercial sponsors to get the required money
[17:47] <saste> that's not unreasonable
[17:49] <iive> it would look quite pity if we can't collect the money.
[17:51] <iive> and that's quite a lot of money for such bare-bone project as ffmpeg.
[17:52] <iive> btw, do we still have people in FFmtech board and does somebody know what is going on there?
[17:53] <durandal_1707> avscale?
[17:53] <Compn> iive: reimar was there, dunno about now
[17:57] Action: durandal_1707 wonders when mxf signed-off patch will appear
[18:26] <Compn> so
[18:26] <Compn> whos working to merge mythtv back to ffmpeg ?
[18:26] <Compn> :)
[18:26] <Compn> the mythtv devs gave up on it years ago
[18:26] <Compn> so someone of us is going to have to take over.
[18:27] <Compn> i guess a first start would be cutting patches out and submitting them to the list for review
[18:27] <Compn> verifying they compile and pass fate
[18:27] <Compn> any volunteers ? :)
[18:29] <Daemon404> wouldnt all their patches be ancient
[18:29] <Daemon404> or just useless hacks
[18:31] <Compn> Daemon404 : wm4 did a diff of ffmpeg , http://sprunge.us/gTcY
[18:32] <kierank> mostly just niche ts features
[18:32] <kierank> the reason they didn't get merged is because ffmpegcli wouldn't know how to deal with the ts data formats for interactive tv etc
[18:33] <Compn> ffmpegcli isnt the only user of libavcodec/libavformat
[18:33] <kierank> of course
[18:34] <kierank> but then people want FATE tests which inherently require ffmpegcli
[18:34] <wm4> yeah, too much focus on ffmpeg.c :(
[18:34] <Compn> i dont think fate tests are a blocker for closed caption support
[18:34] <Daemon404> +libavcodec/dvbsub_parser.c      // Fix for #5978
[18:34] <Daemon404> i wonder about this sort of stuff
[18:34] <Daemon404> why not just send that upstream
[18:35] <Compn> Daemon404 : because the old development rejected it. now we're ready to accept things. maybe.
[18:35] <Compn> more accepting of things.
[18:35] <Daemon404> tsundere ffmpeg
[18:39] <Compn> and ffmpegcli intergration with new features is also not a blocker. especially when those features (interactive tv / teletext) can be used by other projects like vlc
[18:39] <Compn> at least in my opinion, which means little :)
[18:40] <Compn> kierank : i'm curious why you think everything is a blocking issue? where in the ffmpeg developer rules is that written ? :P
[18:40] <Daemon404> ffmpeg/c integration should not be a blocker, no.
[18:40] <kierank> Compn: i didn't say it was a blocking issue
[18:40] <kierank> but every patch i send it seems someone wants a fate test
[18:40] <Compn> its a request for a fate test.
[18:41] <Compn> request, not blocker
[18:41] <Compn> we do like to have samples of course and be able to test patches.
[18:42] <Compn> by 'we' i mean those people who do the testing :)
[18:42] <Compn> not me personally
[18:43] <Compn> sometimes people send patches for bug fixes but dont give samples. that maybe a blocker, since all files that touch that code have to be tested to make sure the fix didnt break anything
[18:43] <Compn> or maybe i am wrong.
[18:44] <Compn> i cant speak for others.
[18:44] <Compn> Daemon404 : do you notice how nicely commented the mythtv code is? :)
[18:45] <nevcairiel> "// hack starts here" is not nicely commented. :P
[18:45] <Daemon404> ffdshow styf
[18:45] <Daemon404> style
[18:45] <Compn> bah
[18:45] <Compn> * HACK!  To allow BBC IPTV streams with incomplete PMTs (they
[18:45] <Compn> +                 * advertise a length of 383, but only send 182 bytes!), we
[18:45] <Compn> +                 * will not wait for the remainder of the PMT, but accept just
[18:45] <Compn> +                 * what is in the first TS payload, as this is enough to get
[18:45] <Compn> +                 * playback, although some PIDs may be filtered out as a result
[18:46] <nevcairiel> I have a whole load of special hacks in my "fork", but I just use git to keep track and comments
[18:46] <nevcairiel> Also, pastebin
[18:47] <Compn> thats what i'd like to do is reduce the amount of diffs from the various forks
[18:47] <Compn> at least where its easy to agree with the changes
[18:47] <nevcairiel> I should go through my patches again some day and send a few
[18:47] <Compn> we wont bite.
[18:49] <nevcairiel> I should really squash all the patches for my custom mkv demuxer, it would make the history so much shorter
[18:49] <nevcairiel> Oh well
[19:21] <cone-861> ffmpeg.git 03Ben Hagen 07master:6928ea7eb0fb: cinedec: add shutter and crop metadata
[20:07] <cone-861> ffmpeg.git 03Marton Balint 07master:51748b6377ff: mpegts: always parse pcr
[20:07] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:3574d34aca9d: Merge remote-tracking branch 'cus/stable'
[20:18] <michaelni> anyone has any comments on: " Mohammad Alsale (8.0K) [FFmpeg-devel] [PATCH] avformat/metadata: Implement AVFMT_FLAG_NO_META_CONV"  ?
[20:19] <michaelni> if not ill apply it
[20:21] <wm4> hm I'm neither against not for it, but maybe it would be better to keep the original metadata around in a separate dict?
[20:29] <michaelni> wm4, iam fine with either, if you think it should be in a seperate dict, reply to that patch and request that
[20:31] <wm4> replied
[20:49] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:b7d5e016a3f3: swresample: Add AVFrame based API
[22:16] <ubitux> lol @ debian thread where lintian is pointed out to solve "human problems"
[22:17] <ubitux> there is a slight misunderstanding here it seems :))
[22:26] <ePirat> Seems that Google is a ffmpeg fan :P http://i.imgur.com/Yanqua0.png
[22:28] <kierank> ePirat: why is google using mpeg-ts?
[22:28] <ePirat> kierank, for HLS, they use hls for live streams
[22:29] <kierank> ah
[22:29] <ubitux> why 48k for streaming btw?
[22:29] <kierank> because that's what they get the content in
[22:29] <ubitux> so just to get free of a resample?
[22:29] <kierank> why would they want to resample
[22:30] <kierank> 44.1khz is annoying#
[22:30] <ubitux> i guess the bw gain between 48k and 44.1 is more than negligible
[22:30] <ubitux> kierank: annoying in what sense?
[22:30] <kierank> ubitux: difficult to fit within a multiple up 29.97
[22:30] <kierank> in fact very complex
[22:31] <kierank> of*
[22:32] <ePirat> actually there was a huge rant on twitter, because the stream was lagging all the time& seems the provider of the original stream fucked something up :P
[22:32] <ePirat> lagging as in video stops, audio continues
[23:27] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:427bcdf035f5: avformat/mpegts: Use differential score for analyze()
[00:00] --- Sun Aug 17 2014