<div dir="ltr">2013/4/3 Carl Eugen Hoyos <span dir="ltr"><<a href="mailto:cehoyos@ag.or.at" target="_blank">cehoyos@ag.or.at</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>Lars Hammarstrand <lars.hammarstrand@...> writes:<br>
<br>
> > Exactly 14 iterations, please trust me, I am doing<br>
> > this quite often.<br>
><br>
> Ok, I'll trust you completely<br>
<br>
</div>(I was actually wrong: 14 iterations == 15 compiles)<br></blockquote><div><br></div><div>That will take roughly 7,5 hours (give or take) in a worst case scenario. That's why I want to automate with git bisec run. I played around with "git log" a found a commit that (what I think) seems close to 0.10 that will produce 13 iterations:</div>

<div><br></div><div><span style="font-family:'courier new',monospace">$ git bisect good 33c21378a846d880110324f3e139a693a9bb30ca</span><br></div><div><div><font face="courier new, monospace">Bisecting: 6686 revisions left to test after this (roughly 13 steps)</font></div>

<div><font face="courier new, monospace">[15a0fb58a3294876c23989915a4a6202411be1b0] Merge remote-tracking branch 'qatar/master'</font></div><div><br></div><div><div>But it seems you are using an earlier commit. Which commit did you use for "git bisect good"?</div>

<div><br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> Before starting, please test -cpuflags -neon and<br>
> --disable-neon to make 100% sure that we know what<br>
> we are searching for.<br>
><br>
> Success, --disable-neon and -cpuflags -neon did the trick!<br>
<br>
</div>I hoped you would first test -cpuflags -neon on<br>
a build with "--enable-neon" and then "--disable-neon"<br>
without any cpuflags - sorry for being unclear!<br></blockquote><div><br></div><div>Ok, I'll test that too!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
100% unrelated to this bisect that we should really<br>
do in any case (you may already have realized that<br>
nobody else but you is able to do it):<br></blockquote><div><br></div><div>Ok, lets do it! :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


I only start to realize now what you are actually<br>
doing, please allow me state very, very clearly that<br>
it is imo *not* a good idea to update xbmc now to a<br>
version of FFmpeg that is already outdated. There<br>
will be no future release series containing new<br>
features but the old API!</blockquote><div><br></div><div><div>Well, yes - we're aware about the new api and that 1.2 will the be the last version with the old api. But since a change to the new api will take some time to implement, we want to use the version 1.2 that solves a bunch of other more or less serious problems that we currently struggle with in version 0.10.2. We are talking show stoppers that is for instance preventing users to watch certain content types, hangs or causes stuttering video playback. And we can't be sure this problem won't occur with the new api, can we? </div>

<div><br></div><div>Xbmc does currently work with ffmpeg n1.2 on all platforms except IOS thus it's worth the effort to fix this particular problem.</div><div>--</div></div></div></div></div>