Another one on my ‘to do’ list, I had all of this in a folder ready to write up but forgot all about it. After a terrible week, it was good to get this one ticked off.
Before we get into it, the usual disclaimer! Remember that systems get changed, upgraded and have bugs fixed on a regular basis. Not every Cellstack export is going to look like this. It is up to you to investigate, analyze and verify your findings independently.
Exports like this tend to come from quite large scale networks.
The disk will autorun, if this function is enabled on the PC in use. During the autorun process, it will check to see if a certain version of DotNet is installed. If not, the player won’t run. Unfortunately, this is not packaged with the export and no link is provided. The other difficulty may be finding a PC that you can actually install this on, if you are behind a corporate network. The ‘Readme’ explains that if the Autorun did not work, then the player can be started by using the .bat file. WARNING: Be careful when running players from batch files. It is common for them to copy .dll files into your system folder and then register them. Obviously this can cause all sorts of problems! Check any .bat files before using them.
The players information reveals a company, Telindus. Upon research, it appears that they have been acquired by Telent. I could not find any information here to assist and there was limited information upon research on Cellstack.
The player is quite simplistic, with a clip index at the bottom. When double clicked, it loads into the main window with a file start and end time given. Milliseconds are only displayed at the frame marker.
The options for export are limited to image only, and each image is named with the date and time information including milliseconds. The images are exported at 720×576.
I find the following issue in quite a few players, and it can cause big problems during analysis. The image data and the time data do not retain their synch. As such, during scrubbing, it is possible to export the same date and time but with different images. Or, the other way around, with the same image but with different times!
I exported a frame (12:40:05.920) and then scrubbed through the video twice. I then exported the same frame in time. As can be seen from the difference filter above, they are different. There was a 3 frame difference in time.
I now know that I cannot export video from the player and the player presents the video in a different size to that being exported. I have identified that it’s possible to have different images display the same time. As a result, analysis of the video is required.
Inside the Player folder, was a folder called Recordings: The .bin files are much larger so I can assume these are the video. The .csm files consists of the frame indexing in a format similar to the quicktime MOOV atom method. The .rec data appears to be a file index, instructing the player to treat the two .bin files as a single video. Upon scanning the .bin and .csm files I have not been able to locate any standard date and time data (using MFT Hex Chomper).
So, lets have a quick look at these .bin files in MediaInfo…
Kind of stream : Video
Stream identifier : 0
Inform : 8 250 Kbps, 720*576 (4:3), at 25.000 fps, MPEG Video (PAL) (Version 2) (Main@Main)
Format : MPEG Video
Format settings, BVOP : No
Format settings, GOP : N=1
Codec : MPEG-2 Video
Duration : 17mn 20s
Duration : 17mn 20s 800ms
Bit rate : 8 250 Kbps
Width : 720 pixels
Height : 576 pixels
Pixel aspect ratio : 1.067
Display aspect ratio : 1.333
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Frame count : 26020
Standard : PAL
Resolution : 8
Colorimetry : 4:2:0
Color space : YUV
Bit depth : 8 bits
Scan type : Interlaced
Scan order : BFF
Scan order : Bottom Field First
Compression mode : Lossy
and the important bits from Bin 2:
Duration : 158280
Duration : 2mn 38s
Duration : 2mn 38s 280ms
Duration : 2mn 38s
Duration : 00:02:38.280
Frame Count : 3957
So… what have we learned from this?
- MPEG 2
- Maximum GOP length of 1 – very unusual, will have to look further at that.
- 720 x 576 Raster Size
- Display Aspect Ratio of 4:3
- Frame Counts given
- Timing given including milliseconds.
- 25 FPS
- INTERLACED, BFF
Just as a quick pointer, if you only have one .bin file, it is possible to miss out the concatenating stage that I will come on to. Virtualdub will read the stream as long as you identify what stream it is. You can do this by specifying to open the .bin file as an MPEG2 file if you have the mpeg2 plugin (found in my Virtualdub pack – shared in my box on the right) Be aware of the frame count issue though – it’s explained shortly!
You can also deal with them inside other software that can detect the streams. For those people with Amped FIVE, you can load in the files using directshow and deal with it all in there. This includes all the deinterlacing, filtering, enhancement and presentation work.
The first thing I want to do though, is deal with the video as a single file. I need to do this as the player has given me a start time and by dealing with the clips as one, I can synch frame number to time, regardless of what bin file they were in.
FFmpeg can be used to join the files and change the container. This is where things get interesting…. From reviewing the .bin files I have a total frame count of 29977. If I simply joined the files together, my data analysis would read 29977 frames but, in many players, I would not be able to decode the last one. This is an issue with unindexed mpeg streams. So, using the following….
ffmpeg -f mpegvideo -i "concat:file1.bin|file2.bin" -c:v copy fileall.mpg
would result in a visually acceptable file but it is missing the last frame.
The frame count is really important here. If we need to utilise the video further on, we have to start with a product we can rely on. Linked with this are the frame timings on both the original .bin files and the new mpg.
It is a simple case of generating an index and placing the stream into a container that can deal with the index. I am not transcoding!
ffmpeg -f mpegvideo -fflags genpts -i "concat:file1.bin|file2.bin" / -c:v copy newfile.mkv
The resulting .mkv file can display all frames as intended. Here it’s in Virtualdub with a time and frame number filter added to the bottom.
When the original player was used, the first and last frame able to be exported can be seen below:
The first frame is duplicated and repeated in the next image, thereby giving an actual start time of 12:40:00.120
The last frame exportable by the player is 12:59:59.040, but there is another one after it, plus a duplicate.
To validate the timings I viewed and compared both 12:59:59.040 frames in photoshop. One was exported from the player and the other was from my new full mkv file.
I now have a file with the correct timing, and all frames can be seen. Upon further inspection I can see that every frame is an I frame. The problem therefore is not the predictive nature of the encoding, but the interlacing and the aspect ratio.
I could deinterlace, resize for the 4:3 aspect ratio and create an image sequence PDF
I could view at field level and double the frame rate to present each field as a seperate image. A regular one for me is to export at field level and then batch process in photoshop with a frame number and then either a T or B after each file name to denote the specific field.
Remember if you have 50 fields per second and you process to 25 progressive frames, 50% of your imagery is being discarded!
I could transcode my footage to another presentation medium.
Whatever is required, I am in a much better position to complete the task correctly, now that I understand the video data and have processed it into a file that I can validate and use.
I hope all of this helps, not just in dealing with this specific export and player, but it may offer some suggestions for dealing with other exports or players with limited functionality.