Introduction
The udev/udisks systems are aimed at simplifying and automating making devices/disks available to userspace application ... Yes, they can understand user defined rules via udev rules, but IMO these are for tweaking and fixing essential basic issues and not suitable for adding extra user desired features ... A better approach for such extended/advanced usage is outside udev by means of shell scripts, cron jobs, user startup applications or even custom systemd units(services).
However, when dealing with udev rules there are a few notes that must be taken into consideration ...
First note
You haven't provided an input argument to vlc ... You need to specify a media input source e.g., in your case, the full path to the MP4 file.
Second note
vlc requires a display server to run which might or might not be available as an environment variable for the udev rules and therefore might require explicitly setting the display server's address/name(which can be found with e.g. echo "$DISPLAY") environment variable directly before running the command like e.g. DISPLAY=":0" /bin/vlc file.mp4.
It also launches a full GUI interface which might be more than what you actually need for such a one shot simple task ... cvlc, however, is a headless variant of the VLC multimedia player and runs without a GUI ... So you might want to give that a try.
Third note
udev rules run as the user root(without actual login ... So a user-runtime environment, which is needed for running userspace applications like VLC) and commands/script run under them run as root as well ... A display server and an audio server don't usually run under root by default ... Therefore, a currently logged-in user(other than root) might be specified to overcome this limitation with e.g. by putting the command in an su command string like so(changing username to the actual desired invoking usernam):
su username -c 'DISPLAY=":0" /bin/vlc file.mp4'
Fourth note
The device that triggers your udev rule is not made available to your userspace applications as vfsmount(Virtual FileSystem mount) or even as a device file under /dev/ until the rule triggered by it finishes executing ... Therefore if the file you want to play with that udev rule resides on the same device that triggers it then this might be an impossible situation ... See why and how to overcome this in this similar post: Different behaviour of bash script in udev
Fifth note
There are limitations to what tasks can be done from within udev ... In addition to the above mentioned filesystem mounting limitation, networking is also not available to udev rules due to security/isolation reasons ... There are, however, possible workarounds like for example launching and detaching a sub-shell to run such commands in the background as a certain privileged user.
