If anybody is interested in using an FPGA to explore deep in the bowels of HDMI you might be interested in my new GitHub Repo.
https://github.com/hamsternz/Artix-7-HDMI-processing
It is HDMI 1080p RX and decode, audio extraction and then sending the video back out as DVI-D, but with 8 channel audio level meters that are blended into the top left corner of the video - the simplest project I could think of to show end-to-end functionality.
It is a bit rough at the moment, but should get better as I fix up a few known issues (f.e. the meters double in height for 1080i inputs).
Features
--------
Supports HDMI input formats:
-720p@50
- 720p@60,
- 1080i (with a bug in the meters)
- 1080p@50
- 1080p@60
and others....
Colourspaces / formats supported:
- RGB 444
- YCbCr 444
- YCbCr 422
Supported Boards
- Digilent Nexys Video (Artix 7 200T)
Sources tested with:
- Western Digital HD Live
- HP Laptop
- Cubieboard
Sinks tested with:
- Viewsonic Monitor - HDMI input
- AOC Monitor DVI-D input
- Vivo TV - HDMI input
Hi DiyAudio, here is a short, supper jerky, short cellphone video....
Thanks this looks great man, you should make a video series explaining this project, their seems to be is a serious lack of "good quality" FPGA educational videos, only fragmented knowledge.
.... we shift one bit per cycle into these two 16-bit shift registers, and two bits per cycle into this other 32-bit shift register.
If the first 16-bit register is 0xFFFE, and the second has 0x0282 in the lowest 8 bits, I then pick these four bits seemingly random bits out of 32-bit shift register, and then use them to set the output signals.Code: [Select]architecture Behavioral of extract_video_infopacket_data is
-- For this usage, we are only interested in four bits that are all in the first
-- 16 transfers of the 32-bit packets
signal header_bits : STD_LOGIC_VECTOR (15 downto 0);
signal frame_bits : STD_LOGIC_VECTOR (15 downto 0);
signal subpacket0_bits : STD_LOGIC_VECTOR (31 downto 0);
signal updated : std_logic := '0';
begin
process(clk)
begin
if rising_edge(clk) then
if adp_data_valid = '1' then
-----------------------------------------------
-- Move the incoming bits into a shift register
-----------------------------------------------
header_bits <= adp_header_bit & header_bits(header_bits'high downto 1);
frame_bits <= adp_frame_bit & frame_bits(frame_bits'high downto 1);
subpacket0_bits <= adp_subpacket0_bits & subpacket0_bits(subpacket0_bits'high downto 2);
updated <= '1';
end if;
----------------------------------------------------
-- The 0 in frame bits indicates the start of packet
----------------------------------------------------
if updated = '1' and frame_bits = x"FFFE" then
-- 82 is the type of packet, 02 is the version
if header_bits = x"0282" then
case subpacket0_bits(14 downto 13) is
when "00" => input_is_YCbCr <= '0'; input_is_422 <= '0';
when "01" => input_is_YCbCr <= '1'; input_is_422 <= '1';
when "10" => input_is_YCbCr <= '1'; input_is_422 <= '0';
when others => NULL;
end case;
case subpacket0_bits(27 downto 26) is
when "01" => input_is_sRGB <= '1';
when others => input_is_sRGB <= '0';
end case;
end if;
end if;
end if;
end process;
end Behavioral;
Cool, that is a lot of work. You have an hdmi analyzer?
I would be quite keen on doing a video, but I hate the sound of my own voice. Do I really sound like that? Sheesh!
I would be quite keen on doing a video, but I hate the sound of my own voice. Do I really sound like that? Sheesh!
Cool, that is a lot of work. You have an hdmi analyzer?
Oh, I've now added 'rule of thirds' guidelines too...
Have you used one? I have seen that kevtris has one and used it to validate his HDMI Nes project. It would be very nice to see an open source HDMI-compliant example, it feels like analyzers are so niche and $$$ that it hampers a lot of fun potential projects.
Cool, that is a lot of work. You have an hdmi analyzer?
Have you used one? I have seen that kevtris has one and used it to validate his HDMI Nes project. It would be very nice to see an open source HDMI-compliant example, it feels like analyzers are so niche and $$$ that it hampers a lot of fun potential projects.
Cool, that is a lot of work. You have an hdmi analyzer?
Have you used one? I have seen that kevtris has one and used it to validate his HDMI Nes project. It would be very nice to see an open source HDMI-compliant example, it feels like analyzers are so niche and $$$ that it hampers a lot of fun potential projects.
Actually I will be using his this weekend I convinced him to do a teardown a while back, there's a video if you haven't seen it.
Last night I extended the project to do Sobel-like edge detection:
The threshold is a little bit high at the moment so I'll fix that and get rid of the artefacts at the edges of the screen...
Just a quick question....should hdmi tx generate a signal when there is no input at the rx side?
Or di I need to connect SDA/SCL on the tx side as well?
[Place 30-149] Unroutable Placement! A MMCM / (BUFIO/BUFR) component pair is not placed in a routable site pair. The MMCM component can use the dedicated path between the MMCM and the (BUFIO/BUFR) if both are placed in the same clock region or if they are placed in horizontally adjacent clock regions. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
< set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets i_hdmi_io/i_hdmi_input/clk_pixel_x5_raw] >
[DRC PDRC-34] MMCM_adv_ClkFrequency_div_no_dclk: The computed value 371.195 MHz (CLKIN1_PERIOD, net tmds_in_clk) for the VCO operating frequency of the MMCME2_ADV site MMCME2_ADV_X0Y1 (cell i_hdmi_io/i_hdmi_input/hdmi_MMCME2_BASE_inst) falls outside the operating range of the MMCM VCO frequency for this device (600.000 - 1200.000 MHz). The computed value is (CLKFBOUT_MULT_F * 1000 / (CLKINx_PERIOD * DIVCLK_DIVIDE)). Please run update_timing to update the MMCM settings. If that does not work, adjust either the input period CLKINx_PERIOD (13.470000), multiplication factor CLKFBOUT_MULT_F (5.000000) or the division factor DIVCLK_DIVIDE (1), in order to achieve a VCO frequency within the rated operating range for this device.
Well done!
I would be quite keen on doing a video, but I hate the sound of my own voice. Do I really sound like that? Sheesh!I thought why I don't like my voice recorded:
Usually, you hear your own voice mostly through your bones which have another Frequency response, so when you hear your real voice it differs and it makes you angry. It's not a problem for other people - your voice is most likely OK for them because they don't have any preprogrammed anticipations about it.