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 - pompeiisneaks

#1
Chmee, I've got visual studio 2012 and have been playing with the source a bit, added some exception code due to warnings, etc.  I'd be happy to help out on the code base, I'm trying to get my C# skills up, I've got a class on it this semester, so any tinkering I can do will help me.  Also, I can help try and add some more try/catch blocks for some of the I/O type errors we've been seeing, but wanted to make sure you're needing help with the program.

~Phil
#2
as Jimmy said, you get the one for your firmware version, are you running 1.2.3 or 1.1.3 of the Canon Firmware?  1.1.3 is a bit more stable at this point but 1.2.3 is getting much closer.  I've been using 1.2.3 because I like the idea of the clean HDMI out.
#3
General Development / Re: SRM job memory buffers
July 11, 2014, 06:02:24 PM
Here's the .113 version, again all the usual warnings, I used my build for a different .113 to test external monitors and it worked fine, but ymmv, but I'm pretty sure the codebase is stable and as usable in the srm-memory fork as any other.

https://www.dropbox.com/s/s136ezkzzad66hy/magiclantern-Nightly.2014Jul11.5D3113.zip
#4
General Development / Re: SRM job memory buffers
July 11, 2014, 05:37:54 PM
Quote from: mario1000 on July 11, 2014, 11:03:26 AM
Do you have a compiled version for 5D3.113?
I don't.  Realize this is a test version, mine couldn't take a picture, it kept saying 'busy' but I think that's because the code used is designed just to see if the ML code can allocate the memory.  If you want me to, I can do a build for 5D3.113, but I'm not going to test it first because rolling back to .113 is a pita.  So I won't have a chance to test it out, and it may not work. 

~Phil
#5
General Development / Re: SRM job memory buffers
July 11, 2014, 04:46:39 AM
Quote from: a1ex on July 02, 2014, 11:25:38 PM
These changes are not yet included in any nightly build (we are reverse engineering it as we speak, and sharing the details as soon as we discover them). Please be patient, and hope this will motivate the 6D developers to bring the port up to date.

Some quick tests on 5D3 123, first outside LiveView, second in LV:


I just did this on mine, here's the output on 5D3.123, seems the same.

#6
The major difference between RAW and MLV is that MLV supports audio as well as the Video.  Otherwise I think the quality is identical.  Both are RAW.  MLV is Magic Lantern's own RAW codec.  So if you always do separate audio and don't need a sync beep on the video to sync your audio up, then RAW is perfect. 

~Phil
#7
So I did the dump here and have a dropbox link to the zip file. 

Here's the file on dropbox:

https://www.dropbox.com/s/oxb9f724utgpojd/MLVRAMDUMP5D3.zip

If you can let me know so I can pull it from dropbox that would be good, as its rather big, 1.7gb.  I've Done the testing, a few thigns to note.

1. This is for my 5D3 on 1.2.3 using the 1.2.3 ML from nightly from 07032014.
2. I realized that my external monitor (A marshall 7") supports 24p and 60i, so I did both, but I'm not sure if the dumps support it, so if they 'overwrote' or something, the second set was 24p, so that would be w hat you got.
3. I did the external cable, but I'm really n ot sure how well it worked, because I didn't have easy access to a monitor that supported it, so I just got ready, plugged the cable in (now blind) and did the actions I'd done many times before.  I hope it worked.  I did this for my native NTSC and then went to PAL.

I also didn't do any MLV tests because I don't have any 1080 video, my cards are too slow and I can't get more than 1 frame at 1080 so I just skipped testing MLV playback.  I think you've probably got a lot of that anyway.  If you need me to test MLV, can you get me an MLV file thats at least 10-15 seconds to allow me to 'dump then hit play' on the differing modes?

Let me know if you have any questions.

BTW that dropbox archive is still syncing, so give it at least 30 mins from my post (Estimated time left now, could go up).

~Phil
#8
I just demoed that, and it worked great for me... I've updated the same on the bitbucket page.
#9
and by 'boot' and use the other as storage I mean you need to keep the CF card OUT of the 5d3 on boot, and then after it has loaded ML, put in the CF after that
#10
You could potentially do this, but I've not tried:  put ML 5d2 on the CF card, and since the 5d3 supports both CF and SD, put the ML 5d3 on the SD.  You'll be fine on the 5d2, but need to always make sure you boot from the SD without the CF in the 5d3, then you can use the CF as just a storage card?  Maybe?  I don't have a 5d2 to test.
#11
My random guess is that you're overloading the speed of the board that does the I/O and therefore pobox's suggestion seems to make sense, if you're sending less data at 24p it would reduce load on the bus.  But that is a guess coming from a more pc hardware level, not knowing the deep specs on the way the canon does I/O.
#12
As a more detailed answer, I personally don't know what the CPU is on the GoPro, but it is unlikely it is a proprietary Canon Digic chip.  The codebase for magiclantern is based off that CPU, and would likely never work on GoPro.  That being said, if you want to take the time to find out how to boot the cpu on the GoPro, you could potentially also use the code base for most of its programming once you adapted the core of the code that loads the custom magiclantern firmware into the camera's memory etc.  But that is no small task.  The team here that have done that work on Canon's Digic processors are mighty :P
#13
For the record, been awol IRL with school, kids etc, but just got the latest build from nightlies on my 5D3 1.2.3 and it seems loads better, the mlv format seems more solid now as well, and I've not seen any pink/corrupted frames in my limited testing, I just don't have one of those super fast computerbay or other cards that can handle raw at 80+Mbs.  It is looking really good otherwise from what I've seen.

Thanks for the excellent work.
#14
Oh odd, sorry looks like somehow my browser didn't update the last few posts.  I'll give it a test soon and see what I get.

~Phil
#15
So last I left this, I had functioning code but it was using the wrong methods to provide it, so we changed the code to use methods that don't work at all.  Did we determine why expected behavior was not working?  This issue could be considered resolved if we can sort that out.  Is it because I'm on the 5D3.123 code base by Chris Miller and its causing the LVINFO code to not trigger as expected by the INIT_FUNC method?
#16
so yeah noix222 the builds posted here have support for mlv recording and raw recording, you'll need to download them and try, using it for a project may be a bit premature, just a warning, this is very alpha build at this point.  If you're making money with this, it may be a bit too sketchy to try it.  But you're welcome to give it a go, the more data shown that it works the better.

~Phil
#17
with the latest version I've had no problem using raw and mvl raw recording.  I've not tested for long periods of time, but they build fine and run fine on .123.

~Phil
#18
This seems related to issue: https://bitbucket.org/hudson/magic-lantern/issue/1759/record-indicator-not-visible  I've commented there,  the code is working now and could use some testing via nightly etc.  It looks like it may not be working in other cameras, likely for the same reason, I'll have to take a look at blind porting my code over in the other bitrate*.c files, as I don't have another camera to test against.  (other than my wife's t3i I guess but I'd have to ask her if she minds :P)
#19
Okay so solution to 4, dividing by elapsed time seems to give a constant value, about 6/7 Mb/s.  This seems more realistic for MB/s, and the raw seems to be more along the 50-60Mb/s from what I recall, so I realized the previous calculation for Mb/s seemed to do this;

raw_bitrate / 1024 * 8 / 1024 (HUH?)

but in the lower instant they did

raw bitrate / 1024 / 1024

this makes more sense.  so I'm removing the *8 because 4*7 is wow 42 ish heheh.

I'll see if that resolves it.  building now.

~Phil
#20
Okay, working the kinks out.  I've got this working but a few questions. 

Problem 1.  the elapsed works well but seems to update only every 2 seconds not sure why.  ideas?
problem 2.  remaining seems to be doing something but it goes all over the place and sometimes has a really large non time number at the start 2345282934 or something. 
problem 3(?not a necessarily a problem). avg bitrate seems logical, goes up and down a bit but when I'm doing ALL-I, its seems to sit around 50-60mb/s is that normal? 
problem 4. the instant bitrate isn't, its total bits drawn, so I'm going to try and divide that by time elapsed and see if that seems more correct. 

At any rate, the only other thing that remains is how do I reset it after I stop recording?  Elapsed time just keeps ticking until I hit record again, what stops the LVINFO from writing data?  do I look for some other buf[0] value change for 'stopping recording' or in my == 0 value is there some 'LVINFO' reset function I can wipe it?

~Phil
#21
Remaining time seems to update every 2 seconds as if it were elapsed time hehe.  Elapsed doesn't show up, avg bitrate seems to show nothing, but 0:00 for a second then a white block. and instant bitrate shows some data definitely.  So I'm on track and can debug this, cool!

~Phil
#22
HEY!  It showed up, but I've got something else wrong now, it showed just a 0:00 so data isn't making it into it, but from there at least I have a starting point.  Cool!

~Phil
#23
Yes but I"m using a property handler, I'm guessing I'm doing it wrong obviously, but I do this:


static int movie_recording = 0;
PROP_HANDLER(PROP_MVR_REC_START)
{
    if (buf[0] == 1)
        movie_start_timestamp = get_seconds_clock();
    if (buf[0] == 2)
        movie_recording = 1;
}


to set a flag if the state is 2.  maybe that should be an else if?   and then an else for ==0?  But still, I would think that means it could be 'stuck on' in that case.  But ultimately I was trying to use the PROP_HANDLER on purpose there. 

~Phil
#24
I tried that again, I think I get what is being hinted at, but not sure if my method is sound, it doesn't work yet anyway.  I'll keep trying, but someone can look and see if what I'm doing makes sense at all maybe:

https://bitbucket.org/frenchiefilms/phil/src/6633808ec34cb23eff9c936681104d2af1ecda66/src/bitrate-5d3.c?at=unified

~Phil
#25
Quote from: dmilligan on February 12, 2014, 12:17:08 AM
a1ex has already given you the clue as to what is wrong: the way you have it coded, it will only work if the camera is already recording when ML initializes, you should change your code to work no matter what mode the camera is in when it initializes ;)

Oh man I totally missed that, sorry, I saw the smiley but missed the sarcasm, I was literally trying to record within 1 second of boot... /facepalm

~Phil