Recent Posts

Pages: [1] 2 3 ... 10
Reverse Engineering / Re: ProcessTwoInTwoOutLosslessPath
« Last post by reddeercity on Today at 12:34:48 AM »
@dfort , I've being checking your addresses for 5d2 and all go a "Pointer" then to  a different address in the .dis file , how are you looking these up ?
I couldn't find them in the string.htm at all. Just wondering if I'm doing this right , the ones I found seem to line up with the description in the ML code.
I use the 5d2.212.dis in MS Visual Studio Code  (free) and search for different variable to find addresses .
Visual Studio is really cool (supported in Win 7,8,10, Mac OS 10.9+ & Linux OS , it look for mistake/problems & make suggestions in the code , add extension
(clang etc. ... )when need them , can upset for "Github" (maybe bitbucket too, no sure)to clone code and even (if I'm not mistaken)
I can setup the tool chain to compile ml , but I haven got to it yet -- makes working with code a breeze .

Are these ~20ms or so important when it comes to audio sync?

Finally, a question I might be able to answer with some degree of confidence. When syncing film dailies we did our best to get sync to the nearest perf. There are 4-perforations per frame of 35mm film so at 24fps that's the equivalent of about 10.5ms, right? Well nobody can actually tell if sync is off unless they examine the waveform (audio pixel peeping) up to about 1-frame so that would be 42ms. When we went digital we were willing to accept sync within 2-frames which the average person can't detect so that's 84ms. I've worked on TV movies where the dailies came in with the sync off 3-frames and that didn't seem to bother anyone except the assistant editor--that would be me.

So no, those ~20ms or so variations shouldn't matter. That's not even a frame out of sync.
Took a closer look and hopefully managed to get a slightly better audio sync. Caveat: I only know this from debug messages; I'm afraid I don't have the equivalent of pixel peeping skills on the audio side (to tell whether audio is in sync or off by some split-second), sorry.

If my understanding of the video and audio pipelines is correct, then:
- video frames are timestamped as soon as the image is read out (evfReadOutDoneInterrupt); the capture process probably happens a little earlier, unsure about the exact timing
- audio frames are timestamped right after StartASIFDMAADC (when the audio recording starts)
- first audio frame is now started shortly after first video frame was captured (~ 2ms in my tests, but I had the trace module active)

It would have been probably better to timestamp the beginning of the exposure, but finding that requires either polling the EDMAC channel that brings the raw image into RAM, or a better understanding on how LiveView works, or - the easiest way - estimating it from FPS and rolling shutter info. Are these ~20ms or so important when it comes to audio sync?
General Help Q&A / Re: How accurate is the ML Intervalometer?
« Last post by a1ex on Yesterday at 11:05:15 PM »
Posted an experimental build (lua_fix) that also has improved intervalometer accuracy.

My quick test:
Code: [Select]
12.004.624  shoot_task:000841e4:00:00: lens_take_picture
16.004.611  shoot_task:000841e4:00:00: lens_take_picture
20.004.610  shoot_task:000841e4:00:00: lens_take_picture
24.004.612  shoot_task:000841e4:00:00: lens_take_picture
28.004.605  shoot_task:000841e4:00:00: lens_take_picture
32.004.622  shoot_task:000841e4:00:00: lens_take_picture
36.004.609  shoot_task:000841e4:00:00: lens_take_picture
40.004.609  shoot_task:000841e4:00:00: lens_take_picture
44.004.624  shoot_task:000841e4:00:00: lens_take_picture
48.004.609  shoot_task:000841e4:00:00: lens_take_picture

12.063.545  ShootCaptu:ff147854:93:03: scsReleaseStart
16.062.177  ShootCaptu:ff147854:93:03: scsReleaseStart
20.071.782  ShootCaptu:ff147854:93:03: scsReleaseStart
24.058.987  ShootCaptu:ff147854:93:03: scsReleaseStart
28.061.618  ShootCaptu:ff147854:93:03: scsReleaseStart
32.066.348  ShootCaptu:ff147854:93:03: scsReleaseStart
36.062.039  ShootCaptu:ff147854:93:03: scsReleaseStart
40.072.756  ShootCaptu:ff147854:93:03: scsReleaseStart
44.072.025  ShootCaptu:ff147854:93:03: scsReleaseStart
48.087.256  ShootCaptu:ff147854:93:03: scsReleaseStart

Just FYI: the intervalometer already used a loop similar to the one you suggested, since 2012 (that's why, even if there was some variation, there was no drift, unless the camera couldn't keep up because of slow card or whatever); it was just the delays within the waiting loop, and the timer update interval, that were too high.
General Chat / Re: Canon 70D Err 80 Brick
« Last post by a1ex on Yesterday at 10:56:54 PM »
If it doesn't show any sign of life with the diagnostic programs, that means we cannot run code on it. Feel free to PM me the ROMs, but my gut feeling says the issue might be elsewere (and the ROMs are very likely good).

The RXDMPU pin (or maybe TXDMPU, depending from which side it's labeled) is likely a serial port (UART) that prints MPU messages. I have no idea how these look like, it was more of a (low-priority) curiosity of mine. However, we did manage to unbrick an EOS M3 using the UART pads on the mainboard (so I have good reasons to believe these are useful).
General Chat / Re: Canon 70D Err 80 Brick
« Last post by TechnoPilot on Yesterday at 10:48:56 PM »
Hi a1ex, thanks for your fast and thorough reply.  So I have tried the portable display test you mentioned with my existing ML card (which was in the camera at the time of the lockup and brick).  Sadly the camera is completely unresponsive, nothing displayed, no LED blinks at all.  I tried this with all three of my fully charged Canon batteries and in all sequences of card and battery insert.   At the moment I don't have another Canon body on hand to use another correctly installed ML copy, will try that as soon as I can borrow my friend's 5D mkIII, but am not holding out hope of a difference.  I've got my original ROM dumps from the camera and checked for any LOGs that might have been triggered when this lockup/brick happened, but the last is from the end of last month.  Would any of this be helpful?  I've had ERR80 happen before in the past, but it was usually just a battery eject and I was good to go, just like if you insert a MicroSD card adapter into most Canon cameras and close the card door without a MicroSD card in it (in fact this soft-bricked it harder with the requirement to first boot the camera with no card in it, before reinserting a card)

I'm not sure what you mean in regards to the RXDMPU pin route, since the forum you link to doesn't seem to have much beyond speculation about the center four grip pin pads purpose and no real final results, would you mind explaining your intention?

Yeah, the developers behind SPT have found the very interesting ability to throw the camera into Service Mode over the USB port which allows the camera to boot even while major circuit boards/LCD screens are missing/disconnected.  Additionally the ability to disable the flash via software so you can work on the internals without the capacitors charged, definitely something that would be nice even just so you don't shock yourself like a stun gun if you accidentally touch the contacts (taught myself the hard way about a year ago when I had to fix the viewfinder in my camera).
@ToniX: Had the same issue with several java and web apps after setting item size to 150 (W7) at the company. Thought giving users with not so optimal vision something good. Had to revert it because of login screen troubles and such like.

Windows, application GUIs and high dpi monitors ... <sigh>.

I post it tomorrow, no time this evening.


So with this learning, one could skip the steps of mlv - converting to a Log image -> corrections - grade - final look? I guess i am asking could the A.I take an MLV - "fake all the steps" - final look? Too complex? Further more, is this perhaps what fhe future of post processing looks like? And it eventually sends robots back in time ;)


I also think it is a Windows font setting. If Windows overrides our font settings, the fonts may be to big for the GUI. We had the same problem on Linux. If fonts are system standard all should be fine.

@masc,  I saw your comment just now. Pardon
 It is certainly a problem caused by windows, known and annoying ..The default settings are too small, so I switched to "BIG" (or Large),  while sizes of specific items (menu, icons, etc) are set  between 9-11 .... ::)
Pages: [1] 2 3 ... 10