The region mask appears to be changed to 0x00000000 when using various ripping software which can decrypt (i.e. remove the DRM) the discs.

mpv reports:

libdvdnav: DVD disk reports itself with Region mask 0x00000000. Regions: 01 02 03 04 05 06 07 08

VLC in turn:

dvdnav demux: DVD disk reports itself with Region mask 0x00000000. Regions: 01 02 03 04 05 06 07 08

Does this mean that the region restrictions have simply been patched out? Why the string is 0x00000000 and not just 0 ('global'), or all flags from 1 to 8?

  • 10
    0x00000000 and 0 are the same number.
    – MechMK1
    Mar 30, 2022 at 14:06
  • @MechMK1 While this is correct in isolation, it's not in the case of the message shown. The 0x00000000 isn't simply "the region mask as a number", instead, the eight bit mask is at the position marked .. in 0x00..0000 in that message. Apr 3, 2022 at 18:25

4 Answers 4


The region code has been set to all regions

Source: It's been a few years since I had a full ~9" stack of DVD specs (physical to logical) sitting on my desk, but I used to work in anti-copy protection of DVDs. Much of this info is also available at https://en.wikipedia.org/wiki/DVD_region_code

The field-size issue

I'm 99% sure that the field is 16-bit, and as @harrymc says, the apparent 32-bit number is a red herring. In any case, only the bottom 8 bits were used. This was common in the DVD spec, where lots of fields had reserved bits for potential future expansion.

0x00 signifies playable in all regions

The bit-field is inverted – a '1' in the bit means the DVD is not permitted to play in that region. So a region of '0x01' means it may not play in region 1 but may play elsewhere. A region 1 disk is coded 0xFE.

Thus a region of '0x00' means it is playable in all regions.

Most rippers alter the region to 0 when ripping, as historically one of the main reasons for ripping (or at least the main quasi-legal reasons!) was to defeat region restrictions, and there's no downside for them in doing so.


The values of 0x00000000 and 0 are identical. The only difference is in the program that is writing out the code.

The code 0x00000000 is printed using the hex format, while 0 would have been the value if written out as decimal.

This is just the way that libdvdnav is programmed, using a print that specifies the hex format.

For programming information see the fprintf function.

  • 2
    I don't really agree with this. printf 0 in hex would give 0x0. Your example is zero padded to 32-bit, which is of course numerically equivalent, but that has nothing to do with it being hex since you could also have zero padded (decimal) 0 to 000000000, which would also be 0.
    – Opifex
    Mar 30, 2022 at 8:17
  • 1
    What do you mean it's not that limited? I didn't mention any limitation? Following your own link to the C++ reference it also shows a description of zero-padding. (2nd table, last row)
    – Opifex
    Mar 30, 2022 at 8:30
  • 1
    @orithena I'm confused. Isn't that exactly what I pointed out? printf can print a number in any format (dec, hex, oct) with or without leading zeroes. The leading zeroes are not part of what defines the format.
    – Opifex
    Mar 30, 2022 at 9:14
  • 2
    @orithena The reason I pointed it out is because right now it is implied that 0 converted to hex is 0x00000000. In other words: that hex requires those zero-pads. Which is not the case of course. The hex conversion has nothing to do with it.
    – Opifex
    Mar 30, 2022 at 10:22
  • 1
    @orithena That is indeed exactly what I meant: converting 0 to hex does not yield 0x00000000 but 0x0. Of course it is numerically equivalent to 0000000 and 0x0000000, but it would also be equivalent to 132487*0. You say it's commonly printed with 4 bytes, but that is only because you are used to working in a 32-bit environment. I come from an electronics background where this is a lot less common.
    – Opifex
    Mar 30, 2022 at 15:09

The region code is handled as a 'bit mask' because any given DVD can be coded for multiple regions. The region code of 0 (global) is equivalent to no bits set in the mask. Assuming that the bits are numbered from right to left (the usual sort of thing that's done in computers), the region codes would be


so that a disc that was coded for US/Canada (region 1) and Europe/Middle East (region 2) would have the region mask


and one that was coded for US/Canada (region 1), Latin America/Australia/Oceania (region 4), and Southeast Asia (region 3) would have the region mask


eta: I actually got the bits 'flipped' in the explanation above; per https://www.askingbox.com/info/the-dvd-region-coding-and-its-technical-implementation, a 1 in a bit position locks out that region, and a 0 enables playback. So, the first example should be 0x11111100 and the second 0x11110010. This is still a single byte in binary, however, not the full 32-bit word that the notation implies.

  • 17
    This would make sense if the prefix were 0b (binary), but it's not; it's 0x (hexadecimal). 0x00000000 is a 32-bit number...
    – kwc
    Mar 30, 2022 at 1:59
  • 1
    @Panzercrisis - Ask whatever organization decided on the regions about that; I'm just using the information in Wikipedia. Mar 30, 2022 at 11:05
  • 2
    @JeffZeitlin: But 0x00fe0000 is still completely different from what your explanation suggests. Mar 30, 2022 at 18:01
  • 11
    The current layout of this answer is weird. You state one thing and then at the end you say it's the other way around. If you want to keep the part you now believe is wrong, explain at the beginning why you're doing this. For now a newcomer sees your upvoted answer, reads it in a hope of learning something, and after they build a mental picture and maybe start to think "oh, this makes sense", you turn it all upside down. This is not how you spread knowledge. Mar 30, 2022 at 18:22
  • 2
    This is not how bits are numbered usually, they are numbered consecutively, and what this answer numbers are nibbles, not bits. This answer is very wrong. Mar 31, 2022 at 7:20

Its region mask is zero, meaning it's playable everywhere. The message is the same when playing any non-region-restricted DVD (it does not have to be ripped).

In the message, the 8-bit region mask is sort of hidden inside the 32-bit long value*.
Here's what running mpv dvd:// said about four different commercial DVDs I have:

libdvdnav: DVD disk reports itself with Region mask 0x00fe0000. Regions: 01
libdvdnav: DVD disk reports itself with Region mask 0x00fd0000. Regions: 02
libdvdnav: DVD disk reports itself with Region mask 0x00e50000. Regions: 02 04 05
libdvdnav: DVD disk reports itself with Region mask 0x00000000. Regions: 01 02 03 04 05 06 07 08

In the first example, the region mask 0xfe (0b11111110) means regions 8 to 2 are masked:
It's only playable in region 1. (Only the rightmost bit is zero.)
The inverse (one's complement) of that mask, 0x01 (0b00000001), would mean the opposite: Region 1 is masked, it's only playable in the other regions.

*: It could be some sort of debug thing or an oversight why it's displayed like this. Although the logic doesn't change, it only reveals itself when there's a non-zero mask (the first three examples).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .