I'm not sure---the last FS usually only posts a modified date if the file is modified and not deleted.
If its simply deleted, it'd those sectors as 'gone' in the file table but there's no notation in the file table to say when modifications to it were made.
Many current filesystems implement journaling - essentially, a circular buffer where operations are logged before being acted on. Therefore, it's perfectly possible that a log entry of the deletion is still on the device, if it used a journaling fs.
EDIT: Also, the EXT filesystems have a 'dtime' (deletion time) property for inodes.
Most photo-cameras use FAT for SD cards so I expect journaling is not that common. Don't know if the same applies to 'professional' video-cameras though.
My DVR uses FAT32 on a 1TB disk. Each recording has a meta entry that holds a list of files that make up that recording. As far as I can tell, as it records, it closes a file that is approaching 4GB, opens a new one to continue recording, and updates the meta entry by adding the new file name to the list.
The DVR is consumer grade, but this method is simple to implement. I guess my point is that it is a solved problem to use FAT with large files.
If its simply deleted, it'd those sectors as 'gone' in the file table but there's no notation in the file table to say when modifications to it were made.