Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - wintix

#1
Hey Alex, you mentioned in the main post that porting work for 1.3.3 has already been done. Is there any news regarding that post, do you need help testing or do you have other priorities right now? I flashed my cam to the newest firmware by accident and wanted to check first before downgrading again.
Thanks!
#3
if you have to sync anyway, just get an external recorder. it will also yield way better results than the internal mic / a hot shoe mounted one.
#4
if i'm not mistaken, that was requesed, discussed and tried elsewhere in this thread but it didn't reliably work from the software side.
#5
how about try reading his post? all the information needed is there.
#6
as there is now a larger userbase than just you alex and no problems seem to arise, are there any hopes to get 5d3 into a stable state?
#7
the full-feature fw runs like a charm, thanks to anyone involved!
#8
Hm. Technically it shouldn't be an issue then to release the python script that puts the .fir together? (without the keys)
#9
Ok, understandable, thanks for clearing that up.

Maybe there should be a note included in the build instructions to let people know that the compilation of .fir files is not publicly possible due to copyright issues and hence fiddling with new ports is not feasible. - Or is there already a sane way to enable the bootflag on 5D3 or 7D? (Those are the only cams I own)

#10
Quote from: a1ex on July 08, 2012, 07:56:18 PM
The tools for compiling the FIRs are not public.
Just discovered this piece of information once I had the complete build environment going. So there's no way to build a FIR file that's accepted by the camera on your own?
#11
will it start up cleanly without needing liveview?
#12
Aaaah! Got it.

My problem was that I had the cam in photomode. I just redid the tests with videomode, only the fir file on the cards and it works as it should. Swiftly boots, blinks, takes a pic and doesn't freeze. Also the testfile is on all cards being its 1,025,000 bytes in size.

That is again:

Transcend CF 64 GB 400x and 600x
INX 1GB SD (sloooow and old)
#13
edit: got it to work, see later post.
#14
Do you also need test results with other cards?
#15
Quote from: a1ex on October 11, 2012, 04:51:46 PM
Nice. I'll try to prepare the alpha 2 next week.

HDMI is causing trouble - anyone needs 720p? I hope not.

great!
nope, not really. everything is headed for high-res anyway
#16
sounds great. hopefully you will get comfortable with using prop_request_change in an alpha soon :)
#17
mhm, i see your point there.
#18
how is that particular call dangerous? if i understand it correctly, it changes camera settings and can potentially lead to a non-booting camera if invalid values are written for whatever reason? - i do see why one wouldn't want to release something like that straight away but it probably doesn't get more safe than it already is with your testing so far?
#19
yeah, saw the changelog was pretty empty and hence hoped for a second alpha soon as things seemed stable from the outside.

i just read the forum thread you linked and it seems that only people that are using the sd card slot with high speed cards are speaking up so far. my glass ball guesses that since the 650d and the 5d3 used with a sd card are affected that it has something to do with the sd card implementation in recent cameras. maybe you can do a release with a ~15G file benchmark (or something so configure the size) to allow specific testing of the sd card slot in the 5d3. maybe it's possible to crash the camera reliably with putting some heavy usage on the sd card slot for a longer period of time.

so far i threw at the 5d3 what i could think of, went through several hundred pictures with ml enabled and didn't experience any issues so far, despite the minor redraw issue in video mode i mentioned earlier.

nice work on the 7d as well, btw! also looking forward to anything testable there. kind of cute to have two cameras with a port in progress. :D
#20
are you planning to release a second alpha to toy around with over the next weekend, alex? if so, what features do you consider to put in there?
#21
same here, looking forward to a alpha 2 build with a bit more functions to toy around with.

btw, is it my imagination or is modifying the shutter speed causing redrawing issues with the aperture number? it's kind of setting me off each time i fiddle with the settings as i first think that i accidentally changed aperture and not the shutter.
#22
Archived porting threads / Re: Canon 5D Mark III
September 15, 2012, 01:38:39 PM
it's a default function in ml, so it can probably be expected to be there again.
#23
you could do a test version for us to play with :)
#24
Quote from: a1ex on September 14, 2012, 05:03:06 PM
Well... with focus peaking and other graphics enabled, it's pretty good IMO. Try disabling GlobalDraw.
indeed, performance is pretty good and likely sufficient for high data rate video stuff. :)

video mode global draw disabled: 19,9mb/s 27,5mb/s 85,3mb/s
photo mode live view global draw disabled: 19,4mb/s 25,9mb/s 77,9mb/s

photo mode, menu, global draw disabled: 36,5mb/s 38,9mb/s 99,5mb/s (!)
(ran twice to confirm - missing autoboot is getting annoying ;)

i would guess we see the different results due to the fact that the data has to come from somewhere and also it's ml code which is dependant on how much stuff is going on. i bet canons native write operations are faster, independent on what mode the cam is in?

Quote from: a1ex on September 14, 2012, 05:03:06 PM
Looking forward to see some tests on a 1000x card.
oh yeah :)
#25
alex, just checked, photo mode live view is a tad faster, don't know why.