Re: [FFmpeg-devel] DCA Decoder
On Thu, Mar 12, 2015 at 08:10:17AM -0400, compn wrote: > On Thu, 12 Mar 2015 11:47:55 + > Derek Buitenhuis wrote: > > answer to that is a *single* decoder, which works the best - > > just say it with less words. you dont want dual decoders like prores. i strongly want to avoid dual decoders and this is part of why i ever replied to this thread The situation ATM is that the dts/dca decoder in FFmpeg has features that are missing in Libav. If niels patch is rebased onto FFmpeg and Marcus works on top of FFmpeg either before or after niels patch then theres just one decoder that has all features and bugfixes But if Marcus rebases his work on top of Niels work before this is rebased onto FFmpeg then his work and Niels work will be on Libav and the FFmpeg decoder will have features missing in Libav so we will then have 2 decoders like in prores or someone will have to merge them which will require at least testcases to test the features, and thats why i asked for testcases I want to avoid 2 decoders but whenever i mention "use FFmpeg" i get accused of being "anti Libav" or "butthurt" or various other things If people cooperate and produce 1 DCA/DTS decoder with all features then we will have 1, otherwise there might be 2 I hope my mail is not misunderstood again [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/12/2015 12:34 PM, Michael Niedermayer wrote: > Its interresting what kind of bizare replies one gets by stating on > the main FFmpeg development list that work should be based on FFmpeg > and should be tested. And then repeating a few times that this is > really what was meant and none of the implications others jumped to > are. Perhaps there has been a gross miscommunication but that's not what I've been reading, nor others, from what I gather from asking. Not much use in continuing flames, regardless. If Marcus has not be scared off, I think the best course is to encourage him to talk to Niels. 2 people working together is better than 2 parallel implementations. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Thu, Mar 12, 2015 at 11:47:55AM +, Derek Buitenhuis wrote: > On 3/12/2015 11:25 AM, Michael Niedermayer wrote: > > you continue to talk about something completely unrelated to what i > > said/meant. > > > > you: take best code > > [...] > > > I: for code to be ever in FFmpeg it must either be developed on top > > of FFmpeg or it must be rebased/ merged/integrated at some point. Its > > better if its developed and tested on top of FFmpeg in the first place > > as this is less work and has a lower chance of bugs. > > FUD as usual, and utter nonsense - see below. > > > The difference here is the "question" that is awnsered > > like in "there are 2 X implementations, which should we use" vs. > > "I want to write a X implementation, on top of what codebase should > > i do the work" > > Except it's already written. "I want to" is not a part of the question, > for either implementations. > > >> Yeah, merge one patchset in FFmpeg, and if it turns out the other functions > >> better, the resulting mess is best summed up as "a clusterf*ck"... > > > > you really are missunderstanding what i meant > > > > I did not mean to suggest to push > > something to main FFmpeg master, i suggested or intended to suggest, > > that code be developeed on top of FFmpeg, code generally is developed > > by a devloper locally on his box or in his own public repo. > > Writing in full English sentences certainly would help my comprehension. > > My point above was that both are already 'developed' to a usable point, > as far as I can tell. It's irrelevant which codebase they're on top of. > They both exist. They can both be merged in different ways.. Being developed > on top of one codebase or the other does not give an advantage, and does > not make it in any way special in any sense. > > I am looking at what is the best end result for the *user*. The answer to that > is a *single* decoder, which works the best - regardless of the "effort" it. > Yes, > I don't buy that merging one from Libav causes "more bugs" than independently > reviewing and pushing a different one. > > I am sad to see that so many years later, these sorts of stupid tropes are > still > being thrown around by everyone on both sides. Scaremongering and FUD, > whether or > not you truly believe it to be the case or not. The users are the ones > suffering > in the end. > > >> This is a strawman argument (or perhaps just FUD). > > > > From your point of view its indeed a strawman, and from my point of > > view your arguments are a strawman because we just talk about 2 > > completely different things from the begin. > > Yes, from my point of view. The view of someone who is associated with > neither project, and is a downstream user. Someone who doesn't care > about the past, or people being butthurt by someone else which I did > not witness. Someone who cares about how the end result will look. > > Perhaps you should lay off the kool-aid. Even Jim Jones seems sane > in comparison to these two projects. Y'all are insane. Its interresting what kind of bizare replies one gets by stating on the main FFmpeg development list that work should be based on FFmpeg and should be tested. And then repeating a few times that this is really what was meant and none of the implications others jumped to are. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Thu, 12 Mar 2015 11:47:55 + Derek Buitenhuis wrote: > answer to that is a *single* decoder, which works the best - just say it with less words. you dont want dual decoders like prores. (i'm not going to make the argument that multiple users use different prores versions because i dont want to talk about that haha.) -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Thu, 12 Mar 2015 11:47:55 + Derek Buitenhuis wrote: > I am looking at what is the best end result for the *user*. The answer to that > is a *single* decoder, which works the best - regardless of the "effort" it. > Yes, > I don't buy that merging one from Libav causes "more bugs" than independently > reviewing and pushing a different one. > > I am sad to see that so many years later, these sorts of stupid tropes are > still > being thrown around by everyone on both sides. Scaremongering and FUD, > whether or > not you truly believe it to be the case or not. The users are the ones > suffering > in the end. And it's definitely hurting both projects, not only the "other" one, as some with impure intentions probably hope. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/12/2015 11:25 AM, Michael Niedermayer wrote: > you continue to talk about something completely unrelated to what i > said/meant. > > you: take best code [...] > I: for code to be ever in FFmpeg it must either be developed on top > of FFmpeg or it must be rebased/ merged/integrated at some point. Its > better if its developed and tested on top of FFmpeg in the first place > as this is less work and has a lower chance of bugs. FUD as usual, and utter nonsense - see below. > The difference here is the "question" that is awnsered > like in "there are 2 X implementations, which should we use" vs. > "I want to write a X implementation, on top of what codebase should > i do the work" Except it's already written. "I want to" is not a part of the question, for either implementations. >> Yeah, merge one patchset in FFmpeg, and if it turns out the other functions >> better, the resulting mess is best summed up as "a clusterf*ck"... > > you really are missunderstanding what i meant > > I did not mean to suggest to push > something to main FFmpeg master, i suggested or intended to suggest, > that code be developeed on top of FFmpeg, code generally is developed > by a devloper locally on his box or in his own public repo. Writing in full English sentences certainly would help my comprehension. My point above was that both are already 'developed' to a usable point, as far as I can tell. It's irrelevant which codebase they're on top of. They both exist. They can both be merged in different ways.. Being developed on top of one codebase or the other does not give an advantage, and does not make it in any way special in any sense. I am looking at what is the best end result for the *user*. The answer to that is a *single* decoder, which works the best - regardless of the "effort" it. Yes, I don't buy that merging one from Libav causes "more bugs" than independently reviewing and pushing a different one. I am sad to see that so many years later, these sorts of stupid tropes are still being thrown around by everyone on both sides. Scaremongering and FUD, whether or not you truly believe it to be the case or not. The users are the ones suffering in the end. >> This is a strawman argument (or perhaps just FUD). > > From your point of view its indeed a strawman, and from my point of > view your arguments are a strawman because we just talk about 2 > completely different things from the begin. Yes, from my point of view. The view of someone who is associated with neither project, and is a downstream user. Someone who doesn't care about the past, or people being butthurt by someone else which I did not witness. Someone who cares about how the end result will look. Perhaps you should lay off the kool-aid. Even Jim Jones seems sane in comparison to these two projects. Y'all are insane. >> From what I understand, neither of them implements fixed point yet in >> the core DCA decoder, which means neither is actually lossless or >> bit-exact. > > ok, but do they implement something testable ? > and if so, how can this be tested ? > knowing this will be usefull to anyone working on the code I do not think DCA extensions are independently testable from the core, but I may be misunderstanding. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Wed, Mar 11, 2015 at 09:44:22PM +, Derek Buitenhuis wrote: > On 3/11/2015 9:36 PM, Michael Niedermayer wrote: > > Thats analogous to saying "no its not important to put fuel in a > > car, its important to drive the best car" > > No what I propose is to look at both and decide which is best. Simply being > submitted to FFmpeg first does not make it better. you continue to talk about something completely unrelated to what i said/meant. you: take best code I: for code to be ever in FFmpeg it must either be developed on top of FFmpeg or it must be rebased/ merged/integrated at some point. Its better if its developed and tested on top of FFmpeg in the first place as this is less work and has a lower chance of bugs. The difference here is the "question" that is awnsered like in "there are 2 X implementations, which should we use" vs. "I want to write a X implementation, on top of what codebase should i do the work" > > > the 2nd is more work, so i suggest that new code is based on top of > > FFmpeg already. Merge/rebase that patchset from Libav if you want > > to work on top of it. > > Yeah, merge one patchset in FFmpeg, and if it turns out the other functions > better, the resulting mess is best summed up as "a clusterf*ck"... you really are missunderstanding what i meant I did not mean to suggest to push something to main FFmpeg master, i suggested or intended to suggest, that code be developeed on top of FFmpeg, code generally is developed by a devloper locally on his box or in his own public repo. > > > The more code is rebased and merged around the higher the risk of > > bugs > > This is a strawman argument (or perhaps just FUD). From your point of view its indeed a strawman, and from my point of view your arguments are a strawman because we just talk about 2 completely different things from the begin. > > > Also if someone has testcases for all the new DCA features, i would > > be interrested to have them so i can test these things if/when needed > > From what I understand, neither of them implements fixed point yet in > the core DCA decoder, which means neither is actually lossless or > bit-exact. ok, but do they implement something testable ? and if so, how can this be tested ? knowing this will be usefull to anyone working on the code [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 11 March 2015 at 14:42, Marcus Johnson wrote: > I've been working on adding XLL for the last couple months, it's still not > quite complete, basically I have to combine the Core and XLL samples before > it's output, and I also have to finish the latter stages of decoding the > XLL like channel decorreclation, and post processing. > > There are a few issues thought. > > 1: My code doesn't have the most recent chances from master, how do I fix > this? > > 2: I read that you'd prefer for code to be small and self contained, but > how can I do that when the later functions directly require earlier ones? > > 3: I've been using the variable names the white paper uses which doesn't > match your guidelines, obviously they need to be renamed but I'm not sure > what else you guys want me to do with that? > > 4: currently almost all of the variables are being stored in DCAContext and > accessed in different functions this way, I assume this is looked down upon > and you'll want me to change this style to use the variables in the > disparate functions when it's called rather than passing it around the > backend, is this correct? > > That said, I've rewritten the ExSS code, ExSS Asset Descriptor, XLL, and > XLL ChSet functions are completely ready to go. I hope this doesn't make you feel bad for your effort but you know there's a patch on libav-devel, right? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 2:42 PM, Marcus Johnson wrote: > I've been working on adding XLL for the last couple months, it's still not > quite complete, basically I have to combine the Core and XLL samples before > it's output, and I also have to finish the latter stages of decoding the > XLL like channel decorreclation, and post processing. Forgot to ask: Is it available in a branch somewhere to review? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 9:36 PM, Michael Niedermayer wrote: > Thats analogous to saying "no its not important to put fuel in a > car, its important to drive the best car" No what I propose is to look at both and decide which is best. Simply being submitted to FFmpeg first does not make it better. > the 2nd is more work, so i suggest that new code is based on top of > FFmpeg already. Merge/rebase that patchset from Libav if you want > to work on top of it. Yeah, merge one patchset in FFmpeg, and if it turns out the other functions better, the resulting mess is best summed up as "a clusterf*ck"... > The more code is rebased and merged around the higher the risk of > bugs This is a strawman argument (or perhaps just FUD). > Also if someone has testcases for all the new DCA features, i would > be interrested to have them so i can test these things if/when needed >From what I understand, neither of them implements fixed point yet in the core DCA decoder, which means neither is actually lossless or bit-exact. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Wed, Mar 11, 2015 at 09:04:39PM +, Derek Buitenhuis wrote: > On 3/11/2015 8:25 PM, Michael Niedermayer wrote: > > whats important is a patchset based on and tested on FFmpeg, at least > > if people want a working decoder in FFmpeg > > No, what's important is that the best possible code is used. Origin is > irrelevant. you misunderstood me Thats analogous to saying "no its not important to put fuel in a car, its important to drive the best car" Of course the best possible code should be used but that either is based on FFmpeg and tested on FFmpeg already or it needs to be git rebased / merged onto FFmpeg and then tested. the 2nd is more work, so i suggest that new code is based on top of FFmpeg already. Merge/rebase that patchset from Libav if you want to work on top of it. The more code is rebased and merged around the higher the risk of bugs Also if someone has testcases for all the new DCA features, i would be interrested to have them so i can test these things if/when needed Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 8:25 PM, Michael Niedermayer wrote: > whats important is a patchset based on and tested on FFmpeg, at least > if people want a working decoder in FFmpeg No, what's important is that the best possible code is used. Origin is irrelevant. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Wed, Mar 11, 2015 at 04:07:00PM +0100, Hendrik Leppkes wrote: > On Wed, Mar 11, 2015 at 4:02 PM, Marcus Johnson > wrote: > > I thought the patch on LibAV was completely removed? > > http://thread.gmane.org/gmane.comp.video.libav.devel/66825/focus=66826 > > It'll probably be merged soon'ish. It still has some open TODOs, but > at this point its probably a much better idea to work on improving > this instead of creating a parallel implementation. whats important is a patchset based on and tested on FFmpeg, at least if people want a working decoder in FFmpeg [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On Wed, Mar 11, 2015 at 4:02 PM, Marcus Johnson wrote: > I thought the patch on LibAV was completely removed? http://thread.gmane.org/gmane.comp.video.libav.devel/66825/focus=66826 It'll probably be merged soon'ish. It still has some open TODOs, but at this point its probably a much better idea to work on improving this instead of creating a parallel implementation. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
I thought the patch on LibAV was completely removed? it was purged from the codebase like 9 months ago or something, I stumbled on that while trying to fix some of the issues with the white paper I was having. I haven't bothered with the Core decoder, but everything I've extracted so far is fixed point. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DCA Decoder
On 3/11/2015 2:42 PM, Marcus Johnson wrote: > I've been working on adding XLL for the last couple months, it's still not > quite complete, basically I have to combine the Core and XLL samples before > it's output, and I also have to finish the latter stages of decoding the > XLL like channel decorreclation, and post processing. There is a patch on Libav's mailing list that will likely soon be merged that implements the XLL extension. Have you looked at that or talk to its author? Working together seems better than duplicated effort. > 1: My code doesn't have the most recent chances from master, how do I fix > this? git pull --rebase ? (backup to a branch first) > 2: I read that you'd prefer for code to be small and self contained, but > how can I do that when the later functions directly require earlier ones? Not sure I follow? > 3: I've been using the variable names the white paper uses which doesn't > match your guidelines, obviously they need to be renamed but I'm not sure > what else you guys want me to do with that? Can't really tell without looking > 4: currently almost all of the variables are being stored in DCAContext and > accessed in different functions this way, I assume this is looked down upon > and you'll want me to change this style to use the variables in the > disparate functions when it's called rather than passing it around the > backend, is this correct? Can't really tell without looking. > That said, I've rewritten the ExSS code, ExSS Asset Descriptor, XLL, and > XLL ChSet functions are completely ready to go. Does this include a fixed point implementation to make it actually lossless? IIRC this is the only thign the existing patch set from Niels lacks. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] DCA Decoder
I've been working on adding XLL for the last couple months, it's still not quite complete, basically I have to combine the Core and XLL samples before it's output, and I also have to finish the latter stages of decoding the XLL like channel decorreclation, and post processing. There are a few issues thought. 1: My code doesn't have the most recent chances from master, how do I fix this? 2: I read that you'd prefer for code to be small and self contained, but how can I do that when the later functions directly require earlier ones? 3: I've been using the variable names the white paper uses which doesn't match your guidelines, obviously they need to be renamed but I'm not sure what else you guys want me to do with that? 4: currently almost all of the variables are being stored in DCAContext and accessed in different functions this way, I assume this is looked down upon and you'll want me to change this style to use the variables in the disparate functions when it's called rather than passing it around the backend, is this correct? That said, I've rewritten the ExSS code, ExSS Asset Descriptor, XLL, and XLL ChSet functions are completely ready to go. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
