Video Forensics Made Easy

Import your CCTV and other footage into VideoFOCUS and quickly reveal the truth.

https://www.salientsciences.com/





This was 11 years ago.

Mass. DAs adopt Salient Stills for crime scene video processing

.

John,

Salient Stills today announced the MDAA - Massachusetts District Attorneys Association - has adopted the company’s video forensics system to secure, capture, and process evidence from crime scene videos. This frees the DAs from relying on other law enforcement agency crime labs to conduct video forensics, and enables seven of the 11 MDAA offices to more quickly process video evidence and advance investigations, arrests and prosecutions.

Background – The MDAA, headquartered in downtown Boston, is an independent state agency that supports the eleven elected Massachusetts District Attorneys and their combined staff of 1,500 employees, who collectively prosecute approximately 300,000 cases annually. Funding for the systems was provided by a U.S. Department of Justice (DOJ) Community Oriented Policing Services (COPS) technology grant.

The official news release is here: http://www.salientstills.com/news/pr-080811.html

SALIENT STILLS SUPPORTS MASSACHUSETTS DISTRICT ATTORNEYS

DAs Conduct Video Forensics With VideoFOCUS Pro

BOSTON, August 8, 2011 - Salient Stills, the leader in video forensics and image enhancement, today announced the Massachusetts District Attorneys Association (MDAA) has licensed VideoFOCUS Pro to seven of the eleven Massachusetts DA offices, enabling its members to conduct hands on video forensics to secure, capture, and process evidence from video samples. Funding for the systems was awarded to the MDAA by a U.S. Department of Justice (DOJ) Community Oriented Policing Services (COPS) technology grant.

More and more investigations and prosecutable cases have videos as part of the evidence. Unfortunately, these videos can be of poor quality, hard to export from proprietary security camera systems, and combined with other video streams, making it difficult to locate, isolate and extract the most helpful sequences and stills, said Pat Alfieri, Chief Information Officer for MDAA. By deploying VideoFOCUS Pro among our members, the DAs and their investigators can quickly process video evidence and advance investigations, arrests and prosecutions.

“Video forensics is a powerful tool for law enforcement agencies, helping them identify suspects and place them at the scene of a crime, establishing a chain of events, and, ultimately, supporting successful prosecutions,” said Laura Teodosio, president and CEO of Salient Stills. “With access to the latest video forensics technology in VideoFOCUS Pro, local DAs can process video faster, freeing time for other important activities.”

MDAA is an independent state agency that supports the eleven elected Massachusetts District Attorneys and their combined staff of 1,500 employees, who collectively prosecute approximately 300,000 cases annually. The agency manages statewide business technology services and administers grants in the areas of Violence Against Women, Motor Vehicle Crimes, and federal technology grants. MDAA also produces publications for prosecutors and victim-witness advocates, hosts dozens of prosecutor trainings annually, and provides information on budgetary, criminal justice and public safety issues to the executive and legislative branches.

Designed for use by law enforcement officers and using innovative processing algorithms, VideoFOCUS Pro dramatically improves the ability to capture and export fuzzy or grainy video from videotape, CCTV systems, digital video cameras, cell phones and proprietary DVR formats. The system generates higher resolution stills and videos to help identify suspects and produce other leads. VideoFOCUS Pro is in use by hundreds of investigative agencies in over 20 countries and throughout the United States.

About Salient Stills
Founded in 1997, Salient Stills is a leading video forensics and image enhancement software company. Salient Stills introduced its technology to answer the need for an efficient and effective video image enhancement solution. VideoFOCUS Pro and VF Source are video forensics solutions in use by law enforcement, security and military and intelligence agencies. For more information on Salient Stills visit www.salientstills.com.

Salient Stills today announced the MDAA - Massachusetts District Attorneys Association - has adopted the company’s video forensics system to secure, capture, and process evidence from crime scene videos. This frees the DAs from relying on other law enforcement agency crime labs to conduct video forensics, and enables seven of the 11 MDAA offices to more quickly process video evidence and advance investigations, arrests and prosecutions.

Background – The MDAA, headquartered in downtown Boston, is an independent state agency that supports the eleven elected Massachusetts District Attorneys and their combined staff of 1,500 employees, who collectively prosecute approximately 300,000 cases annually. Funding for the systems was provided by a U.S. Department of Justice (DOJ) Community Oriented Policing Services (COPS) technology grant.

The official news release is here: http://www.salientstills.com/news/pr-080811.html

I have started an Open Facebook discussion group, Video Technology

Please Join us: 

https://www.facebook.com/groups/608389670074687/

Best Oculus Quest Settings for 360 / VR180 Video Rendering in Premiere/F...

FROM : https://www.youtube.com/watch?v=iBGjn4rmFJU

What are the MAX resolutions and best render settings for 360° and VR180 content creators on the brand new Oculus Quest? This tutorial will give you a step by step guide on how to export your 360VR or 3D 180 videos and sideload them onto Oculus Quest for the best viewing experience with Adobe Premiere OR FFmpeg using both H.264 and H.265 (HEVC). Make sure to stay tuned and subscribe! My full review video for the HOTTEST headset of the year is coming out very soon!

⏰Timestamps for your viewing convenience:
2:57 - all MAX resolutions for Oculus Quest
4:23 - all my MAX 60fps resolutions (beyond Oculus recommendation)
6:12 - how to sideload videos onto Oculus Quest and the best way to play them
9:26 - Premiere rendering workflow with AfterCodecs
12:28 - FFmpeg workflow for BEST quality VR videos

➡️Oculus Quest MAX resolution (official)
360 / 360VR
2880x2880 60fps H264 H265
4096x2048 60fps H264 H265
3840x3840 30fps H264 H265
4096x4096 30fps ---- H265
5120x2560 30fps H264 ----
5760x2880 30fps H264 ----

3D-180 / VR180:
5120x2560 30fps H264 ----
2880x5760 30fps H264 H265

💻The command for monitoring drop frames:
adb logcat -s VideoPlayerAnalytics

💻The command for FFmpeg for 360VR video render:
ffmpeg -y -i "input.mov" -c:v libx265 -preset fast -crf 21 -vf "scale=4096x4096:out_range=full" -pix_fmt yuvj420p -aspect 1:1 -movflags faststart "output.mp4"

💻The command for FFmpeg for VR180 max resolution:
ffmpeg -y -i "input.mov" -c:v libx265 -preset fast -crf 21 -vf "stereo3d=sbs2l:abl, scale=2880x5760:out_range=full" -pix_fmt yuvj420p -aspect 1:2 -movflags faststart "output.mp4"

test videos are available to download here:
http://bit.ly/2MHmHKO
#oculusquest #adobepremiere #360 #vr180 #ffmpeg


Also read:
Encoding High-Resolution 360 and 180 Video for Oculus Quest and Oculus Go [Updated to Include h.265 Support]
  https://creator.oculus.com/blog/encoding-high-resolution-360-and-180-video-for-oculus-go/?locale=en_US

h.264, 30fps (side-by-side 3D-180 video):

ffmpeg -i "input.mp4" -c:v libx264 -preset fast -crf 18 -x264-params mvrange=511 -maxrate 50M -bufsize 25M -vf "scale=5120x2560" -pix_fmt yuv420p -c:a aac -b:a 160k -movflags faststart "output_h264.mp4"

h.265, 30fps (side-by-side 3D-180 video re-arranged to over/under):

ffmpeg -i "input.mp4" -c:v libx265 -preset fast -crf 18 -maxrate 50M -bufsize 25M -vf "stereo3d=sbs2l:abl, scale=2560x5120" -pix_fmt yuv420p -aspect 1:2 -c:a aac -b:a 160k -movflags faststart "output_h265.mp4"




5 Inch Video Card

Huya - the Chinese Twitch.tv : Stream VR Panoramic video live.

https://www.huya.com/

This is a really cool site if you can read Mandarin or have the google translator plugin that will make it english.

Anyhow I just stumbled on this when researching streaming Live 360VR for the Qoocam.  I assume there is a big lag in it. 

What is Huya Live

Huya live broadcast is a barrage interactive live broadcast platform that young people like. It mainly focuses on interactive live broadcast of games, and continues to introduce a variety of live broadcast content, such as e-sports live broadcast, outdoor live broadcast, entertainment interactive live broadcast, etc., to provide users with quality live broadcast viewing Experience. At present, Huya Live is supported by professional e-sports teams 4AM, TYLOO, 619, YTG, 1246, and well-known popular anchors Wei Shen, Miss, Uzi, Sao Nan, etc. Uninterrupted throughout the year, continue to provide players with a wonderful live broadcast feast!

How to watch live games on Huya Live?

1. Log in to www.huya.com with a browser on your computer , watch live chatter on the big screen, and enjoy a lively interactive feeling.

2, mobile phone download eye teeth live APP , anytime, anywhere, want to see, wonderful live in your palm.

This VR watch live, Watch panorama live.  

How do you conveniently get this in to your VR headset I have no idea. 

VR180 "VR Ready" cameras.

https://arvr.google.com/vr180/ 

Looking for the specs,

Protocols,  maybe a wireshark tcpdump of a clear text session 

 Can it be simulated from a pi with a t265 Intel realsense tracking camera with 2 perfectly eye spaced 175deg wide angle cameras?

Or some code libraries to connect into one?

--

John Sokol

http://johnsokol.com

669-500-2329

john.sokol@gmail.com

VR180 Open Source Tools

NOTE: I am still looking and updating.  Let me know if you have anything I should add.

180 Stereo Photo Viewer

A VR180 photo viewer that works on a web browser.

You can try it here. https://chiqden.github.io/180-stereo-photo-viewer/

Supported photo formats
VR180 photos (vr.jpg)
180 stereo side by side photos

A VR180 photo viewer that works on a web browser.
https://github.com/chiqden/180-stereo-photo-viewer

based on A-Frame

VR180

NOTE: I am still updating this page.

How to publish VR180

https://www.blog.google/products/google-vr/how-publish-vr180/

VR180: NEW FORMAT AIMS TO EXPAND IMMERSIVE MARKET

VR180 Creator

Introducing VR180 Creator, simplifying the video editing process

VR180 cameras allow creators to shoot three-dimensional, immersive photos and videos using affordable cameras that are small enough to fit in your pocket.

And to make it even easier for you to create and edit high quality VR videos, we’re launching VR180 Creator on Mac and Linux. This desktop tool lets anyone edit VR180 footage with existing VR video tools.

VR180 Creator currently offers two features for VR videos. “Convert for Publishing” takes raw fisheye footage from VR180 cameras like the Lenovo Mirage Camera and converts it into a standardized equirect projection. This can be edited with the video editing software creators already use, like Adobe Premiere and Final Cut Pro. “Prepare for Publishing” re-injects the VR180 metadata after editing so that the footage is viewable on YouTube or Google Photos in 2D or VR.



Convert your VR180 footage into a standardized format so you can edit it with leading editing tools like Adobe Premiere and then re-inject the appropriate metadata for publishing.

https://arvr.google.com/vr180/apps/   DOWNLOAD HERE



VR180 Creator release notes
https://support.google.com/vr180/answer/9049949


Google’s VR180 Creator Tool Makes it Easier to Edit VR Video on Linux
https://www.omgubuntu.co.uk/2018/06/google-vr180-creator


https://itsfoss.com/vr180-creator/

https://fstoppers.com/originals/introduction-vr180-format-440235

DNxHR was listed as an output option instead of mpeg4. This is something I wasn't familiar with.
I have yet to try it on anything.

Avid DNxHR, which stands for "Digital Nonlinear Extensible High Resolution", is a lossy UHDTV post-production codec 
https://en.wikipedia.org/wiki/DNxHR_codec

Cameras

 Z-Cam

http://www.z-cam.com/180-vr-camera-k1-pro/

Kandao qoocam

VR180 Video Format

1. Introduction

VR180 cameras are a new category of VR camera that use two wide angle cameras to capture the world as you see it with point and shoot simplicity. This document describes the video format output by these devices. The choice considers the following aspects:

FOV: VR180 cameras capture sub-360 FOV rather than full 360. It is important to retain the original pixel density of the camera sensors in order to provide high pixel density for VR viewing.
Projection: Different versions of VR180 cameras may have different lens and different camera projections. As such the file format should be camera-independent.
Motion: The cameras can often be non-stationary due to unintentional shakes or intentional motion, for example, handheld capture of events or people. To avoid motion sickness, camera motion metadata should be saved for stabilized playback.
Playback: The file format should be friendly enough for local playback so that manufacturers can easily build their apps. Android and iOS should have an easy way to play the raw video.
VR180 videos contain two types of metadata to jointly define the projection from video frames to their partial viewports within a spherical coordinate system.

A global static projection that defines the mapping from the pixels to local spherical coordinate systems, typically to only a sub-180 FOV part. The Spherical Metadata V2 Spec is adopted here to encode this global metadata. (See details in section 2).
A dynamic orientation stream that defines the rotation between the local coordinate system of each frame and the world coordinate system. A new Camera Motion Metadata track is created for encoding such per-frame metadata. (See section 3).

https://github.com/google/spatial-media/blob/master/docs/vr180.md

Spherical Video V2 RFC

This document describes a revised open metadata scheme by which MP4 (ISOBMFF) and WebM (Matroska) multimedia containers may accommodate spherical videos. Comments are welcome by discussing on the Spatial Media Google group or by filing an issue on GitHub.

Metadata Format
MP4 (ISOBMFF)
Spherical video metadata is stored in a new box, sv3d, defined in this RFC, in an MP4 (ISOBMFF) container. The metadata is applicable to individual video tracks in the container. Since many spherical videos are also stereoscopic, this RFC also defines an additional optional box, st3d, to specify metadata specific to stereoscopic rendering.

As the V2 specification stores its metadata in a different location, it is possible for a file to contain both the V1 and V2 metadata. If both V1 and V2 metadata are contained they should contain semantically equivalent information, with V2 taking priority when they differ.

Stereoscopic 3D Video Box (st3d)

https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md

Speech Warping and Audio Restoration - Speech Gender Conversion

From May 5, 2011

http://www.mattmontag.com/projects/speech-warping-and-audio-restoration/

Matt Montag - EEN 540 Speech Signal Processing - Project 3

MATLAB Files

proj3.m project script
pad.m utility function to make two vectors match in size
fftplot.m utility function
averageLogSpectrum.m utility function to compute average log spectrum

Speech Gender Conversion

http://www.mattmontag.com/development/speech-gender-conversion

Barack Obama	obama.wav	obama_to_female.wav	obama_to_child.wav
Sarah Palin	palin.wav	palin_to_male.wav	palin_to_female.wav
Katie Couric	couric.wav	couric_to_male.wav
Al Gore	algore.wav	algore_to_female.wav	algore_to_child.wav
Hip-Hop	turnstiles.wav	turnstiles_to_child.wav

Nreal Augmented Reality Glasses Developer Kit Review!

StereoPi review (English version)

StereoPi board review. A a stereoscopic digital camera board based on the Raspberry Pi http://StereoPi.com

ProEar™ - The Official Home of the Ear Endoscope

https://proear.co/

This is basically a usb webcam that has a camera the end of a pen.

This could be useful for all sorts of things. 

Fwd: Face recognition Temperature Measurement Terminal

---------- Forwarded message ---------

This high-precision detection algorithm can detect the body temperature whether wearing a mask or not.It integrates image acquisition, face detection, face tracking and face contrast, and human body temperature detection. 1 second detection speed.

Voice broadcast temperature,LED light turn red if temperature is not normal.

Each Entrance can install this machine (Hotel,CBD building,school,shopping mall,bus station,apartment.....)

On computer we can check lastest 10,000 records

Also can use as face recognition punch in and punch out machine.Avoid touching

---

Ching Deng

Masrui Technology (HK) Co., Ltd. 

Shenzhen Masrui Technology Co., Ltd. 

M(Wechat/WhatsApp): +86 13652367942

Email: chingdeng@masrui.com.cn | sales2@masrui.com 

Skype:masrui99

https://masrui.en.alibaba.com

http://www.masrui.com

 

The first no-headset virtual monitor | Barmak Heshmat | TEDxKC

What Is CoaXPress? | Vision Campus

https://www.baslerweb.com/en/vision-campus/interfaces-and-standards/what-is-coaxpress/ 

CoaXPress | CXP

The CoaXPress (CXP) standard was originally launched by various companies in the industrial image processing sector.

The CoaXPress (CXP) standard was originally launched by various companies in the industrial image processing sector. The goal was to develop a fast data interface that also made it possible to bridge a large data volume across greater distances. The first CoaXPress interfaces were introduced at "Vision", the leading trade fair for industrial image processing in 2008 in Stuttgart. After three more years of development, CXP 1.0 was officially released as a standard in 2011. Since then, the standard has established itself in industrial image processing. This standard was then developed further, into CoaXPress 2.0. An interface with the CoaXPress 1.0/1.1 standard supports data rates as high as 6.25 Gbps. The transmission speed of the CoaXPress 2.0 standard is twice as high, at up to 12.5 Gbps. This allows for even higher resolutions and frame rates compared to other efficient standards. In contrast to the preceding interface, the new standard only needs half as many cables to transfer the same amount of data.

Thanks to the combined triggering and power supply (power over CXP), only one CoaXPress cable is needed, which can have a maximum cable length of 40 meters – another benefit of this update.

Exact Recompression

Is it possible to "reverse engineer" a compressed lossy image or audio file?


By this, instead of re-encoding and incurring more compression artifacts is it possible to work out what the original compressed data looks like and repacket back in to the original compressed file without any loss or degradation?


A researcher at Cambridge was able to revert a decompressed bitmap to a JPEG source, covered by this paper on Exact JPEG recompression. The authors are able to recover the compression parameters (quantized DCT coefficients) for 96% of the blocks** in images compressed at a JPEG quality of 75%. 

https://micrological.appspot.com/cl-web/spie10-full.pdf

Exact JPEG recompression

 Andrew B. Lewis, Markus G. Kuhn 

Computer Laboratory, University of Cambridge, 

ABSTRACT 

We present a variant of the JPEG baseline image compression algorithm optimized for images that were generated by a JPEG decompressor. It inverts the computational steps of one particular JPEG decompressor implementation (Independent JPEG Group, IJG), and uses interval arithmetic and an iterative process to infer the possible values of intermediate results during the decompression, which are not directly evident from the decompressor output due to rounding. We applied our exact recompressor on a large database of images, each compressed at ten different quality factors. At the default IJG quality factor 75, our implementation reconstructed the exact quantized transform coefficients in 96% of the 64-pixel image blocks. For blocks where exact reconstruction is not feasible, our implementation can output transform-coefficient intervals, each guaranteed to contain the respective original value. Where different JPEG images decompress to the same result, we can output all possible bit-streams. At quality factors 90 and above, exact recompression becomes infeasible due to combinatorial explosion; but 68% of blocks still recompressed exactly. 

Matt Montag discussed the possiblity of doing this with MP3.
http://www.mattmontag.com/research/exact-mp3-recompression


I am sure it should be possible to train neural networks to be able to effectively do this. 

1910 postcard depiction of video telephony as imagined in the year 2000

SHOWRUNNER video warping and video mapping control software.

Sun Microsystems - CELL-B encoding from 1992

https://github.com/johnsokol/holiday_greeting_1992

holiday_greeting_1992

Sun Micro Systems - Scott McNealy , First Global Internet Stream December 1992.

I need a old copy of Solaris 2.4 or 2.5 on a SparkStation or emulator to capture an Mpeg4 of this.



We tried QEMU and the video played, but no audio...



player will play TESTME or holliday greeting 1992 files out to local audio and standard Xwindow.

Still looking for the source code for these, but it's been lost in time. 

This should be a precursor to : Sun's CellB Video Encoding rfc2029

https://tools.ietf.org/html/rfc2029  October 1996

https://tools.ietf.org/html/draft-ietf-avt-profile-06

"CellB, derived from CellA, has been optimized for network-based video applications. It is computationally symmetric in both encode and decode. CellB utilizes a fixed colormap and vector quantization techniques in the YUV color space to achieve compression."




https://tools.ietf.org/html/rfc1890



5.1 CelB


   The CELL-B encoding is a proprietary encoding proposed by Sun
   Microsystems.  The byte stream format is described in work in
   progress [12].  The author can be contacted at

   Michael F. Speer
   Sun Microsystems Computer Corporation
   2550 Garcia Ave MailStop UMPK14-305
   Mountain View, CA 94043
   United States
   electronic mail: michael.speer@eng.sun.com

  [] M. F. Speer and D. Hoffman, "RTP payload format of CellB video
       encoding," Work in Progress, Internet Engineering Task Force,
       Aug.  1995.





https://tools.ietf.org/html/draft-ietf-avt-profile-04   March 24, 1995

It is not permissible to use distinct payload types to multiplex several media concurrently onto a single RTP session (e.g., to concurrently send PCMU audio and CelB video over the same RTP session). Some payload types may designate a combination of both audio and video, both within the same packet or differentiated by information within the payload. Currently, the MPEG Transport encapsulation is the only such payload type. 


     CelB: The CELL-B encoding is a proprietary encoding proposed by Sun
          Microsystems. The byte stream format is described in RFC TBD.


Source code was published in the drafts, but later removed, 
Upon further investigation there are 2 version of the code, but other then doing 
variable cleanup like u_char is now U_INT8 not much has changed. 

draft-ietf-avt-cellb-05.txt 
draft-ietf-avt-cellb-06.txt  
draft-ietf-avt-cellb-profile-01.txt  This is the only one that mentions NetVideo. 
draft-ietf-avt-cellb-profile-02.txt  
draft-ietf-avt-cellb-profile-03.txt    (all the rest are the same code) 


This code after resolving countless build issues is missing the tables making it almost unusable

as is, although there are Sun documents that explain the format. 

but finding working code is way faster then reconstruction a dead format from what looks

 like an incomplete set of specifications. 


I found the source code for the CellB codec in VIC,
 a Lawrence Berkeley National Labs , White board and video conferencing Application done in 1993/4

decoder-cellb.cc
encoder-cellb.cc
cellb_tables.c

I later also found a copy in the source code for NV will I will soon post a link for.

ViewPoint Compressed Packet Video (CPV)

Doing a little but of code Archaeology on old video conferencing code from 25 years ago.

Ran across an Interesting codec I wasn't familiar with.  CPV


In the early days the same codec keep getting referenced, some like JPEG and H.261 are ubiquitous and still around.  Others like CPV, NV, PicW are still mysteries at least to me and about to be forgotten in time.


     CelB: The CELL-B encoding is a proprietary encoding proposed by Sun
          Microsystems. The byte stream format is described in RFC TBD.

     CPV: This proprietary encoding, "Compressed Packet Video is  imple-
          mented by Concept, Bolter, and ViewPoint Systems video codecs.
          For further information, contact:  Glenn Norem, President
          ViewPoint Systems, Inc.
          2247 Wisconsin Street, Suite 110
          Dallas, TX 75229-2037
          United States
          Phone: +1-214-243-0634

     JPEG: The encoding  is  specified  in  ISO  Standards  10918-1  and
          10918-2. The RTP payload format is as specified in RFC TBD.


     H261: The encoding is specified in CCITT/ITU-T standard H.261.  The
          packetization and RTP-specific properties are described in RFC
          TBD.

     HDCC: The HDCC encoding is a proprietary encoding used  by  Silicon
          Graphics. Contact

          inperson@sgi.com for further details.

     MPV: MPV designates the use MPEG-I and MPEG-II video encoding  ele-
          mentary  streams  as  specified in ISO Standards ISO/IEC 11172
          and 13818-2, respectively. The RTP payload format is as speci-
          fied in RFC TBD, Section 3.

     MP2T: MP2T designates the use of  MPEG-II  transport  streams,  for
          either  audio  or video. The encapsulation is described in RFC
          TBD, Section 2.

     nv:  The encoding is implemented in the program 'nv'  developed  at
          Xerox PARC by Ron Frederick.

     CUSM: The encoding is implemented in the program CU-SeeMe developed
          at  Cornell  University by Dick Cogger, Scott Brim, Tim Dorcey
          and John Lynn.

     PicW: The encoding is  implemented  in  the  program  PictureWindow
          developed at Bolt, Beranek and Newman (BBN).

https://tools.ietf.org/html/draft-ietf-avt-profile-00  December 15, 1992

Internet Engineering Task Force          Audio-Video Transport Working Group
INTERNET-DRAFT                                                H. Schulzrinne
                                                      AT&T Bell Laboratories
                                                           December 15, 1992
                                                            Expires:  5/1/93


   Sample Profile for the Use of RTP for Audio and Video Conferences with
                              Minimal Control


                               _number__name_
                                31      H261
                                30      Bolt
                                29      dvc
                                28      nv


                     Table 2:  Default Video Encodings

Bolt is Bolter - CPV

V2 of this document extended to: 

                               _number__name_
                                31      H261
                                30      Bolt
                                29      PicW
                                28      nv
                                27      CUSM
                                26      JPEG


                     Table 2:  Standard Video Encodings

I just got a hold of the NV source code.  (Xerox Park, Net Video _ which is plan to make sure it's available somewhere on github.

https://tools.ietf.org/html/draft-ietf-avt-profile-03  October 20, 1993

CPV: This encoding, "Compressed Packet Video" is implemented by Concept, Bolter, and ViewPoint Systems video codecs.

RFC 1890                       AV Profile                   January 1996


      PT         encoding      audio/video    clock rate    channels
                 name          (A/V)          (Hz)          (audio)
      _______________________________________________________________
      0          PCMU          A              8000          1
      1          1016          A              8000          1
      2          G721          A              8000          1
      3          GSM           A              8000          1
      4          unassigned    A              8000          1
      5          DVI4          A              8000          1
      6          DVI4          A              16000         1
      7          LPC           A              8000          1
      8          PCMA          A              8000          1
      9          G722          A              8000          1
      10         L16           A              44100         2
      11         L16           A              44100         1
      12         unassigned    A
      13         unassigned    A
      14         MPA           A              90000        (see text)
      15         G728          A              8000          1
      16--23     unassigned    A
      24         unassigned    V
      25         CelB          V              90000
      26         JPEG          V              90000
      27         unassigned    V
      28         nv            V              90000
      29         unassigned    V
      30         unassigned    V
      31         H261          V              90000
      32         MPV           V              90000
      33         MP2T          AV             90000
      34--71     unassigned    ?
      72--76     reserved      N/A            N/A           N/A
      77--95     unassigned    ?
      96--127    dynamic       ?

   Table 2: Payload types (PT) for standard audio and video encodings

From NV 2.7 code and similar in the 3.2 tree.

more bolter_decode.h

/****************************************************************************//*  bolter_decode.h -- Return codes from Bolter_Decode subroutine           *//****************************************************************************/
#define VxSUCCESS       0       /* Packet successfully decoded */#define VxEXTRAPIXEL    1       /* Extra pixel past end of pixmap */#define VxBADADDRESS    2       /* Bad address in video data */#define VxUNTERMINATED  3       /* Packet not terminated */#define VxBADHEADER     4       /* Bad video header format */#define VxBADLENGTH     5       /* Unreasonable packet length */#define VxNONMOTION     6       /* Non-motion video packet found */
src/nv.c:#ifdef BOLTERsrc/nv.c:           (void) Bolter_Decode(source[i].image, packet+8, len-8);src/nv.c:#endif BOLTER

From NV (Xerox Park, Net Video version 3.3)
There are Binary object for it.

7592 Feb 22  1994 cpv_decode-alpha.o
2849 Nov  1  1994 cpv_decode-bsdi.o
4176 Feb 18  1994 cpv_decode-dec5k.o
3120 Feb 18  1994 cpv_decode-hp.o
4112 Feb 17  1994 cpv_decode-irix4.o
5156 Mar  7  1994 cpv_decode-irix5.o
2764 Feb 17  1994 cpv_decode-sunos4.o
4132 Mar  7  1994 cpv_decode-sunos5.o

/src/cpv.h Feb 3, 1994

/****************************************************************************/
/*                                                                          */
/*      cpv.h -- Return codes from CPV_Decode subroutine to decode          */
/*      Concept/Bolter/ViewPoint Compressed Packet Video (CPV) (TM)         */
/*                                                                          */
/****************************************************************************/
/*                                                                          */
/*      Copyright (c) 1994 by the University of Southern California.        */
/*      All rights reserved.                                                */
/*                                                                          */
/*      COMMERCIAL USE OF THIS CODE IS STRICTLY PROHIBITED WITHOUT THE      */
/*      SPECIFIC PRIOR WRITTEN AUTHORIZATION OF VIEWPOINT SYSTEMS, INC.     */
/*      de-CPV-ware(TM), CPV(TM), and Compressed Packet Video(TM) are       */
/*      trademarks of VIEWPOINT SYSTEMS, INC., 2247 Wisconsin Street        */
/*      #110, DALLAS, TEXAS 75229                                           */
/*                                                                          */
/*      Permission to use, copy, and distribute this software and its       */
/*      documentation in binary form for non-commercial purposes and        */
/*      without fee is hereby granted, provided that the above copyright    */
/*      notice appears in all copies, that both the copyright notice and    */
/*      this permission notice appear in supporting documentation, and      */
/*      that any documentation, advertising materials, and other            */
/*      materials related to such distribution and use acknowledge that     */
/*      the software was developed by the University of Southern            */
/*      California, Information Sciences Institute.  The name of the        */
/*      University may not be used to endorse or promote products derived   */
/*      from this software without specific prior written permission.       */
/*                                                                          */
/*      THE UNIVERSITY OF SOUTHERN CALIFORNIA makes no representations      */
/*      about the suitability of this software for any purpose.  THIS       */
/*      SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED     */
/*      WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES   */
/*      OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.            */
/*                                                                          */
/*      Other copyrights might apply to parts of this software and are      */
/*      so noted when applicable.                                           */
/*                                                                          */
/****************************************************************************/
/*                                                                          */
/*      This software decompression function is also known as               */
/*      "de-CPV-ware", Version 1.0.                                         */
/*                                                                          */
/****************************************************************************/
/*                                                                          */
/*      Author:           Stephen Casner, casner@isi.edu                    */
/*                        USC Information Sciences Institute                */
/*                        4676 Admiralty Way                                */
/*                        Marina del Rey, CA 90292-6695                     */
/*                                                                          */
/****************************************************************************/
/*                                                                          */
/*      Programming Interface                                               */
/*                                                                          */
/*      int CPV_Decode(image, pktptr, pktlen)                               */
/*          struct vidimage {      Output image arrays CPV_WIDTHxCPV_HEIGHT */
/*              unsigned char *y_data;    Pixel luminance image             */
/*              char *uv_data;            Pixel chrominance image           */
/*              short width, height;      Size of pixel image               */
/*                                        Other stuff here that we ignore   */
/*          } *image;              Pointer to output image array struct     */
/*          unsigned char *pktptr; Pointer to start of video data in packet */
/*          int pktlen;            Length of video data as received         */
/*                                                                          */
/*      The caller is responsible for allocating the image output           */
/*      arrays y_data and uv_data; these arrays continuously maintain       */
/*      the output image as it is updated for each call.  For each          */
/*      call, one packet of compressed video data is decompressed and       */
/*      written as Y and UV pixels at the addressed locations in the        */
/*      y_data and uv_data output arrays.  The image is in "4:2:2"          */
/*      format; that is, for each horizontal pair of Y pixels there is      */
/*      one U and one V pixel that together form the chrominance shared     */
/*      by both Y pixels.  The conversion from the encoding of video        */
/*      data in the packet to Y and UV pixels is accomplished with          */
/*      lookup tables indexed by an RGB value of 5 bits each.  These        */
/*      tables occupy a total of 98304 bytes.  These lookup tables may      */
/*      be supplied by the caller in the two arrays:                        */
/*                                                                          */
/*      extern unsigned char rgb2y[32768];     RGB to Y or B&W table    */
/*      extern unsigned short rgb2uv[32768];   RGB to U & V table       */
/*                                                                          */
/*      Or, if this module is compiled with FIRST_ENTRY defined,            */
/*      static arrays will be allocated and on the first call tables        */
/*      values will be calculated.                                          */
/*                                                                          */
/*      For each rectangular area of the image which has been updated,      */
/*      a call is made to the following routine to allow the caller to      */
/*      further process and display those parts of the image:               */
/*                                                                          */
/*      extern void VidImage_UpdateRect(image, x, y, width, height);        */
/*          struct vidimage *image; Pointer to output image array struct    */
/*          int x,y;                Offsets of area within image (left,top) */
/*          int width,height;       Size of update area in pixels           */
/*                                                                          */
/*      The return value from CPV_decode is an integer success/failure      */
/*      code.                                                               */
/*                                                                          */
/****************************************************************************/

#define CPV_SUCCESS     0       /* Packet successfully decoded */
#define CPV_EXTRAPIXEL  1       /* Extra pixel past end of pixmap */
#define CPV_BADADDRESS  2       /* Bad address in video data */
#define CPV_UNTERM      3       /* Packet not terminated */
#define CPV_BADHEADER   4       /* Bad video header format */
#define CPV_BADLENGTH   5       /* Unreasonable packet length */
#define CPV_NONMOTION   6       /* Non-motion video packet found */

#define CPV_WIDTH       256
#define CPV_HEIGHT      200

extern int CPV_Decode(vidimage_t *image, unsigned char *data, int len);

x