Multimedia file formats

B

balanga

I'm trying to access files recorded on a PVR but don't recognise any of the files. The Decoder is from Vectra (in Poland) so the files may be in some sort of proprietary format.
How should I go about finding a program to read them? Should I just point VLC at a directory containing various files in the hope that it detects something viewable?
 
Look at the first few bytes of the file. Those are usually "magic" numbers. Which is basically the same thing file(1) does.

List of file signatures - Wikipedia

en.wikipedia.org en.wikipedia.org

But I'm going to guess they used some sort of DRM or encryption on those files. This makes them useless unless you're able to break the DRM/encryption.
 
At least give file(1) a try. It is pretty smart even without any file extension. For example, I renamed a .mp4-movie to test.

file test
Code: 
test: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]
 
On UNIX(-like) systems file extensions are irrelevant, they're just part of the filename and have no special meaning. File extensions are a relic from the old CP/M and MS-DOS era.
 
Actually, Windows itself doesn't really depend on file extensions either. Not a modern Windows version at least. Older versions (Windows 95 et al.) did though. And, more importantly, a whole slew of brain-dead third party applications still depend on it. But you can't blame Windows (or Microsoft) for that.
 
Windows 10 build 1809 (?) must have file extensions or it will always ask how you want to open a file, at least from the file manager anyway. It's not a deal breaker and you can always use the previously associated application to open the file anyway but the OS still throws up a warning about the extension when you remove it.

Doesn't break anything but they still use the extensions at least if you open everything from the file manager, which I do.
 
SirDice said:
File extensions are a relic from the old CP/M and MS-DOS era.
Click to expand...

If you take an extension off a file Windows doesn't know what to do with it in terms of associations with programs. I don't know the mechanics there, but Windows doesn't seem to be using them. In any case it should be relic, but doesn't seem to be. That is one thing I've always liked a lot about Unix, it's never used extensions like that.
 
SirDice said:
On UNIX(-like) systems file extensions are irrelevant, they're just part of the filename and have no special meaning. File extensions are a relic from the old CP/M and MS-DOS era.
Click to expand...

While it is worth noting that file(1) does not check the file type by extension but by introspection, I don’t see extensions as a relic, but as a convention. This convention is still used on many operating systems for quickly deducing the type of files. On the other hand, also on MS-DOS we could do mere file system operations without any extension, and FreeBSD does heavily rely on this kind of convention for various purposes. You can find this out yourself:

DO NOT FOLLOW THE FOLLOWING!

1. execute:
# cd /boot/kernel
# find . -name "*.ko" -exec sh -c 'mv "$1" "${1%.ko}"' '$0' {} ';'

2. execute:
# cd /usr/src
# find . -name "*.c" -exec sh -c 'mv "$1" "${1%.c}"' '$0' {} ';'
# find . -name "*.h" -exec sh -c 'mv "$1" "${1%.h}"' '$0' {} ';'

3. restart

Once you managed your FreeBSD system to boot having all kernel modules without .ko extension, you want to try to build the kernel and world from sources without any .c and .h extensions. After some days of trial and error to no avail, you will perhaps come to appreciate FreeBSD using file extensions as a convention even if it is strictly technically not necessary.
 
I don't recognise any of the filenames.... Here is a listing of the root directory:-
Code: 
root@Vbox:/mnt/tmp # ls -al
total 385060
drwxr-xr-x   5 10    kmem        4096 Jan  1  1970 .
drwxr-xr-x  18 root  wheel        512 Jan  9 14:54 ..
drwx------   4 10    kmem        4096 Jan  1  1970 .dvrcc
-rw-------   1 10    daemon  98566144 Jan  8 22:52 00.po
-rw-------   1 10    daemon  98566144 Jan  8 22:45 01.po
-rw-------   1 10    daemon  98566144 Jan  8 22:48 02.po
-rw-------   1 10    daemon  98566144 Jan  8 22:50 03.po
drwx------   3 10    kmem        4096 Jan  1  1970 OCAP_LSV
-rw-------   1 10    kmem           5 Jan  2  1970 OCAP_LSV~~attr
drwx------   2 10    kmem       16384 Jan  1  1970 lost+found

I presume that the recordings are held in .dvrcc which contains:-
Code: 
root@Vbox:/mnt/tmp/.dvrcc # ls -al
total 184
drwx------  4 10  kmem    4096 Jan  1  1970 .
drwxr-xr-x  5 10  kmem    4096 Jan  1  1970 ..
drwx------  2 10  kmem   36864 Jan  8 22:54 meta
drwx------  2 10  kmem  135168 Jan  8 22:52 streams
streams contains a large number of files similar to:-
Code: 
-rw-------  1 10  daemon  98566144 Jan  8 16:30 a96-c
-rw-------  1 10  daemon  98566144 Jan  8 16:32 a96-d
-rw-------  1 10  daemon  98566144 Jan  8 16:35 a96-e
-rw-------  1 10  daemon  98566144 Jan  8 16:38 a96-f
-rw-------  1 10  daemon  98566144 Jan  8 17:32 a97-0
-rw-------  1 10  daemon  98566144 Jan  8 17:35 a97-1
-rw-------  1 10  daemon  98566144 Jan  8 17:39 a97-2
-rw-------  1 10  daemon  98566144 Jan  8 17:42 a97-3
-rw-------  1 10  daemon  98566144 Jan  8 17:45 a97-4
-rw-------  1 10  daemon  98566144 Jan  8 17:48 a97-5
-rw-------  1 10  daemon  98566144 Jan  8 17:51 a97-6
-rw-------  1 10  daemon  98566144 Jan  8 17:55 a97-7
-rw-------  1 10  daemon  98566144 Jan  8 17:55 a97-8

file identifies these files as 'data' and looking at the file with a file viewer does not show any recognisable strings...

The disk with the recordings comes from a Polish Vectra decoder, if anyone is familiar with them....
 
Thanks for the pointer, but one of the notes says:-
NOTE: To decrypt PVR recordings you need a dump of the unique AES-128 key from your TV
Click to expand...

but since I have no idea as to how to retrieve that I'm stuck. I think my only hope is to somehow find some way of logging in to the STB and copying recordings onto a USB stick.
 
You must log in or register to reply here.
Back
Top