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

[burek]

[00:35:50 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:d736b52a045c: swscale: Drop is9_OR_10BPS() use, its name is not correct
[00:35:51 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:a340cfef8259: swscale/input: Fix alpha bswap for set readAlpPlanar
[00:35:52 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:873d06c76ea5: swscale/output: Fix alpha shift in yuv2gbrp_full_X_c()
[00:35:53 CET] <cone-299> ffmpeg 03Luca Barbato 07master:2c7d8cbd666d: swscale: Add the GBRAP12 output
[00:35:54 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:b828788d58cb: swscale: Add GBRAP10 output
[01:51:14 CET] <root___10> ls
[02:16:35 CET] <cone-299> ffmpeg 03Luca Barbato 07master:638b216d4f54: pixfmt: Add GRAY12
[02:16:36 CET] <cone-299> ffmpeg 03Luca Barbato 07master:19be5fb7286b: swscale: Add GRAY12
[02:16:37 CET] <cone-299> ffmpeg 03Michael Niedermayer 07master:2bc66d9e4320: nut: add gray12 support
[03:34:39 CET] <cone-299> ffmpeg 03Steven Liu 07master:863ebe6f83de: avformat/flvenc: add add_keyframe_index option
[04:14:21 CET] <atomnuker> a whole 6% performance increase just by moving opus dequantization to a separate file
[04:23:37 CET] <rcombs> wat
[04:23:41 CET] <rcombs> how even
[04:24:13 CET] <rcombs> preventing poor inlining decisions that made functions too big for cache?
[04:26:58 CET] <Compn> or he put the stop/start timer in the wrong place :P
[04:27:04 CET] <Compn> or magic i guess
[08:12:54 CET] <cone-065> ffmpeg 03Carl Eugen Hoyos 07master:edb8af6e9247: lavc/hevc_ps: Use correct pix_fmt for 12bit 4:0:0.
[08:24:08 CET] <cone-065> ffmpeg 03Carl Eugen Hoyos 07master:08be65a07557: lavc/hevc_ps: Fix an error message.
[10:15:15 CET] <ubitux> covers extraction from mov doesn't seem to work anymore with ffmpeg cli (since mov edit list i suppose?)
[10:16:38 CET] <ubitux> oh wait it's a more nasty thing
[10:25:15 CET] <ubitux> i guess i'll mail him
[10:32:44 CET] <ubitux> so basically there is an edit list on a h264 video stream of 1 frame, with 1 entry: media_time=0 duration=0
[10:33:12 CET] <ubitux> and so ffmpeg drops it (unless ignore_editlist is disabled)
[10:34:44 CET] <wm4> lol has the editlist stuff still not been reverted
[11:20:09 CET] <wm4> is copying a GetBitContext via assignment allowed? (I want to do that to read ahead without changing the position in an existing GetBitContext)
[11:20:16 CET] <wm4> from the source code it looks like that should be ok
[11:22:17 CET] <nevcairiel> i think thats used in various places for exactly that
[11:51:30 CET] <wm4> should av_reduce(&num, &den, 1, 14112000, 1000000) really return num=0, den=1
[11:57:12 CET] <nevcairiel> not sure how strict it sees the max, there is no way it can express anything useful that would obey it
[11:57:42 CET] <nevcairiel> if its a hard limit, invalid is the only reasonable reply
[11:58:31 CET] <wm4> maybe so, but INT_MAX isn't a too reasonable parameter either
[11:58:42 CET] <wm4> imagine you have a timebase that's close to one second, with a very minor deviation - then both num and den could be very high
[11:58:54 CET] <wm4> and then multiplying the timebase with a small integer could overflow
[11:58:56 CET] <nevcairiel> well if both are very high, it can reduce them
[11:59:15 CET] <nevcairiel> by losing accuracy if need be
[11:59:34 CET] <wm4> can it lose accuracy? if so, it could return 1/1000000 in the example above
[11:59:56 CET] <nevcairiel> thats probably too much of a loss  for it
[12:00:40 CET] <nevcairiel> usually it would just round the fractions, so something like 11/50 can turn into 1/5 etc
[12:00:41 CET] <jkqxz> It returns the nearest fraction with num and den not exceeding the max.  In that case, zero is correct.
[12:01:10 CET] <jkqxz> (But not necessarily what you wanted.)
[12:01:46 CET] <nevcairiel> also for applying timebases to times, we have overflow safe functions for that
[12:04:08 CET] <jkqxz> Yeah, all of the rescale functions are written to get the best representable approximation to the answer in the cases where it overflows.
[12:16:47 CET] <atomnuker> wm4: yep, you can do whatever you want to getbitscontetxt or the buffer it writes to
[12:28:56 CET] <wm4> back to edit lists, on the ML I see a post: "I've seen a lot (hundreds/thousands) of files broken like this so far."
[13:36:06 CET] <kierank> is it possible to do
[13:36:10 CET] <kierank> xor    ebx,DWORD PTR [rsp+dx*4+0x6e20]
[13:36:12 CET] <kierank> instead of 
[13:36:12 CET] <kierank> xor    ebx,DWORD PTR [rsp+rdx*4+0x6e20]
[14:44:49 CET] <Gramner> kierank: nope, you can't mix register sizes
[15:20:17 CET] <kierank> Gramner: the compiler is doing
[15:20:17 CET] <kierank> xor    ebp,DWORD PTR [rsp+rax*4+0x4e20]
[15:20:17 CET] <kierank> movzx  eax,WORD PTR [rsi-0x16]
[15:20:17 CET] <kierank> xor    ebp,DWORD PTR [rsp+rax*4+0x5e20]
[15:20:17 CET] <kierank> movzx  eax,WORD PTR [rsi-0x1a]
[15:20:35 CET] <kierank> but I would like to do a single larger load and instead just shift to get the right index to the table
[15:29:52 CET] <wm4> what exactly happens if you read past a GetBitContext?
[15:31:02 CET] <atomnuker> depends if you have --disable-safe-bitstream-reader enabled or disabled
[15:31:22 CET] <wm4> is that a configure option
[15:31:47 CET] <atomnuker> yep, by default its on (so the safe bitstream reader is enabled)
[15:32:26 CET] <wm4> insane as usual... I thought a define (UNCHECKED_BITSTREAM_READER) controlled this
[15:32:35 CET] <wm4> anyway, I'm pretty sure this uses the safe reader
[15:32:43 CET] <atomnuker> yes, the configure option maps to that define
[15:33:12 CET] <atomnuker> but anyway, it'll clip any reads past the end byte to the end byte
[15:33:38 CET] <wm4> so what do the read functions return? 0?
[15:34:07 CET] <iive> i thought that the bitstream is supposed to be padded with extra bytes.
[15:34:44 CET] <cone-065> ffmpeg 03Tom Butterworth 07master:bd6fa80d56fc: avcodec/hap: add "compressor" option to Hap encoder to disable secondary compression
[15:35:43 CET] <atomnuker> wm4: the read functions return the bits you attempted to read, the only way to check if you've went past the end is to call get_bits_count and compare it
[15:37:15 CET] <BBB> wm4: the unchecked reader can be enabled globally (for speed) or per-decoder (if its known-safe)
[15:37:37 CET] <BBB> wm4: e.g. wmavoice uses it (theres really no reason for this, it was just for fun and I did indeed confirm it had no overreads)
[15:37:46 CET] <BBB> I believe mpeg also uses it, maybe cavlc/h264 also
[15:37:51 CET] <wm4> yeah
[17:51:26 CET] <cone-065> ffmpeg 03Sasi Inguva 07master:c8dc11bb9ef9: lavf/mov.c: Fallback to finding non-keyframe in fix_index, if keyframe search fails.
[17:51:27 CET] <cone-065> ffmpeg 03Sasi Inguva 07master:18108f361838: lavc/utils.c: Make sure skip_samples never goes negative.
[21:03:36 CET] <cone-065> ffmpeg 03Andreas Cadhalpun 07master:1e33035ee7a8: proresdec_lgpl: explicitly check coff[3] against slice_data_size
[21:03:37 CET] <cone-065> ffmpeg 03Andreas Cadhalpun 07master:c82b8ef0e4f2: dvbsubdec: fix division by zero in compute_default_clut
[21:34:21 CET] <kierank> atomnuker: LOL
[21:34:40 CET] <atomnuker> wut?
[21:34:53 CET] <JEEB> let me guess, you guys were doing that raw video stuff 8)
[21:34:57 CET] <kierank> you wrote basically a carbon copy of what I did 
[21:35:16 CET] <JEEB> oh, you replied
[21:35:39 CET] <atomnuker> damn, you were 8 minutes quicker :)
[21:37:20 CET] <kierank> they will get nowhere trying to do it with ffmpeg rtp
[21:37:31 CET] <kierank> because iirc ffmpeg rtp is in the main thread
[21:37:48 CET] <JEEB> I didn't remember it was like that, but I totally wouldn't be surprised
[21:38:02 CET] <kierank> there's a special thread in raw udp
[21:38:03 CET] <funman> how can rtp be slow, it has real time right in the name
[21:39:12 CET] <atomnuker> the same way "people's rebuplic" is really a synonym for dictatorship :)
[21:39:19 CET] <JEEB> :)
[21:44:23 CET] <kierank> "A solution would be to repack the samples into a compatible format, eg.
[21:44:23 CET] <kierank> planar."
[21:44:28 CET] <kierank> i have no idea wtf he means by that
[21:44:53 CET] <kierank> is he going to try and do pixel processing in the packed domain or something?
[21:44:59 CET] <JEEB> I think if that's the guy who was here a few days ago, then it means poking data around so that it's in planar YCbCr
[21:45:06 CET] <JEEB> yuvXXXp
[21:45:08 CET] <kierank> implement his own adder perhaps
[21:45:10 CET] <kierank> yes
[21:45:21 CET] <jamrial> atomnuker: there are more diplomatic ways to tell people no...
[21:46:15 CET] <jamrial> your email was absurdly aggressive
[21:47:08 CET] <kierank> It was a bit extreme but these people need to be told
[21:53:25 CET] <llogan> it did seem quite angry
[21:59:15 CET] <funman> i think he got vaccinated broadcast ^_^
[21:59:41 CET] <CFS-MP3> Anyone reading that email is going to stay away from the ffmpeg developer community and with good reason
[22:00:04 CET] <CFS-MP3> And "those people" are just developers with a job, which today may be broadcast but tomorrow can be something totally different
[22:00:09 CET] <kierank> it's the opposite problem, people who think ideas are nice on a whiteboard
[22:00:19 CET] <kierank> but will want other people to maintain their crappy implementation
[22:00:32 CET] <kierank> yes they'll bugger off somewhere else and we'll have to fix their bugs
[22:00:47 CET] <kierank> and user complaints
[22:01:25 CET] <CFS-MP3> well, when there's user complaints there's users, some maybe what is useless for you it's useful for someone else
[22:02:12 CET] <kierank> meaningless statement
[22:02:34 CET] <CFS-MP3> make read it again if you can't make meaning out of it?
[22:02:36 CET] <kierank> some things remain difficult for good reason
[22:02:59 CET] <CFS-MP3> Well, being civil to other developers is not difficult
[22:03:02 CET] <kierank> it's not ffmpeg's job to do a poor implementation to give people the idea that what is difficult is easy
[22:03:19 CET] <kierank> forcing your pet feature into ffmpeg and leaving then having others maintain it is also not difficult
[22:03:54 CET] <CFS-MP3> telling someone to fuck off in the mailing list when he just offered to do something is definitely a terrible way to get good contributions in the future from that individual or anyone who just happened to subscribe 
[22:04:11 CET] <kierank> We've probably saved them thousands of man-hours
[22:04:17 CET] <kierank> doing something they wouldn't be able to do
[22:04:50 CET] <kierank> ok, maybe hundreds of man hours
[22:05:12 CET] <CFS-MP3> that's not really your problem, if they want to try and can somehow figure out a way to do it, maybe even do whatever huge refactoring is needed to get it done in an elegant way why tell them not even try
[22:05:28 CET] <funman> but you need to refactor the kernel
[22:05:30 CET] <kierank> it is my problem, because when he leaves for his next contract someone has to fix all these bugs
[22:05:33 CET] <kierank> that too
[22:05:37 CET] <CFS-MP3> why underestimate the resources or cleverness of people you don't know
[22:05:43 CET] <cone-065> ffmpeg 03Andreas Cadhalpun 07master:89eb398c7fc4: icodec: correctly check avio_read return value
[22:05:44 CET] <kierank> or if he makes breaking changes that I have to deal with 
[22:06:07 CET] <funman> CFS-MP3: i used to work there
[22:06:08 CET] <Compn> CFS-MP3 : kierank knows what he is talking about and he knows ffmpeg code. if he says it cant be done , i trust him
[22:06:16 CET] <Compn> also i trust atomnuker abilities as well...
[22:06:38 CET] <kierank> "That said some people in the community will encourage you to do it because
[22:06:39 CET] <kierank> they don't understand the complexity of the problem and it is why FFmpeg is
[22:06:39 CET] <kierank> full of broken things and has a bad name in the professional world."
[22:06:52 CET] <Compn> if person on ML wants to do it, let him do it in his own repo, he doesnt need ffmpeg help if hes being paid to work on it
[22:07:20 CET] <JEEB> CFS-MP3: I do agree that atomnuker's response was out of the line, but you could read from the e-mail that the person thought that the pixel format was the biggest problem
[22:07:33 CET] <kierank> yeah proves that the person has no clue
[22:08:08 CET] <CFS-MP3> kierank so what if he doesn't have a clue? You can just list of the top of your head a bunch of other bigger problems that you see but he doesn't 
[22:08:12 CET] <CFS-MP3> there's no need to be rude
[22:08:26 CET] <kierank> had no choice after you're little escapade
[22:08:31 CET] <kierank> your*
[22:08:31 CET] <Compn> although i think kierank works on competing software to ffmpeg and kierank doesnt want ffmpeg to have 'broadcast' fixes :D
[22:08:32 CET] Action: Compn runs
[22:08:33 CET] <CFS-MP3> plus expecting people to "have a clue" when they're new to a large problem is not realistic at all
[22:08:36 CET] <kierank> certain people don't listen
[22:08:42 CET] <kierank> (hint: i'm talking to one now)
[22:08:49 CET] <kierank> they think their way or the highway
[22:08:54 CET] <kierank> in spite of complex technical problems
[22:08:56 CET] <funman> Compn: ahah you haven't seen the light yet!
[22:09:02 CET] <Compn> :D
[22:09:16 CET] <JEEB> CFS-MP3: kierank actually posted a civil response, just fyi :P
[22:09:33 CET] <wm4> nice drama, can I join
[22:09:39 CET] <kierank> those guys even called me
[22:09:43 CET] <kierank> and I told them not to do it
[22:09:48 CET] <kierank> and then they post on the ML wanting to do it
[22:10:00 CET] <kierank> and who is going to pick up the pieces of this mess in the end I wonder
[22:10:04 CET] <kierank> when they break a ton of stuff
[22:10:40 CET] <kierank> multimedia development doesn't take place on a whiteboard
[22:10:43 CET] <kierank> this isn't node.js
[22:11:13 CET] <wm4> ew advocating upipe (sounds like a nice idea but haven't heard any good about it)
[22:11:22 CET] <CFS-MP3> OK, you are by definition right and no one can attempt to contribute without your OK - if you say no then it's no and nothing will change your mind
[22:11:24 CET] <CFS-MP3> that's clear
[22:11:29 CET] <CFS-MP3> have a nice day
[22:11:43 CET] <kierank> nice straw man
[22:11:44 CET] <Compn> kierank : dont scare off CFS-MP3 , we need to be friends with kodi
[22:11:44 CET] <JEEB> wm4: I heard at least the timestamp fields there are nice
[22:12:00 CET] <kierank> wm4: cf what I wrote in the message
[22:12:15 CET] <funman> wm4: did you hear anything bad?
[22:12:42 CET] <kierank> upipe is complex, sure but it's designed to solve complex multimedia problems
[22:12:48 CET] <kierank> not run-of-the mill problems
[22:12:54 CET] <Compn> is upipe french made ?
[22:12:58 CET] Action: Compn trolls and runssss
[22:13:10 CET] <wm4> funman: yes, that it's not actually good and that it's kept alive by people who were unfortunate to rely on it and now have to maintain it as part of their company's software stack
[22:13:12 CET] <funman> it also solves a big lack of macros
[22:13:24 CET] <funman> wm4: wow who is this?
[22:13:26 CET] <kierank> wm4: eh?
[22:14:00 CET] <funman> you have to be thinking of something else
[22:17:35 CET] <funman> ebail: hello
[22:18:19 CET] <wm4> CFS-MP3: they say that saying "no" is a maintainer's job
[22:18:46 CET] <kierank> ebail: hello
[22:18:49 CET] <wm4> I don't quite understand this case though
[22:18:50 CET] <Compn> ebail : although there maybe insults on the replies, please dont be offended, none of the developers can speak for the whole project.... 
[22:19:11 CET] <wm4> must be a quite dumb protocol if it needs special kernel mechanisms for performance
[22:19:20 CET] <kierank> wm4: no, it's just got a LOT of data
[22:19:42 CET] <funman> ebail: i worked at sfl on sflphone (when it was still called that way :)
[22:19:44 CET] <kierank> several orders of magnitude more than 99.99% of people deal with in ffmpeg
[22:22:18 CET] <Compn> note that ebail only mentioned adding pixfmts to ffmpeg. possibly using ffmpeg in a chain or just the swscale in a chain somewhere... no mention of network code.
[22:22:21 CET] Action: Compn runs
[22:22:56 CET] <wm4> these formats don't sound like a good match for pixfmts
[22:24:56 CET] <kierank> pixfmts are orthogonal to the problem
[22:26:43 CET] <kierank> btw, if anyone wants anything fuzzed please let me know
[22:50:23 CET] <reynaldo> some of whats going on in our mailing list shouldnt be allowed at all. The kind of behavior you see on the "TR-03 implemenation" thread can not be justified by any technical reason. No matter what
[22:51:06 CET] <reynaldo> I would like to see a coordinated action to stop this for once and for all
[22:54:15 CET] <wm4> can we also put a stop on low quality features once and for all
[22:54:36 CET] <wm4> because at this point I'd consider such "rudeness" as necessary evil
[22:55:04 CET] <kierank> Regrettable +1
[22:56:28 CET] <ebail> hi funman kierank, Compn, thanks for your comments. We will study carrefully your answers. If you have any other comments, you are welcome ;)
[22:57:05 CET] <reynaldo> wm4: I am of the opinion that rudeness and violence have no place in a technical defense
[22:57:15 CET] <reynaldo> I would like to think Im not the only one
[22:58:43 CET] <wm4> reynaldo: the problem starts if technical concerns are completely ignored
[22:58:58 CET] <wm4> which hasn't happened yet in this case, but did often in the past
[22:58:59 CET] <dkc> well, if it was the third thread in two days about the same topic then maybe it would be a necessary evil
[22:59:31 CET] <reynaldo> wm4: I mentioned a specific thread
[22:59:41 CET] <reynaldo> please do not dilute this conversation
[23:00:48 CET] <nevcairiel> Well you used terms like "for once and for all", which implies a general topic and not an isolated incident
[23:00:58 CET] <reynaldo> this behavior can not be allowed from the project developers, no matter how technically gifted they are or appear
[23:01:19 CET] <funman> ebail: btw does Radio Canada have specific use case yet or are they just future-proofing?
[23:01:38 CET] <reynaldo> nevcairiel: might be my crude english showing up. Im refering to all the similar cases involving unprovocated and uncalled for rudeness and violence
[23:04:01 CET] <reynaldo> littrle can be one about what happened in the past, we cant even "recall" the ofending parts of this thread but I would like to propose that going forward, this behavior its clearly off limits and ppl to be held accountable for it
[23:04:57 CET] <ebail> thanks for your kind works reynaldo 
[23:05:11 CET] <ebail> *words
[23:06:43 CET] <wm4> reynaldo: why is rudeness bad anyway?
[23:09:17 CET] <kierank> Make FFmpeg great again
[23:09:19 CET] <gnafu> wm4: In this case, the rudeness was surprisingly strong to me, and I'm one who usually doesn't mind some strong words and strong opinions.
[23:10:10 CET] <funman> we're gonna put a rfc4175 pixel format in FFmpeg and we're gonna make Radio Canada pay for it
[23:10:22 CET] <gnafu> funman: :-D
[23:10:49 CET] <nevcairiel> Often people are just very passionate about certain topics which makes them a bit thoughtless, instead of meaning to be rude
[23:12:45 CET] <gnafu> nevcairiel: I definitely saw that in this case, sure.
[23:14:19 CET] <gnafu> (And to clarify: I only saw this because it was mentioned here, and I am probably the least qualified to weigh in on developer discussion etiquette.)
[23:14:50 CET] <reynaldo> I dont think violence can be justified just because we think it's comming from passion
[23:16:27 CET] <reynaldo> even if you dont get the human implications of this, try to see how this plays out in our interaction with other organizations
[23:16:47 CET] <reynaldo> OPW, Google's GSoC, etc
[23:17:32 CET] <wm4> these have been always worthless
[23:17:42 CET] <reynaldo> it is bad, really bad. I think I've worked on application letter's to these programs in which we state quite clearly that we are able to thread ppl with respect
[23:17:56 CET] <ssalenik> funman: to answer your question for eloi (I'm also working on this project), I think its a bit of both... but basically they think broadcasting will be moving to this new IP format and they want to explore libre software solutions to prevent them from having to invest in proprietary solutions... ffmpeg was the first choice since they already use it in other applications
[23:18:26 CET] <reynaldo> wm4: again, unless I'm really not understanding you I think you are willing to justify violence on technical merits or lack thereof
[23:18:48 CET] <reynaldo> I think this is a fundamental difference I cant really get across
[23:19:00 CET] <kierank> ssalenik: this is too naive
[23:19:04 CET] <kierank> the world is not a whiteboard
[23:20:59 CET] <funman> ssalenik: https://blog.cloudflare.com/how-to-receive-a-million-packets/
[23:23:24 CET] <ssalenik> kierank: I'm not sure what you mean... we're exploring a solution which seems reasonable to us, if it turns out to not be the case, then we'll do something else
[23:23:42 CET] <wm4> reynaldo: it's just another tone which some apparently don't like
[23:23:48 CET] <kierank> with all due respect you don't know what you are talking about
[23:24:05 CET] <kierank> you're talking to a number of people who have gone and done this
[23:24:11 CET] <kierank> and who know exactly what they are doing
[23:24:24 CET] <wm4> that said even "non-violent" words can make just as much negative and destructive effect on a person as "violent" words so I don't buy this sentiment
[23:24:34 CET] <ebail> so please kierank, share your experience
[23:24:42 CET] <ssalenik> sure, which is why we were asking for feedback about it from the community/experts
[23:24:45 CET] <kierank> ebail: we explained all of this multiple times in the email
[23:24:53 CET] <kierank> if you don't like the technical reality that's tough luck
[23:24:53 CET] <ssalenik> are*
[23:25:08 CET] <kierank> we can't help you build your perpetual motion machine
[23:25:19 CET] <ssalenik> and we appreciate your feedback
[23:26:23 CET] <kierank> when we implemented it we listened to people who did it before
[23:26:30 CET] <kierank> instead of ignoring them
[23:28:42 CET] <wm4> ssalenik, ebail: what they actually want to say is that ffmpeg is a really bad match for this task and that there are better projects (which have been pointed out)
[23:29:22 CET] <kierank> well I did say that
[23:29:42 CET] <ebail> sure wm4. we are not ignoring you kierank.
[23:29:46 CET] <ssalenik> yup, thats why we're asking the questions... if it turns out that what we want to do isn't doable in ffmpeg, or the solution won't be upstreamed, thats fine as well
[23:30:17 CET] <kierank> this is why we have all the assembly code in a different repo by the way
[23:30:22 CET] <kierank> because it doesn't fit upstream
[23:30:39 CET] <wm4> ehat also was implicated - it's not hard to get things into ffmpeg, but this is also why ffmpeg has so many low quality features
[23:30:50 CET] <wm4> which are half-broken, work only in certain situations, etc.
[23:31:06 CET] <wm4> one example would be the PSD "decoder" (not sure if it made it in yet)
[23:31:36 CET] <kierank> scte-35 is another example, the web server
[23:31:38 CET] <kierank> etc
[23:39:36 CET] <ssalenik> yup... I think the reasoning behind trying ffmpeg first was that they already use it for some things and if its possible to have this new format in ffmpeg they would also use other features of it in conjunction, so the natural reaction is to try to contribute to ffmpeg... but the project is in R&D phase so we're just seeing if these functionalities align with the possibilities / vision of the project
[23:41:33 CET] <ssalenik> *possibilities / vision of ffmpeg
[23:44:02 CET] <nevcairiel> we're of course not opposed to new features - but they should of course match the overall design/philosophy and be technically feasible, which as it seems would be the part thats in question
[23:44:53 CET] <nevcairiel> personally I wouldn't call our rtp code very reliable as it is, so shovling gigabits of data per second through there seems very error prone
[23:48:46 CET] <kierank> that's actually not the issue
[23:48:56 CET] <kierank> the issue is how to get the data reliably into ffmpeg in the first place
[23:49:04 CET] <kierank> the "codec" processing is not too hard
[00:00:00 CET] --- Fri Nov 11 2016