One from the electronics powerhouse that is Sony… should be interesting!
A small and simple disk structure certainly makes things easier. I am drowning in virtual machines containing different Video Management Systems and proprietary Codec installations.
A player and a folder with a series of .cam files – Simple!
The properties of the player are also well documented – makes a nice change!
When first run, the small red check box in the top left was empty. As a result, the player was suggesting I browse for an index file. Upon selection, the text changes to enable the search for .cam files instead. Rather than selecting the folder containing the CAM folder, you have to actually open the CAM folder. When you do, they populate the left side of the player.
The usual controls are along the bottom. The frame reverse only goes back in sections….. the tell tale sign that these are highly likely to be I frames and as such identifying the video as some form of mpeg. Each .cam has a start and end time displayed, including milliseconds. By right clicking the video window, we can get some more information.
We could do with a few more bits of information here, such as amount of Frames, Resolution, Aspect Ratio and GOP structure but its a start.
At the bottom of the player we have two export options, Still Image and Video (AVI).
The option for still image export appears to be a straight frame grab due to there being no date/time overlay added. Interestingly, in my example, I actually had a good size image at 1280px x 720px. When most of the day is spent dealing with 352px x 288px, anything over PAL is a nice surprise!
We already know that the format is H264, so is the AVI export merely a re-wrapper? NO… It gives you a Motion Jpeg encoded AVI. The transcoding was fairly fast considering it is writing new images for every frame but its a shame that Sony doesn’t give you further video export options. I noted that on the file used for analysis, the converted video presented 81 Frames as I will need this number later. The time was now overlayed and it was padded with a large amount of duplicate frames to give a 30 FPS video even though the native player and the Motion Jpeg overlay presented just over 4 Frames per Second.
Before moving on I thought it worthwhile to see if there was further software available. As you can imagine, with a huge organisation like Sony, finding information and downloads could take a little while.
I located a new player, Ver 220.127.116.11 and also the main Manager Software. I originally planned to give this a go but after reading the manual I didn’t bother.
The new version of the player didn’t offer any more functionality so it was time to move on and examine a .cam file >>>>
Firstly, the times. Hex Chomper from MFT revealed the dates and times throughout the file, one for every frame in Win64 Little Endian Format. I couldn’t locate the milliseconds during my review.
MediaInfo and FFprobe detected the AVC stream immediately. Upon conducting a FFprobe -show_frames XML sheet, I was a little surprised not to see a Presentation Time Stamp within the encoding. It’s possible that FFprobe just can’t detect it. The only Parameters listed were those seen in the image below.
ffprobe -show_frames -print_format xml yourfile.cam > yourfile.xml
A selection of the results obtained:
I believe that the Player uses the Date and Time information to control the speed of the video playback. Within the data of each file, right at the start is the beginning and end time. Then throughout the video are the individual time stamps. It’s probable that this important time data controls the speed when being played back by the player, rather than a standard MPEG PTS.
Through a number of tests I could not contain the AVC Stream into a playable .MP4 or .M4V container. I believe that this is due to those containers requiring a PTS. Placing the footage into an .AVI or an .MKV worked with no problems.
ffmpeg -f h264 -i yourfile.cam -c:v copy -fflags genpts yournewfile.mkv
This produced a newly contained file and all analysis and results shared the 81 Frame count with the Motion JPEG AVI that the native player produced.
Using the duration identified by the player, along with the frame count, the Frame rate of 4.34 FPS was identified so this could be added into any re-wrapping if required (by adding -r 4.34 before the output file). WARNING: Only suitable for presentation / informative use. However, if that was your requirement, the Motion JPEG file produced by the player would probably be just as suitable.
After this, the options for further processing are many…
- I frame Extraction to Tiffs,
- All Frame Extraction to Tiffs
- Automated Re-wrapping of all Cam files
- Concatenating of all files into a single analysis stream.
Concatenating and containing the raw streams into a single review file was very quick and could make the task of finding specific images of interest much faster and easier than selecting each .cam file and using the native player.
ffmpeg -f h264 -i "concat:file1.cam|file2.cam|file3.cam" -c:v copy -vsync drop -fflags genpts yournewfile.mkv
More on concatenating:
Tested in Amped FIVE – the .cam files can be read after the software creates an index file. This only a single mouse click and then the video appears and scrubs with no issues. As in the manual mode described above, due to no timing information within the mpeg stream, you will need to adjust the frame rate from within FIVE to review the footage at something near to the native playback rate. For dealing with the frames / images though, this is another quick route.
I hope this gives you some useful information on dealing with these files.