3dbrew - User contributions [en]

NWMINF:ConnectToEncryptedAP

2025-08-22T13:32:57Z

2670QM: Added AP channel

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00070742]
|-
| 1-8
| SSID
|-
| 9
| SSID length
|-
| 10-11
| 6-byte AP MAC address
|-
| 12
| AP channel
|-
| 13-29
| 0x44-byte encryption structure
|-
| 30
| Value 0x0
|-
| 31
| Event handle. This is probably signaled once the system finishes connecting to the AP?
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Encryption structure=
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| ?
|-
| 0x1
| 0x1
| ?
|-
| 0x2
| 0x1
| ?
|-
| 0x3
| 0x1
| ?
|-
| 0x4
| 0x20
| This is the WPA PSK / network encryption key.
|-
| 0x24
| 0x20
| Usually zero.
|}

NWMINF:ConnectToAP

2025-08-22T13:32:33Z

2670QM: Added AP channel

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x0008....]
|-
| 1-8
| SSID
|-
| 9
| SSID length
|-
| 10-11
| 6-byte AP MAC address
|-
| 12
| AP channel
|-
| 13
| ?
|-
| 14
| Event handle. This is probably signaled once the system finishes connecting to the AP?
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Calls same code as [[NWMINF:ConnectToEncryptedAP]] but with an all-zero encryption struct.

MVDSTD:CalculateWorkBufSize

2025-04-03T10:35:19Z

2670QM:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 00
| Header code [0x00030300]
|-
| 01-03
| CalculateWorkBufSizeConfig
|-
| 04-10
| ???????????????
|-
| 11
| u32 Video width
|-
| 12
| u32 Video height
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Resultcode
|}

=Description=
==CalculateWorkBufSizeConfig==
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| Unused
|-
| 0x01-0x04
| CalculateWorkBufWithLevel
|-
| 0x05-0x06
| CalculateWorkBufWithNumOfRefFramesA
|-
| 0x07-0x08
| CalculateWorkBufWithNumOfRefFramesB
|-
| 0x09-0x11
| Unused
|}

===CalculateWorkBufWithLevel===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Flag
|-
| 0x02
| bool Double size
|-
| 0x03
| u8 H.264 level
|}

====Flag====
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0x00
| FLAG_NONE
|-
| 0x01
| FLAG_ENABLE_CALCULATION
|-
| 0x02
| FLAG_ENABLE_EXTRA_OP (see below)
|-
| 0x04
| FLAG_UNK
|}

====H.264 level====
{| class="wikitable" border="1"
|-
! Index
! Description
|-
| 0x00
| Level 1.0
|-
| 0x01
| Level 1.0b
|-
| 0x02
| Level 1.1
|-
| 0x03
| Level 1.2
|-
| 0x04
| Level 1.3
|-
| 0x05
| Level 2.0
|-
| 0x06
| Level 2.1
|-
| 0x07
| Level 2.2
|-
| 0x08
| Level 3.0
|-
| 0x09
| Level 3.1
|-
| 0x0A
| Level 3.2
|-
| 0x0B
| Level 4.0
|-
| 0x0C
| Level 4.1
|-
| 0x0D
| Level 4.2
|-
| 0x0E
| Level 5.0
|-
| 0x0F
| Level 5.1
|-
| 0x10
| Level 5.2
|}

This will calculate maximum possible buffer size (==buffer size that '''''may''''' be needed to decode video) based on H.264 level and resolution, <s>so any videos that are compliant with H.264 specs should be decoded with this buffer size</s> '''''it seems there is some buffer overflow (some hundreds bytes according to test) when maximum number of reference frames are used''''', so adding some extra bytes (maybe around 4096Bytes is enough) is safer.

Calculation procedures are :
* Calculate '''max_reference_frames''' based on '''H.264 level''' and '''resolution''', 0x10 is used if '''max_reference_frames''' is greater than 0x10.
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''(max_reference_frames + 1)''' to get '''temp_buffer_size'''
* If FLAG_ENABLE_EXTRA_OP is set, '''temp_buffer_size += (temp_buffer_size / 6)'''
* If double size (offset 0x02) is set, '''temp_buffer_size *= 2'''
* Finally, '''temp_buffer_size += 0xFC8'''

To perform calculation, enable calculation (ofset 0x00) '''''and''''' flag (offset 0x01) must be non-zero, otherwise 0 is returned.

If resolution is too high for given H.264 level, 0 is returned.

Attempting to use more than 0x10 for H.264 level (offset 0x03) will likely cause out-of-bound access.

===CalculateWorkBufWithNumOfRefFramesA/B===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Number of reference frames
|}

This will calculate buffer size based on resolution and number of reference frames.

Calculation procedures are :
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''number_of_reference_frames''' to get '''temp_buffer_size'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''A''', '''temp_buffer_size += 0x10800'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''B''', '''temp_buffer_size += 0x858'''

To perform calculation, enable calculation (ofset 0x00) must be non-zero, otherwise 0 is returned.

If number of reference frames (offset 0x01) is less than 0x02, 0x02 is used internally, if it's greater than 0x10, 0x10 is used internally.

----

It is possible to enable more than 1 calculation methods simultaneously, in that case the largest buffer size among them is returned.

SKATER uses

<nowiki>
cmd.CalculateWorkBufWithLevel.enable = 0x01;
cmd.CalculateWorkBufWithLevel.flag = 0x07; //(FLAG_ENABLE_CALCULATION | FLAG_ENABLE_EXTRA_OP | FLAG_UNK).
cmd.CalculateWorkBufWithLevel.doubleSize = 0x00;
cmd.CalculateWorkBufWithLevel.level = 0x0A; //Level 3.2.
cmd.CalculateWorkBufWithNumOfRefFramesA.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesA.numOfReferenceFrames = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.numOfReferenceFrames = 0x00;
cmd.width = 854; //Regardless of input video, 854 is always used.
cmd.height = 480; //Regardless of input video, 480 is always used.
</nowiki>

and result is '''9438920Bytes''' (0x9006C8), aka MVD_DEFAULT_WORKBUF_SIZE.

This doesn't write to MVD state / registers at all.

MVDSTD:CalculateWorkBufSize

2025-04-02T09:54:31Z

2670QM:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 00
| Header code [0x00030300]
|-
| 01-03
| CalculateWorkBufSizeConfig
|-
| 04-10
| ???????????????
|-
| 11
| u32 Video width
|-
| 12
| u32 Video height
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Resultcode
|}

=Description=
==CalculateWorkBufSizeConfig==
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| Unused
|-
| 0x01-0x04
| CalculateWorkBufWithLevel
|-
| 0x05-0x06
| CalculateWorkBufWithNumOfRefFramesA
|-
| 0x07-0x08
| CalculateWorkBufWithNumOfRefFramesB
|-
| 0x09-0x11
| Unused
|}

===CalculateWorkBufWithLevel===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Flag
|-
| 0x02
| bool Double size
|-
| 0x03
| u8 H.264 level
|}

====Flag====
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0x00
| FLAG_NONE
|-
| 0x01
| FLAG_ENABLE_CALCULATION
|-
| 0x02
| FLAG_ENABLE_EXTRA_OP (see below)
|-
| 0x03
| FLAG_UNK
|}

====H.264 level====
{| class="wikitable" border="1"
|-
! Index
! Description
|-
| 0x00
| Level 1.0
|-
| 0x01
| Level 1.0b
|-
| 0x02
| Level 1.1
|-
| 0x03
| Level 1.2
|-
| 0x04
| Level 1.3
|-
| 0x05
| Level 2.0
|-
| 0x06
| Level 2.1
|-
| 0x07
| Level 2.2
|-
| 0x08
| Level 3.0
|-
| 0x09
| Level 3.1
|-
| 0x0A
| Level 3.2
|-
| 0x0B
| Level 4.0
|-
| 0x0C
| Level 4.1
|-
| 0x0D
| Level 4.2
|-
| 0x0E
| Level 5.0
|-
| 0x0F
| Level 5.1
|-
| 0x10
| Level 5.2
|}

This will calculate maximum possible buffer size (==buffer size that '''''may''''' be needed to decode video) based on H.264 level and resolution, <s>so any videos that are compliant with H.264 specs should be decoded with this buffer size</s> '''''it seems there is some buffer overflow (some hundreds bytes according to test) when maximum number of reference frames are used''''', so adding some extra bytes (maybe around 4096Bytes is enough) is safer.

Calculation procedures are :
* Calculate '''max_reference_frames''' based on '''H.264 level''' and '''resolution''', 0x10 is used if '''max_reference_frames''' is greater than 0x10.
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''(max_reference_frames + 1)''' to get '''temp_buffer_size'''
* If FLAG_ENABLE_EXTRA_OP is set, '''temp_buffer_size += (temp_buffer_size / 6)'''
* If double size (offset 0x02) is set, '''temp_buffer_size *= 2'''
* Finally, '''temp_buffer_size += 0xFC8'''

To perform calculation, enable calculation (ofset 0x00) '''''and''''' flag (offset 0x01) must be non-zero, otherwise 0 is returned.

If resolution is too high for given H.264 level, 0 is returned.

Attempting to use more than 0x10 for H.264 level (offset 0x03) will likely cause out-of-bound access.

===CalculateWorkBufWithNumOfRefFramesA/B===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Number of reference frames
|}

This will calculate buffer size based on resolution and number of reference frames.

Calculation procedures are :
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''number_of_reference_frames''' to get '''temp_buffer_size'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''A''', '''temp_buffer_size += 0x10800'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''B''', '''temp_buffer_size += 0x858'''

To perform calculation, enable calculation (ofset 0x00) must be non-zero, otherwise 0 is returned.

If number of reference frames (offset 0x01) is less than 0x02, 0x02 is used internally, if it's greater than 0x10, 0x10 is used internally.

----

It is possible to enable more than 1 calculation methods simultaneously, in that case the largest buffer size among them is returned.

SKATER uses

<nowiki>
cmd.CalculateWorkBufWithLevel.enable = 0x01;
cmd.CalculateWorkBufWithLevel.flag = 0x07; //(FLAG_ENABLE_CALCULATION | FLAG_ENABLE_EXTRA_OP | FLAG_UNK).
cmd.CalculateWorkBufWithLevel.doubleSize = 0x00;
cmd.CalculateWorkBufWithLevel.level = 0x0A; //Level 3.2.
cmd.CalculateWorkBufWithNumOfRefFramesA.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesA.numOfReferenceFrames = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.numOfReferenceFrames = 0x00;
cmd.width = 854; //Regardless of input video, 854 is always used.
cmd.height = 480; //Regardless of input video, 480 is always used.
</nowiki>

and result is '''9438920Bytes''' (0x9006C8), aka MVD_DEFAULT_WORKBUF_SIZE.

This doesn't write to MVD state / registers at all.

MVDSTD:CalculateWorkBufSize

2025-04-02T09:52:36Z

2670QM: Fixed wrong description

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 00
| Header code [0x00030300]
|-
| 01-03
| CalculateWorkBufSizeConfig
|-
| 04-10
| ???????????????
|-
| 11
| u32 Video width
|-
| 12
| u32 Video height
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Resultcode
|}

=Description=
==CalculateWorkBufSizeConfig==
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| Unused
|-
| 0x01-0x04
| CalculateWorkBufWithLevel
|-
| 0x05-0x06
| CalculateWorkBufWithNumOfRefFramesA
|-
| 0x07-0x08
| CalculateWorkBufWithNumOfRefFramesB
|-
| 0x09-0x11
| Unused
|}

===CalculateWorkBufWithLevel===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Flag
|-
| 0x02
| bool Double size
|-
| 0x03
| u8 H.264 level
|}

====Flag====
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0x00
| FLAG_NONE
|-
| 0x01
| FLAG_ENABLE_CALCULATION
|-
| 0x02
| FLAG_ENABLE_EXTRA_OP (see below)
|-
| 0x03
| FLAG_UNK
|}

====H.264 level====
{| class="wikitable" border="1"
|-
! Index
! Description
|-
| 0x00
| Level 1.0
|-
| 0x01
| Level 1.0b
|-
| 0x02
| Level 1.1
|-
| 0x03
| Level 1.2
|-
| 0x04
| Level 1.3
|-
| 0x05
| Level 2.0
|-
| 0x06
| Level 2.1
|-
| 0x07
| Level 2.2
|-
| 0x08
| Level 3.0
|-
| 0x09
| Level 3.1
|-
| 0x0A
| Level 3.2
|-
| 0x0B
| Level 4.0
|-
| 0x0C
| Level 4.1
|-
| 0x0D
| Level 4.2
|-
| 0x0E
| Level 5.0
|-
| 0x0F
| Level 5.1
|-
| 0x10
| Level 5.2
|}

This will calculate maximum possible buffer size (==buffer size that '''''may''''' be needed to decode video) based on H.264 level and resolution, <s>so any videos that are compliant with H.264 specs should be decoded with this buffer size</s> '''''it seems there is some buffer overflow (some hundreds bytes according to test) when maximum number of reference frames are used''''', so adding some extra bytes (maybe around 4K is enough) is safer.

Calculation procedures are :
* Calculate '''max_reference_frames''' based on '''H.264 level''' and '''resolution''', 0x10 is used if '''max_reference_frames''' is greater than 0x10.
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''(max_reference_frames + 1)''' to get '''temp_buffer_size'''
* If FLAG_ENABLE_EXTRA_OP is set, '''temp_buffer_size += (temp_buffer_size / 6)'''
* If double size (offset 0x02) is set, '''temp_buffer_size *= 2'''
* Finally, '''temp_buffer_size += 0xFC8'''

To perform calculation, enable calculation (ofset 0x00) '''''and''''' flag (offset 0x01) must be non-zero, otherwise 0 is returned.

If resolution is too high for given H.264 level, 0 is returned.

Attempting to use more than 0x10 for H.264 level (offset 0x03) will likely cause out-of-bound access.

===CalculateWorkBufWithNumOfRefFramesA/B===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Number of reference frames
|}

This will calculate buffer size based on resolution and number of reference frames.

Calculation procedures are :
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''number_of_reference_frames''' to get '''temp_buffer_size'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''A''', '''temp_buffer_size += 0x10800'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''B''', '''temp_buffer_size += 0x858'''

To perform calculation, enable calculation (ofset 0x00) must be non-zero, otherwise 0 is returned.

If number of reference frames (offset 0x01) is less than 0x02, 0x02 is used internally, if it's greater than 0x10, 0x10 is used internally.

----

It is possible to enable more than 1 calculation methods simultaneously, in that case the largest buffer size among them is returned.

SKATER uses

<nowiki>
cmd.CalculateWorkBufWithLevel.enable = 0x01;
cmd.CalculateWorkBufWithLevel.flag = 0x07; //(FLAG_ENABLE_CALCULATION | FLAG_ENABLE_EXTRA_OP | FLAG_UNK).
cmd.CalculateWorkBufWithLevel.doubleSize = 0x00;
cmd.CalculateWorkBufWithLevel.level = 0x0A; //Level 3.2.
cmd.CalculateWorkBufWithNumOfRefFramesA.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesA.numOfReferenceFrames = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.numOfReferenceFrames = 0x00;
cmd.width = 854; //Regardless of input video, 854 is always used.
cmd.height = 480; //Regardless of input video, 480 is always used.
</nowiki>

and result is '''9438920Bytes''' (0x9006C8), aka MVD_DEFAULT_WORKBUF_SIZE.

This doesn't write to MVD state / registers at all.

MVDSTD:CalculateWorkBufSize

2025-04-01T11:43:31Z

2670QM:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 00
| Header code [0x00030300]
|-
| 01-03
| CalculateWorkBufSizeConfig
|-
| 04-10
| ???????????????
|-
| 11
| u32 Video width
|-
| 12
| u32 Video height
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Resultcode
|}

=Description=
==CalculateWorkBufSizeConfig==
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| Unused
|-
| 0x01-0x04
| CalculateWorkBufWithLevel
|-
| 0x05-0x06
| CalculateWorkBufWithNumOfRefFramesA
|-
| 0x07-0x08
| CalculateWorkBufWithNumOfRefFramesB
|-
| 0x09-0x11
| Unused
|}

===CalculateWorkBufWithLevel===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Flag
|-
| 0x02
| bool Double size
|-
| 0x03
| u8 H.264 level
|}

====Flag====
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0x00
| FLAG_NONE
|-
| 0x01
| FLAG_ENABLE_CALCULATION
|-
| 0x02
| FLAG_ENABLE_EXTRA_OP (see below)
|-
| 0x03
| FLAG_UNK
|}

====H.264 level====
{| class="wikitable" border="1"
|-
! Index
! Description
|-
| 0x00
| Level 1.0
|-
| 0x01
| Level 1.0b
|-
| 0x02
| Level 1.1
|-
| 0x03
| Level 1.2
|-
| 0x04
| Level 1.3
|-
| 0x05
| Level 2.0
|-
| 0x06
| Level 2.1
|-
| 0x07
| Level 2.2
|-
| 0x08
| Level 3.0
|-
| 0x09
| Level 3.1
|-
| 0x0A
| Level 3.2
|-
| 0x0B
| Level 4.0
|-
| 0x0C
| Level 4.1
|-
| 0x0D
| Level 4.2
|-
| 0x0E
| Level 5.0
|-
| 0x0F
| Level 5.1
|-
| 0x10
| Level 5.2
|}

This will calculate maximum possible buffer size (==buffer size that '''''may''''' be needed to decode video) based on H.264 level and resolution, so any videos that are compliant with H.264 specs should be decoded with this buffer size.

Calculation procedures are :
* Calculate '''max_reference_frames''' based on '''H.264 level''' and '''resolution''', 0x10 is used if '''max_reference_frames''' is greater than 0x10.
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''(max_reference_frames + 1)''' to get '''temp_buffer_size'''
* If FLAG_ENABLE_EXTRA_OP is set, '''temp_buffer_size += (temp_buffer_size / 6)'''
* If double size (offset 0x02) is set, '''temp_buffer_size *= 2'''
* Finally, '''temp_buffer_size += 0xFC8'''

To perform calculation, enable calculation (ofset 0x00) '''''and''''' flag (offset 0x01) must be non-zero, otherwise 0 is returned.

If resolution is too high for given H.264 level, 0 is returned.

Attempting to use more than 0x10 for H.264 level (offset 0x03) will likely cause out-of-bound access.

===CalculateWorkBufWithNumOfRefFramesA/B===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Number of reference frames
|}

This will calculate buffer size based on resolution and number of reference frames.

Calculation procedures are :
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''number_of_reference_frames''' to get '''temp_buffer_size'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''A''', '''temp_buffer_size += 0x10800'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''B''', '''temp_buffer_size += 0x858'''

To perform calculation, enable calculation (ofset 0x00) must be non-zero, otherwise 0 is returned.

If number of reference frames (offset 0x01) is less than 0x02, 0x02 is used internally, if it's greater than 0x10, 0x10 is used internally.

----

It is possible to enable more than 1 calculation methods simultaneously, in that case the largest buffer size among them is returned.

SKATER uses

<nowiki>
cmd.CalculateWorkBufWithLevel.enable = 0x01;
cmd.CalculateWorkBufWithLevel.flag = 0x07; //(FLAG_ENABLE_CALCULATION | FLAG_ENABLE_EXTRA_OP | FLAG_UNK).
cmd.CalculateWorkBufWithLevel.doubleSize = 0x00;
cmd.CalculateWorkBufWithLevel.level = 0x0A; //Level 3.2.
cmd.CalculateWorkBufWithNumOfRefFramesA.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesA.numOfReferenceFrames = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.numOfReferenceFrames = 0x00;
cmd.width = 854; //Regardless of input video, 854 is always used.
cmd.height = 480; //Regardless of input video, 480 is always used.
</nowiki>

and result is '''9438920Bytes''' (0x9006C8), aka MVD_DEFAULT_WORKBUF_SIZE.

This doesn't write to MVD state / registers at all.

MVDSTD:CalculateWorkBufSize

2025-04-01T11:34:31Z

2670QM: Added command detail.

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 00
| Header code [0x00030300]
|-
| 01-03
| CalculateWorkBufSizeConfig
|-
| 04-10
| ???????????????
|-
| 11
| u32 Video width
|-
| 12
| u32 Video height
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Resultcode
|}

=Description=
==CalculateWorkBufSizeConfig==
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| Unused
|-
| 0x01-0x04
| CalculateWorkBufWithLevel
|-
| 0x05-0x06
| CalculateWorkBufWithNumOfRefFramesA
|-
| 0x07-0x08
| CalculateWorkBufWithNumOfRefFramesB
|-
| 0x09-0x11
| Unused
|}

===CalculateWorkBufWithLevel===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Flag
|-
| 0x02
| bool Double size
|-
| 0x03
| u8 H.264 level
|}

====Flag====
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0x00
| FLAG_NONE
|-
| 0x01
| FLAG_ENABLE_CALCULATION
|-
| 0x02
| FLAG_ENABLE_EXTRA_OP (see below)
|-
| 0x03
| FLAG_UNK
|}

====H.264 level====
{| class="wikitable" border="1"
|-
! Index
! Description
|-
| 0x00
| Level 1.0
|-
| 0x01
| Level 1.0b
|-
| 0x02
| Level 1.1
|-
| 0x03
| Level 1.2
|-
| 0x04
| Level 1.3
|-
| 0x05
| Level 2.0
|-
| 0x06
| Level 2.1
|-
| 0x07
| Level 2.2
|-
| 0x08
| Level 3.0
|-
| 0x09
| Level 3.1
|-
| 0x0A
| Level 3.2
|-
| 0x0B
| Level 4.0
|-
| 0x0C
| Level 4.1
|-
| 0x0D
| Level 4.2
|-
| 0x0E
| Level 5.0
|-
| 0x0F
| Level 5.1
|-
| 0x10
| Level 5.2
|}

This will calculate maximum possible buffer size (==buffer size that '''''may''''' be needed to decode video) based on H.264 level and resolution, so any videos that are compliant with H.264 specs should be decoded with this buffer size.

Calculation procedures are :
* Calculate '''max_reference_frames''' based on '''H.264 level''' and '''resolution''', 0x10 is used if '''max_reference_frames''' is greater than 0x10.
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''(max_reference_frames + 1)''' to get '''temp_buffer_size'''
* If FLAG_ENABLE_EXTRA_OP is set, '''temp_buffer_size += (temp_buffer_size / 6)'''
* If double size (offset 0x02) is set, '''temp_buffer_size *= 2'''
* Finally, '''temp_buffer_size += 0xFC8'''

To perform calculation, enable calculation (ofset 0x00) '''''and''''' flag (offset 0x01) must be non-zero, otherwise 0 is returned.

If resolution is too high for given H.264 level, 0 is returned.

Attempting to use more than 0x10 for H.264 level (offset 0x03) will likely cause out-of-bound access.

===CalculateWorkBufWithNumOfRefFramesA/B===
{| class="wikitable" border="1"
|-
! Offset
! Description
|-
| 0x00
| bool Enable calculation
|-
| 0x01
| u8 Number of reference frames
|}

This will calculate buffer size based on resolution and number of reference frames.

Calculation procedures are :
* Calculate '''frame_size''' based on '''resolution'''.
* Multiply '''frame_size''' and '''number_of_reference_frames''' to get '''temp_buffer_size'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''A''', '''temp_buffer_size += 0x10800'''
* Finally, for CalculateWorkBufWithNumOfRefFrames'''B''', '''temp_buffer_size += 0x858'''

To perform calculation, enable calculation (ofset 0x00) must be non-zero, otherwise 0 is returned.

If number of reference frames (offset 0x01) is less than 0x02, 0x02 is used internally, if it's greater than 0x10, 0x10 is used internally.

It is possible to enable more than 1 calculation methods simultaneously, in that case the biggest buffer size among them is returned.

SKATER uses
```
cmd.CalculateWorkBufWithLevel.enable = 0x01;
cmd.CalculateWorkBufWithLevel.flag = 0x07; //(FLAG_ENABLE_CALCULATION | FLAG_ENABLE_EXTRA_OP | FLAG_UNK).
cmd.CalculateWorkBufWithLevel.doubleSize = 0x00;
cmd.CalculateWorkBufWithLevel.level = 0x0A; //Level 3.2.
cmd.CalculateWorkBufWithNumOfRefFramesA.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesA.numOfReferenceFrames = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.enable = 0x00;
cmd.CalculateWorkBufWithNumOfRefFramesB.numOfReferenceFrames = 0x00;
cmd.width = 854; //Regardless of input video, 854 is always used.
cmd.height = 480; //Regardless of input video, 480 is always used.
```
and result is 9438920Bytes (0x9006C8), aka MVD_DEFAULT_WORKBUF_SIZE.

This doesn't write to MVD state / registers at all.

Hardware

2024-06-18T12:16:09Z

2670QM: Added 2TB SD card test results and boot time vs capacity table.

This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are custom made and are expanded upon here or in other pages.

== Common hardware ==
{| class="wikitable"
! Type !! Description
|-
| ARM11 Processor Core || Old3DS: [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html ARM11 2x MPCore & 2x VFPv2 Co-Processor] 268MHz (268,111,856.0 ± 2-32 Hz, i.e. exactly twice the clock rate of the ARM9).

New3DS: 4x MPCore, 4x VFPv2, able to run up to 804MHz (see below). It also has an optional 2MB L2 cache.
|-
| ARM9 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/index.html ARM946] 134MHz (134,055,927.9 ± 2-32 Hz),
|-
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz,
|-
| VRAM || 6 MB within SoC.
|-
| Top screen || 800x240, with only 400 usable pixels per eye per line.
|-
| Bottom screen || 320x240, with resistive touch overlay.
|-
| DSP || [https://twitter.com/CEVADSP/status/177172880918986752 CEVA TeakLite]. 134Mhz. 24ch 32728Hz sampling rates.
|}

New3DS exclusives are able to clock the CPU at 804MHz, but this appears to be limited to the currently running application/app cores. Timed by running svcGetSystemTick on either side of a long idle loop to stay in the current process context. svcGetSystemTick uses a tick counter running at 268MHz in this mode.

On New3DS: when Home Menu is active, the system runs at 804MHz. For everything else, it's 268MHz, except when the app(let) has the required flag set. See [[NCCH/Extended_Header|here]] and [[PDN_Registers|here]] for details, regarding clock-rate and cache.

For New3DS-only there are multiple clock-rate multiplier values available in [[PDN_Registers|hardware]], but since the relevant code is only implemented in the New3DS ARM11-kernel, the only non-normal clock-rate available with official kernel code is 3x.

== Specifications ==
{| class="wikitable"
! Type !! 3DS !! 3DSXL !! 2DS !! N3DS !! N3DSXL !! N2DSXL
|-
| Model || CTR-001 || SPR-001 || FTR-001 || KTR-001 || RED-001 || JAN-001
|-
| SoC || CPU CTR
|| CPU CTR A
CPU CTR
|| CPU CTR B || CPU LGR A || CPU LGR A || CPU LGR A

|-
| FCRAM || [https://web.archive.org/web/20221022124807/https://www.fujitsu.com/downloads/MICRO/fma/pdf/MB81EDS516545_e511463.pdf 2x64MB Fujitsu MB82M8080-07L] || Fujitsu MB82DBS16641 || Fujitsu MB82DBS1664 || ?? || Fujitsu MB82MK9A9A || Fujitsu MB82MK9A9A
|-
| Top Screen || 3.53 in, 3D || 4.88 in, 3D || 3.53 in cropped from a single panel || 3.88 in, 3D || 4.88 in, 3D || 4.88 in (?)
|-
| Bottom Screen || 3.00 in || 4.18 in || 3.00 in cropped from a single panel || 3.33 in || 4.18 in || 4.18 in (?)
|-
| Storage ||colspan="2"| Toshiba THGBM2G3P1FBAI8 1GB ||colspan="1"| Changed between O3DS and N3DS parts depending on production date ||colspan="2"| Samsung KLM4G1YEQC 4GB (in 1.3GiB SLC mode) or Toshiba THGBMBG4P1KBAIT 2GB (MLC, approx. 1.8GiB usable) ||colspan="1"| Samsung KLM4G1FEPD 4GB
|-
| Speaker, Microphone, Circlepad, Touch controller || TI PAIC3010B 0AA37DW || ?? || ?? || TI AIC3010B 39C4ETW || TI AIC3010D 48C01JW || ??
|-
| Gyroscope || [https://www.sparkfun.com/datasheets/Sensors/Gyro/PS-ITG-3200-00-01.4.pdf Invensense ITG-3270 MEMS Gyroscope] || ?? || ?? || ?? || ?? || ??
|-
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || ?? || ?? || ?? || ?? || ??
|-
| Infrared IC || NXP S750 0803 TSD031C || ?? || ?? || ?? || NXP S750 1603 TSD438C || NXP S750 0210 TSD651C
|-
| Custom Microcontroller || Renesas UC CTR || ?? || Renesas UC CTR 324KM47 KG10 || Renesas UC KTR || Renesas UC KTR 442KM13 TK14 || ??
|-
| PMIC? || TI 93045A4 OAAH86W || ?? || ?? || TI 93045A4 38A6TYW G2 || TI 93045A4 49AF3NW G2 || TI 93045A4 72ASRHW G2
|-
| Charging IC ||colspan="6"| CKP TI [http://www.ti.com/lit/ds/symlink/bq24072.pdf BQ24072]
|-
| Wifi || Atheros AR6014 || ?? || ?? || ?? || Atheros AR6014G-AL1C || ??
|-
| Wifi SPI Flash
| Raw ID data: 20 58 || ?? || ?? || Raw ID data: 62 62 || ?? || ??
|}

* [11] Official Documentation

* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):

* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).

* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].

* [12] This IC is somewhat similar to [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html this].

* The Raw ID data for Wifi SPI Flash is from command 0x9F, RDID.

== FCRAM ==

There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.

The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.

== SoC ==

The 3DS has much of it's internals housed in a SoC (System on Chip) just like it's predecessors. This is done to reduce build costs, cut down on power consumption, as well as make the PCB layout less complex and make the system harder to tamper with. The SoC, branded as the Nintendo 1048 0H, contains the CPU, GPU, DSP and VRAM.

According to official documents, the CPU used is a dual-core ARM11 CPU, clocked at 268MHz. One core is dedicated to system software, while the other is used for application programming, each known as the syscore and appcore, respectively.

== GPU ==

Designed by Digital Media Professionals Inc. (DMP) and codenamed PICA200, 268Mhz.

Block diagram of an ULTRAY2000 based architecture PICA200:

[[File:Pica200BlockDiagram.png]]

PICA200 is compatible with OpenGL ES 1.1. It furthermore provides unique functionality for:
* Per-fragment lighting ("Lighting Maestro")
* Hard- and soft-shadowing ("Shadow Maestro")
* Polygon subdivision ("Figure Maestro")
* Bump mapping and procedural textures ("Mapping Maestro")
* Rendering of gaseous objects ("Particle Maestro")

Some parts of the extended functionality are provided in hardware by an extended geometry pipeline. Most importantly, PICA200 has three programmable vertex processors. There is furthermore a unit called [[GPU/Primitive_Engine|Primitive Engine]], which is a geometry shader unit (using the same instruction set as vertex shaders) with support for variable-size primitives. The Primitive Engine functionality may be disabled, and the geometry shader unit then acts as a fourth vertex processor. See [[Shader_Instruction_Set]] for more information on the shader instruction set.

[[GPU/Fragment Lighting|Fragment lighting]] is implemented as an optional pipeline step during pixel processing. It's implemented by having the vertex shader output an additional attribute describing the transformation (represented by a quaternion) to surface-local space. This per-vertex quaternion can then be interpolated across screen space to calculate dot products relevant for lighting (e.g. light vector dot normal vector). To provide support for advanced lighting models, these dot products are used as indices into programmable lookup tables. With this setup, PICA200 in particular supports the shading models Blinn-Phong, Cook-Terrance, Ward, and microfacet-based BRDF-models.

PICA200 supports four texture units, the fourth of which is used exclusively for [[GPU/Procedural Texture Generation|procedural texture generation]].

== SDIO controller ==

Nintendo recommends SD cards up to 32 GB. The internal SDIO controller seems to support SD cards up to 2.199 Terabyte (32-bit sector number). Up to 2TB (AGI TF138) has been tested and works, however larger SD sizes increase system boot time. The larger the SD capacity, the greater the bootup slowdown. 64-128GB tends to be the sweet spot for most users, with only an extra 0.5-1.0 seconds added to boot time as the tradeoff for the larger size.

SD cards should be formatted FAT32 with a 64KB unit size for maximum compatibility.

[[File:Gm9_2tb_sd.png]]
[[File:Ftpd_2tb_sd.png]]

{| class="wikitable"
! Capacity !! Boot time (NEW2DS) !! Boot time (OLD3DS)
|-
| No SD cards || 7 seconds || 8 seconds
|-
| 16GB || 10 seconds || 11 seconds
|-
| 64GB || 12 seconds || 11 seconds
|-
| 256GB || 19 seconds || 20 seconds
|-
| 2TB || 60 seconds || 60 seconds
|}

* Tests were made on NEW2DS 11.16.0.49J and OLD3DS 11.15.0.47J.
* Boot time is the time until you see the home menu (software icons are still loading) after pressing power button.

== Images ==

=== Front ===

[[Image:CTR_Front.jpg|600px]]

[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]

=== Back ===

[[Image:CTR_Back.jpg]]

[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]

=== NAND pinout ===

NAND dumping has been successful, but the image is encrypted.

==== Normal model ====

[[Image:CTR_NAND_pinout.png]]

==== XL model ====

[[Image:CTR_NAND_pinout_XL.jpg|500px]]

==== 2DS ====

[[Image:2DSeMMC.jpg|500px]]

==== New 3DS ====

[[Image:N3DSeMMC.jpg]]

==== New 3DS XL ====

[[Image:N3DSXLeMMC.jpg]]

=== WiFi dongle pinout ===
[[Image:CTR_WiFiDongle_pinout.png|600px]]

SDIO interface is colored red:
* CLK
* CMD
* D0, D1, D2, D3

This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.

The proprietary DS-mode WiFi is colored yellow, pins are unknown.

I²C eeprom is colored blue:
* SCL
* SDA

SPI Flash is colored purple:
* CLK
* CS#
* SI
* SO
* WP#
* NC

=== Auxiliary Microcontroller (MCU) ===
[[Image:CTR_UC.png|600px]]

Monitors HOME button, WiFi switch, 3D slider, volume control slider.
Controls LEDs, various power supplies via an I²C connection to the PMIC.

Two I²C buses are attached to the MCU. For one, the SoC is the master; for the other, the MCU is the master.

Devices attached to MCU master I²C bus:
* MCU (master)
* Fuel Gauge
* Accelerometer (slave address 0x18)
* PMIC
* maybe more?

Devices attached to the SoC master I²C bus:
* SoC (master)
* MCU
* LCD
* Camera
* QTM (New3DS-only)

The MCU uses the [http://mcs.uwsuper.edu/sb/327/Resources/RL78.pdf RL78 ISA].

The MCU uses some custom Special Function Registers, but documentation for much of the hardware protocol/general SFRs can be found [http://courses.ee.sun.ac.za/Computer_Systems_245/Dokumentasie/RL78%20hardware%20manual%20(registers).pdf here].

File:Ftpd 2tb sd.png

2024-06-18T12:11:39Z

2670QM: Ftpd screen with 2TB SD cards.

== Summary ==
Ftpd screen with 2TB SD cards.

File:Gm9 2tb sd.png

2024-06-18T12:10:21Z

2670QM: GM9 screen with 2TB SD cards.

== Summary ==
GM9 screen with 2TB SD cards.

User:2670QM

2024-06-18T11:09:42Z

2670QM: Updated discord user name to new format

Discord : armv6k

Github : https://github.com/Core-2-Extreme

MVD Services

2021-09-28T08:30:13Z

2670QM: /* Output formats */

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Video processing
! Color conversion
|-
| 0x00010001
| Color conversion
| N/A
| YUYV422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010005
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| YVYU422
|-
| 0x00010006
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| UYVY422
|-
| 0x00010007
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| VYUY422?
|-
| 0x00020000
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00020001
| Video processing
| H.264
| N/A
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
| N/A
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
| N/A
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
! Note
|-
| 0x00010001
| YUYV422
| N/A
|-
| 0x00010005
| YVYU422
| A certain MVD state field must not be set to 0x8170 in order to use this.
|-
| 0x00010006
| UYVY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010007
| VYUY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010008
| YUYV422 with some align?
| A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YVYU422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| VYUY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format?
| 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| ARGB1555?
| N/A
|-
| 0x00040002
| RGB565
| N/A
|-
| 0x00040003
| ABGR1555?
| N/A
|-
| 0x00040004
| BGR565
| N/A
|-
| 0x00041000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| ARGB32
| N/A
|-
| 0x00041002
| ABGR32
| N/A
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2021-09-28T08:24:00Z

2670QM: Updated format name

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Video processing
! Color conversion
|-
| 0x00010001
| Color conversion
| N/A
| YUYV422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010005
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| YVYU422
|-
| 0x00010006
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| UYVY422
|-
| 0x00010007
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| VYUY422?
|-
| 0x00020000
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00020001
| Video processing
| H.264
| N/A
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
| N/A
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
| N/A
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
! Note
|-
| 0x00010001
| YUYV422
| N/A
|-
| 0x00010005
| YVYU422
| A certain MVD state field must not be set to 0x8170 in order to use this.
|-
| 0x00010006
| UYVY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010007
| VYUY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010008
| YUYV422 with some align?
| A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YVYU422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| VYUY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format?
| 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| ARGB1555?
| N/A
|-
| 0x00040002
| BGR565
| N/A
|-
| 0x00040003
| ABGR1555?
| N/A
|-
| 0x00040004
| RGB565
| N/A
|-
| 0x00041000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| ARGB32
| N/A
|-
| 0x00041002
| ABGR32
| N/A
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2021-09-28T01:53:25Z

2670QM: Fixed typo

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Video processing
! Color conversion
|-
| 0x00010001
| Color conversion
| N/A
| YUYV422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010005
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| YVYU422
|-
| 0x00010006
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| UYVY422
|-
| 0x00010007
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| VYUY422?
|-
| 0x00020000
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00020001
| Video processing
| H.264
| N/A
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
| N/A
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
| N/A
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
! Note
|-
| 0x00010001
| YUYV422
| N/A
|-
| 0x00010005
| YVYU422
| A certain MVD state field must not be set to 0x8170 in order to use this.
|-
| 0x00010006
| UYVY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010007
| VYUY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010008
| YUYV422 with some align?
| A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YVYU422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| VYUY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format?
| 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| RGBA5551?
| N/A
|-
| 0x00040002
| BGR565
| N/A
|-
| 0x00040003
| Some sort of RGBA5551?
| 16bit format.
|-
| 0x00040004
| RGB565
| N/A
|-
| 0x00041000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
| N/A
|-
| 0x00041002
| y400a?
| N/A
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

User:2670QM

2021-09-28T01:50:40Z

2670QM: Created page with "Discord : ARM11#7410 Github : https://github.com/Core-2-Extreme"

Discord : ARM11#7410
Github : https://github.com/Core-2-Extreme

MVD Services

2021-09-28T01:46:44Z

2670QM: Updated some format

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Video processing
! Color conversion
|-
| 0x00010001
| Color conversion
| N/A
| YUYV422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010005
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| YVYU422
|-
| 0x00010006
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| UYVY422
|-
| 0x00010007
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| VYUY422?
|-
| 0x00020000
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00020001
| Video processing
| H.264
| N/A
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
| N/A
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
| N/A
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
! Note
|-
| 0x00010001
| YUYV422
| N/A
|-
| 0x00010005
| YVYU422
| A certain MVD state field must not be set to 0x8170 in order to use this.
|-
| 0x00010006
| UYVY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010007
| VYUY422
| see 0x00010005 for the usage requirement.
|-
| 0x00010008
| VYUY422 with some align?
| A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YVYU422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| VYUY422 with some align?
| see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format?
| 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| RGBA5551?
| N/A
|-
| 0x00040002
| BGR565
| N/A
|-
| 0x00040003
| Some sort of RGBA5551?
| 16bit format.
|-
| 0x00040004
| RGB565
| N/A
|-
| 0x00041000
| Unknown
| Doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
| N/A
|-
| 0x00041002
| y400a?
| N/A
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2021-09-28T01:05:38Z

2670QM: Changed layout

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Video processing
! Color conversion
|-
| 0x00010001
| Color conversion
| N/A
| YUYV422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00010005
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| YVYU422
|-
| 0x00010006
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| UYVY422
|-
| 0x00010007
| Color conversion, Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| VYUY422?
|-
| 0x00020000
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00020001
| Video processing
| H.264
| N/A
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
| N/A
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
| N/A
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
| N/A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
|-
| 0x00010001
| See the input format type.
|-
| 0x00010005
| YUY2 (pixel order : YVU)?, A certain MVD state field must not be set to 0x8170 in order to use this. 16bit format.
|-
| 0x00010006
| UYVY (pixel order : YUV)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010007
| UYVY (pixel order : YVU)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010008
| YUY2 (pixel order : YUV) with some align?, A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YUY2 (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY (pixel order : YUV) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| UYVY (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format? 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| RGBA5551?
|-
| 0x00040002
| BGR565
|-
| 0x00040003
| Some sort of RGBA5551? 16bit format.
|-
| 0x00040004
| RGB565
|-
| 0x00041000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
|-
| 0x00041002
| y400a?
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2021-09-28T01:01:48Z

2670QM: Added input format

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Description
|-
| 0x00010001
| Color conversion
| YUYV422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010005
| Color conversion, Video processing
| When color conversion, YVYU422
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010006
| Color conversion, Video processing
| When color conversion, UYVY422
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010007
| Color conversion, Video processing
| When color conversion, VYUY422?
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00020000
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00020001
| Video processing
| H.264
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
|-
| 0x00010001
| See the input format type.
|-
| 0x00010005
| YUY2 (pixel order : YVU)?, A certain MVD state field must not be set to 0x8170 in order to use this. 16bit format.
|-
| 0x00010006
| UYVY (pixel order : YUV)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010007
| UYVY (pixel order : YVU)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010008
| YUY2 (pixel order : YUV) with some align?, A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YUY2 (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY (pixel order : YUV) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| UYVY (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format? 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| RGBA5551?
|-
| 0x00040002
| BGR565
|-
| 0x00040003
| Some sort of RGBA5551? 16bit format.
|-
| 0x00040004
| RGB565
|-
| 0x00041000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
|-
| 0x00041002
| y400a?
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2021-09-27T02:28:09Z

2670QM: /* Output formats */

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Description
|-
| 0x00010001
| Color conversion
| yuyv422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010005
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010006
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010007
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00020000
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00020001
| Video processing
| H.264
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
|-
| 0x00010001
| See the input format type.
|-
| 0x00010005
| YUY2 (pixel order : YVU)?, A certain MVD state field must not be set to 0x8170 in order to use this. 16bit format.
|-
| 0x00010006
| UYVY (pixel order : YUV)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010007
| UYVY (pixel order : YVU)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010008
| YUY2 (pixel order : YUV) with some align?, A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YUY2 (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY (pixel order : YUV) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| UYVY (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format? 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| RGBA5551?
|-
| 0x00040002
| BGR565
|-
| 0x00040003
| Some sort of RGBA5551? 16bit format.
|-
| 0x00040004
| RGB565
|-
| 0x00041000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
|-
| 0x00041002
| y400a?
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2021-09-26T21:53:29Z

2670QM: /* Input formats */

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Description
|-
| 0x00010001
| Color conversion
| yuyv422
|-
| 0x00010002
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010004
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010005
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010006
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00010007
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00020000
| Color conversion, Video processing
| When video processing, H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00020001
| Video processing
| H.264
|-
| 0x00020002
| Video processing
| H.264, output will be corrupt a little??
|-
| 0x00080000
| Video processing
| H.264, output will be gray-scale.
|-
| 0x00080001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|-
| 0x00180001
| Video processing
| H.264, but no output will be written to output buffer with error code 0xD961710A
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
|-
| 0x00010001
| See the input format type.
|-
| 0x00010005
| YUY2 (pixel order : YVU)?, A certain MVD state field must not be set to 0x8170 in order to use this. 16bit format.
|-
| 0x00010006
| UYVY (pixel order : YUV)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010007
| UYVY (pixel order : YVU)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010008
| YUY2 (pixel order : YUV) with some align?, A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YUY2 (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY (pixel order : YUV) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| UYVY (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format? 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| RGB555?, RGBA5551?
|-
| 0x00040002
| BGR565
|-
| 0x00040003
| Some sort of RGB555 or RGBA5551? 16bit format.
|-
| 0x00040004
| RGB565
|-
| 0x00041000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
|-
| 0x00041002
| y400a?
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2021-09-26T06:10:13Z

2670QM: Added some format name

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Description
|-
| 0x00010001
| Color conversion
| yuyv422
|-
| 0x00010002
| Video processing
| ?
|-
| 0x00010004
| Video processing
| ?
|-
| 0x00010005
| Color conversion
| ?
|-
| 0x00010006
| Color conversion
| ?
|-
| 0x00010007
| Color conversion
| ?
|-
| 0x00020000
| Color conversion
| ?
|-
| 0x00020001
| Video processing
| H.264
|-
| 0x00020002
| ?
| ?
|-
| 0x00080000
| Video processing
| Same as 0x00020001, except with gray-scale?
|-
| 0x00080001
| Video processing
| ?
|-
| 0x00180001
| Video processing
| ?
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
|-
| 0x00010001
| See the input format type.
|-
| 0x00010005
| YUY2 (pixel order : YVU)?, A certain MVD state field must not be set to 0x8170 in order to use this. 16bit format.
|-
| 0x00010006
| UYVY (pixel order : YUV)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010007
| UYVY (pixel order : YVU)?, see 0x00010005 for the usage requirement. 16bit format.
|-
| 0x00010008
| YUY2 (pixel order : YUV) with some align?, A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| YUY2 (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000A
| UYVY (pixel order : YUV) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x0001000B
| UYVY (pixel order : YVU) with some align?, see 0x00010008 for the usage requirements. 16bit format.
|-
| 0x00020001
| Some sort of YUV format? 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| RGB555?, RGBA5551?
|-
| 0x00040002
| BGR565
|-
| 0x00040003
| Some sort of RGB555 or RGBA5551? 16bit format.
|-
| 0x00040004
| RGB565
|-
| 0x00041000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
|-
| 0x00041002
| y400a?
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

ACI:GetConnectingNetworkEnableUPnP(bool)

2019-11-05T03:51:08Z

2670QM: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x04A10000] |} =Response= {| class="wikitable" border="1" |- ! Index Word !..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04A10000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 1
| Result code
|-
| 2
| 0 = Disabled, 1 = Enabled(?).
|}

=Description=
If disabled UPnP return 0.
If enabled UPnP return 1.(?)
=Example=

Handle share_ac_handle;

u32* cache_buffer = getThreadCommandBuffer();

srvGetServiceHandle(&share_ac_handle, "ac:i");

cache_buffer[0] = IPC_MakeHeader(0x4A1, 0, 0); // 0x04A20000

svcSendSyncRequest(share_ac_handle);

printf("Result : 0x%lx", cache_buffer[1]);

printf("MTU value : %ld", cache_buffer[2]);

svcCloseHandle(share_ac_handle);

ACI:GetConnectingNetworkMtu

2019-11-05T03:36:56Z

2670QM:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04A20000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 1
| Result code
|-
| 2
| MTU value.
|}

=Description=
Return the current access point to MTU value.
If the 3DS is connected to the internet, return the current access point's MTU value.
If the 3DS isn't connected to the internet, return the last connected access point's MTU value.
(If the 3DS has never connected to any access point return to 0)

=Example=

Handle share_ac_handle;

u32* cache_buffer = getThreadCommandBuffer();

srvGetServiceHandle(&share_ac_handle, "ac:i");

cache_buffer[0] = IPC_MakeHeader(0x4A2, 0, 0); // 0x04A20000

svcSendSyncRequest(share_ac_handle);

printf("Result : 0x%lx", cache_buffer[1]);

printf("MTU value : %ld", cache_buffer[2]);

svcCloseHandle(share_ac_handle);

ACI:GetConnectingNetworkMtu

2019-11-04T13:51:08Z

2670QM: /* Description */

ACI:GetConnectingNetworkMtu

2019-11-04T13:46:52Z

2670QM:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04A20000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 1
| Result code
|-
| 2
| MTU value.
|}

=Description=
Return the current access point to MTU value.
If the 3DS is connected to the internet, return current access point MTU value.
If the 3DS isn't connected to the internet, return last connected access point MTU value.
(If the 3DS has never connected to any access point return 0)

=Example=

Handle share_ac_handle;

u32* cache_buffer = getThreadCommandBuffer();

srvGetServiceHandle(&share_ac_handle, "ac:i");

cache_buffer[0] = IPC_MakeHeader(0x4A2, 0, 0); // 0x04A20000

svcSendSyncRequest(share_ac_handle);

printf("Result : 0x%lx", cache_buffer[1]);

printf("MTU value : %ld", cache_buffer[2]);

ACI:GetConnectingNetworkMtu

2019-11-04T13:17:45Z

2670QM: /* Example */

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04A20000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 1
| Result code
|-
| 2
| MTU value.
|}

=Description=
If 3DS is connected to Internet return current access point MTU value.
If 3DS isn't connected to Internet return last connected access point MTU value.(If 3DS has never connected any access point return 0)

=Example=

Handle share_ac_handle;

u32* cache_buffer = getThreadCommandBuffer();

srvGetServiceHandle(&share_ac_handle, "ac:i");

cache_buffer[0] = IPC_MakeHeader(0x4A2, 0, 0); // 0x04A20000

svcSendSyncRequest(share_ac_handle);

printf("Result : 0x%lx", cache_buffer[1]);

printf("MTU value : %ld", cache_buffer[2]);

ACI:GetConnectingNetworkMtu

2019-11-04T13:15:45Z

2670QM: /* Example */

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04A20000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 1
| Result code
|-
| 2
| MTU value.
|}

=Description=
If 3DS is connected to Internet return current access point MTU value.
If 3DS isn't connected to Internet return last connected access point MTU value.(If 3DS has never connected any access point return 0)

=Example=

Handle share_ac_handle;

u32* cmdbuf = getThreadCommandBuffer();

srvGetServiceHandle(&share_ac_handle, "ac:i");

cmdbuf[0] = IPC_MakeHeader(0x4A2, 0, 0); // 0x04A20000

svcSendSyncRequest(share_ac_handle);

printf("MTU value : %ld", cache_buffer[2]);

ACI:GetConnectingNetworkMtu

2019-11-04T13:15:17Z

2670QM:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04A20000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 1
| Result code
|-
| 2
| MTU value.
|}

=Description=
If 3DS is connected to Internet return current access point MTU value.
If 3DS isn't connected to Internet return last connected access point MTU value.(If 3DS has never connected any access point return 0)

=Example=

Handle share_ac_handle;
u32* cmdbuf = getThreadCommandBuffer();

srvGetServiceHandle(&share_ac_handle, "ac:i");
cmdbuf[0] = IPC_MakeHeader(0x4A2, 0, 0); // 0x04A20000

svcSendSyncRequest(share_ac_handle);

printf("MTU value : %ld", cache_buffer[2]);

ACI:GetConnectingNetworkMtu

2019-11-04T13:03:42Z

2670QM: /* Response */

ACI:GetConnectingNetworkMtu

2019-11-04T13:02:27Z

2670QM: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x04A20000] |} =Response= {| class="wikitable" border="1" |- ! Index Word !..."