I have looked everywhere and cannot find an answer, hopefully with all the experts on this site I can be pointed in the correct direction to a solution.
A VHS containing a recording of 6 CCTV feeds was digitized and downsized using (dvdshrink) then burned to 6 DVDS each containing 6 VOB files. I have attempted to view them but they appear to be stacked ontop of each other, when attempting to demux I get a result of only one stream being available. Using a CCTV player I get an error indicating format error and will not play. Any help is greatly appreciated.
+ Reply to Thread
Results 1 to 20 of 20
Last edited by Cis85701; 4th Sep 2014 at 13:31. Reason: corrected errors and give a better explanation of problem
Most VHS recordings that utilized multiple CCTV feeds (e.g. security cams, etc) still had to stay within NTSC (or PAL in those areas) parameters. They did so by multiplexing the signals, either sequentially or spatially.
If sequentially multiplexed, a single feed of 30FPS (60 fields/sec) would change to 5FPS (5 or 10 fields) and then 6 such feeds might be interleaved field-wise thus: (A top, B bottom, C top, D bottom, E top, F bottom, A top, B bottom, C top, D bottom, E top, F bottom) or frame-wise: (A top, A bottom, B top, B bottom, C top, C bottom, D top, D bottom, E top, E bottom, F top, F bottom).
If spatially multiplexed, each feed of full screen SD (equiv.~640x480) is resized down to fit 4x, 9x, etc. images on a single screen.
I'm guessing it is likely a form of the first method.
It would be best if the OP uploaded a short clip of an original VOB file. Then would know for sure and be able to proceed correctly.
***Note that the term "multiplex" and "demultiplex" in the context of analog multi-cam feeds bears NO RELATION to how it is used in combining data files/streams/packets (other than the generic idea of what multiplexing means: "to weave together multiple strands into one")
I am a newbie to posting on forums, please advise if I need to upload the sample clip elsewhere. Thank you in advance for all the assistance.
vid.user: I really don't know what I have or what process exactly was used, sorry all I have 6 DVD's that I cannot view properly.
Note: A little while ago I received a call from a LP video specialist who indicated back when this CCTV was taken it was most likely produced with a Rainbow technologies quad processor or a 9CH with only six cameras connected. Not sure if it makes a difference or helps any.
OK, so it was sequentially multiplexed, like I was thinking. However, there is some strangeness to it which makes it very difficult to determine the actual sequence timing, so this may take a while. I am making some headway with using AVISynth and a combination of "Separate Fields()" and "SelectRangeEvery()" script elements.
I noticed the audio was there, but it was sped way up, so I demuxed it out, slowed it down, mixed to mono, and saved an unprocessed WAV & mp3 of it (NR processing is a good idea but should be used judiciously). Here is the mp3 version:
More to come...
I only see 5 views , not 6
#front door looking in
#front door looking out
#cash register left
#cash register right
The sequence is hard to get down and changes (pattern starts out repetitive, but changes)
If this was representative - I would just display the fields separate or "bobbed" with even and odd frames stacked side by side. But I wonder if there is additional information on the other VOB's from the other discs
But I wonder what is the relevance of 6 feeds, and 6 DVD's , each with 6 VOB's ? 666
Where is the other 6th feed, and what does a VOB on another disc look like ?
I wonder how it was digitized? Perhaps some more info on the equipment and process used would help
Interesting that there is no burnt in timecode. Usually with surveillance footage, time/date is stamped on
You could probably get something usable by using "SelectRangeEvery()" with a couple of variables that take input from a list (which you'd manually have to supply after doing extensive walkthrough).
There's also some weirdness in that it seems that each frame is actually an overly of 2 frames.
Checked on Rainbow CCTV: seems it is out of business as of 2011-2012, so tough luck trying to find a manual or specs or anything.
Yes, more info please, if at all possible...
If you bob deinterlace them , then group into even/odd frames, each appears in 4 consecutive frames before switching, But the offset for each camera view changes. For example, if the offset is 16, it stays like that for a while then swaps to 24 later on. It makes grouping the camera views difficult to do automatically with avisynth
Quick demonstration of what I'm trying to say
(This has been , cut, resized, and slowed down for demonstration purposes. The bobbed framenumber, and actual clip running time is overlaid)
If you take one view, eg.. the "front door out view"
It occurs with offset of 16 until later, where it swaps sides to "odd" numbers with an offset of 24
8,10,12,14 24,26,28,30 . . . 105, 107,109,111 129,131,133,135
I was thinking there might be a missing camera view on one of the other discs. Maybe some combination of using the other view would make it work. Also, if the actual burnt in timecodes were overlaid, it would provide a clue
Most if not all cctv applications won't play anything other than their proprietary avi formats.
Breaking it down.
Aidemux > filter = horizontal stack > crop left 720 > resize 720x480 > output right view avi
Aidemux > filter = horizontal stack > crop right 720 > resize 720x480 output left view avi
Each camera view portion is 4 frames in sequence in new outputs ... both left and right contain I frames at the start of each camera portion
Use ffmpeg to split left view at i frames to folder left view, repeat for right view to folder right view
Finally concat similar sections in order of view outputs.
That systems recording frame rate was way too low.
What was your script, pdr? Mine never looked that clean.
This is the original side by side script
Mpeg2Source() AssumeTFF() Bob() BicubicResize(640,480) ShowFrameNumber() ShowTime() orig=last orig selecteven ev=last orig selectodd od=last stackhorizontal(ev,od)
But I think I have a "semi-automated" approach, at least proof of concept coming up
One way you might be able to "semi-automatically" do this is use avisynth with a conditionalfilter() or writefileif() . The idea is to use a "detection patch" so you crop the video to a frame that has similarity to the one you want. In this example I used the fire extinguisher as the distinguishing feature for this view.
To get an idea of what's going on, this is what the "patch" looks like for the "front door looking out" view , that's what the "crop" values below are for
###this is the video, cropped to the region of interest MPEG2Source("VTS Sample for VideoHelp.d2v") AssumeTFF() Bob() BicubicResize(640,480) Crop(480,120,0,-152,true) frontout_crop=last ###this is the still frame detection patch, using the same region of interest frontout_crop Trim(8,-1) frontout_crop_still=last frontout_crop WriteFileIf(last, "frontout_crop.txt", "LumaDifference(frontout_crop, frontout_crop_still)<10", "current_frame")
So you run an analysis pass (e.g. vdub , file=>run video analysis pass) and it will only write to the text file, if the conditions are met. In this case, I have it set to the LumaDifference < 10 between the detection patch , and the video. If it's <10, the it's similar enough to write the frame number. If it's higher, then it's from a different camera feed. You can tweak or adjust the values for the script. This part should be very fast, since we have cropped to the region of interest (low resolution). I've appended the log below
Once you have the log, you can use stickboy's RemapFramesSimple (from remap frames.dll) to "stitch" together the video, using the log file. I've attached what the video sample looks like (Denoised to keep the filesize lower , and framerate slowed down , just for demonstration purposes )
Obviously, if someone walks in front of the fire extinguisher, or something like that, you will get error - it will be detected as "different", and the frame will not be written - so you have to select the patch appropriately. For the "5th" view, something like that $27.99 sign would be good, because nobody is going to "walk" on the ceiling
MPEG2Source("VTS Sample for VideoHelp.d2v") AssumeTFF() Bob() BicubicResize(640,480) RemapFramesSimple(filename="frontout_crop.txt")
You would repeat that for each camera view (each one needs a different, relevant "detection patch" ) .
It's just a proof of concept, you would probably want to use better deinterlacer for example, better image processing filters for the real thing. (But the detection pass can use "fast" filters)
Last edited by poisondeathray; 5th Sep 2014 at 00:50.
Doh! Nevermind. It was just that I had done a "shortcut" and used DirectshowSource() instead of DGIndex+d2v+Mpeg2Source(). Much better!
I'm curious about your concept. You realize there are tons of these securitycam-sequential-multiplexed files out there, just waiting to be fixed by AVISynth. Good time for a new plugin, eh?
...took too long...
If it was a set repeating cadence, then no doubt SelectRangeEvery() or related Select functions like you suggested earlier would be the easiest, fastest way to go. I can't help but to think something was setup incorrectly in this recording (Like where is the 6th feed?) , leading to the screwed up pattern
They call it by different names: Interleaving, Interlacing (ugh!), just Multiplexing, Flipping, Time sequential, Alternating,...
Yeah, those are usually LOCK STEP in a regular pattern. Threw me for a loop, this one.
Good use of thresholding detection as a frame selection tool!
That, and Quad-split or 9x-split are the most common. I have a feeling though, that with DVRs and encoding to AVC (or HEVC in future) that these methods will fall by the wayside. It's easy enough now to create a multi-program TS that incorporates all the views discreetly.
WOW! Incredible how clean it looks, following the suggestions I will attempt to replicate for video and audio. Could anyone see time stamps? if so, how can I see them? I am actually looking for approximately a one hour block of footage of extreme importance.
How do you'all recommend I attempt to analyze the remaining DVD's for the missing feed?
Can you clarify if this is a "regular dvd". ie. can you can insert it in a normal DVD player and will it play, albeit with the speedy switching cameras ? If it's not a "regular dvd" , there might be additional accessory files with metadata
There are no timestamps in that sample VOB (as in event timestamps, like date/time), which is why I asked about it earlier. Normally they are overlaid onto the footage. And there are no subtitles or captions with that info in that sample VOB.
Do you have any more information about the "digitization" process? Details are helpful.
To look for the missing camera feed, I would look at some of the other VOB's in the same manner. You can use avisynth or avidemux as in the procedure described above