Hi,
I just joined the group and I'm planning on hacking on the 550d/Atomos Ninja combination to see how far I can take it.
Has anyone experimented with this yet?
What little I know or suspect is the following:
1. Atomos can do 10-bit/channel recording (30 bits / pixel) in 1080i/60 which is how 1080p/24 is encoded in 3:2 pulldown.
2. 550d HDMI live view streams use 8-bit 1440 x 1080 which is embedded within black borders. (Not sure if this is the resolution which feeds to both HDMI stream and H264 recording, or is particular to live view. I would guess its a limitation imposed because of limited encoding bandwidth -- need more info)
3. I don't know if HDMI output includes the pixel binning results or if its a raw sensor crop.
In any case, if possible I'm prepared to hack any parameters or do special stream processing to:
1. Increase HDMI res to full 1920 x 1080
2. Increase pixel depth to 10-bit.
3. Write any C/Lua code to enable this.
If anyone could point to a decent block diagram of the dataflow and stream processing between the image capture / monitoring and recording functional units in the 550 it would be an excellent aid while browsing the source code.
Thanks
Erisian
On Thu, Apr 12, 2012 at 7:01 PM, Jim Burnes <jvbu...@gmail.com> wrote:
> Hi,
>
> I just joined the group and I'm planning on hacking on the 550d/Atomos Ninja
> combination to see how far I can take it.
>
> Has anyone experimented with this yet?
>
> What little I know or suspect is the following:
>
> 1. Atomos can do 10-bit/channel recording (30 bits / pixel) in 1080i/60
> which is how 1080p/24 is encoded in 3:2 pulldown.
>
> 2. 550d HDMI live view streams use 8-bit 1440 x 1080 which is embedded
> within black borders. (Not sure if this is the resolution which feeds to
> both HDMI stream and H264 recording, or is particular to live view. I would
> guess its a limitation imposed because of limited encoding bandwidth -- need
> more info)
>
> 3. I don't know if HDMI output includes the pixel binning results or if its
> a raw sensor crop.
The raw data sent to HDMI can be found by taking a screenshot in ML
(it's a 422 file). It's not raw. I believe it's downsampled a bit.
The native resolution (at which the sensor seems to be sampled while
recording) can be found here:
https://bitbucket.org/hudson/magic-lantern/src/tip/src/vram.c#cl-179
> In any case, if possible I'm prepared to hack any parameters or do special
> stream processing to:
>
> 1. Increase HDMI res to full 1920 x 1080
See our notes here:
http://magiclantern.wikia.com/wiki/Register_Map
Hint: try to understand how the firmware resizes the black bars when
you press DISP/INFO.
Probably the easiest way is to configure the display device (C0F14xxx)
to resize the image data to fit the screen (but this will not improve
the actual resolution, just upscale the image).
> 2. Increase pixel depth to 10-bit.
I don't think it's possible. You need to change the code running on
the image processing chip (so-called DIGIC).
> 3. Write any C/Lua code to enable this.
>
> If anyone could point to a decent block diagram of the dataflow and stream
> processing between the image capture / monitoring and recording functional
> units in the 550 it would be an excellent aid while browsing the source
> code.
My best guess about this would be:
- sample raw data from sensor (14-bit) - somewhere inside DIGIC
- apply a simple linear transformation (black and white levels, as in
"dcraw -k black_level -S white_level")
- convert data to 12 bits (hints: 14_12 strings in the firmware, and
the dynamic range in movie mode compared to photo raws)
- apply curves, gamma, picture styles, etc
- at this point we have 8-bit 422 data available in image buffers
(these buffers are visible from the general-purpose CPU)
From here, we have LiveView data going to:
1) display device (so-called LV image buffer)
2) recorded video (so-called HD image buffer); this is active in
standby too, but usually at lower resolution.
See http://magiclantern.wikia.com/wiki/VRAM/Geometry for more info
about these buffers.
I believe one of those buffers is downsampled for the other (usually,
HD contains non-resized data, while LV contains resized data). On HDMI
1080, it may be the opposite.
Also, I believe the HD buffer is passed directly to H.264 engine
(which configured via C0E0xxxx registers), and the H.264 module also
upsamples the data to 1080p and converts it to YUV420.
> Thanks
>
> Erisian
>
> --
> http://magiclantern.wikia.com/
>
> To post to this group, send email to ml-d...@googlegroups.com
> To unsubscribe from this group, send email to
> ml-devel+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/ml-devel?hl=en
Perfect, Alex. Exactly what I needed to get started.
One thing I'm trying to get my head around. How does a 550d stream video data to the HDMI port? Do you set certain registers and it auto-streams YUV buffers or do you have to intentionally do a DMA into the HDMI output buffer every 1/60th of a second?
One last thing: I thought I saw someone on a forum (dvxuser) say that if you disable audio monitoring you can get full 1920 HDMI out. He was referencing experimental builds made by some guy 'a1ex'. Is that you? I don't need audio since I do all of my recording with external mic/recorder.
Jim Burnes
If you write to the YUV buffer, the data appears on the screen (that's
how magic zoom works). I believe the buffer region can be read
directly by the display device.
The buffer includes the black bars - if you write valid image data
there, it will appear on the screen.
For DMA usage, look in the vectorscope patch from g3gg0 (somewhere on
this mailing list). Also this may be useful:
http://magiclantern.wikia.com/wiki/Register_Map/60D#Unsorted
especially 0xC0F04308.
> One last thing: I thought I saw someone on a forum (dvxuser) say that if you
> disable audio monitoring you can get full 1920 HDMI out. He was referencing
> experimental builds made by some guy 'a1ex'. Is that you? I don't need
> audio since I do all of my recording with external mic/recorder.
Audio monitoring has nothing to do with HDMI.
On Wed, Apr 18, 2012 at 5:48 AM, Jim Burnes <jvbu...@gmail.com> wrote:If you write to the YUV buffer, the data appears on the screen (that's
> Perfect, Alex. Exactly what I needed to get started.
>
> One thing I'm trying to get my head around. How does a 550d stream video
> data to the HDMI port? Do you set certain registers and it auto-streams YUV
> buffers or do you have to intentionally do a DMA into the HDMI output buffer
> every 1/60th of a second?
how magic zoom works). I believe the buffer region can be read
directly by the display device.
The buffer includes the black bars - if you write valid image data
there, it will appear on the screen.
For DMA usage, look in the vectorscope patch from g3gg0 (somewhere on
this mailing list). Also this may be useful:
http://magiclantern.wikia.com/wiki/Register_Map/60D#Unsorted
especially 0xC0F04308.
Audio monitoring has nothing to do with HDMI.
> One last thing: I thought I saw someone on a forum (dvxuser) say that if you
> disable audio monitoring you can get full 1920 HDMI out. He was referencing
> experimental builds made by some guy 'a1ex'. Is that you? I don't need
> audio since I do all of my recording with external mic/recorder.