Radius Studio Video: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
No edit summary
(fill codec information)
 
(3 intermediate revisions by 2 users not shown)
Line 3: Line 3:
* Samples: [http://samples.mplayerhq.hu/V-codecs/PGVV-RadiusStudio/ http://samples.mplayerhq.hu/V-codecs/PGVV-RadiusStudio/]
* Samples: [http://samples.mplayerhq.hu/V-codecs/PGVV-RadiusStudio/ http://samples.mplayerhq.hu/V-codecs/PGVV-RadiusStudio/]


PGVV is apparently a video codec generated by a piece of software named Radius Studio. A search revealed that it might be "Radius VideoVision Telecast" and using "adaptive JPEG". The claim that it is JPEG should be right as some products claim they can convert losslessly to [[MJPEG-B]].
PGVV is apparently a video codec generated by either the Video Vision hardware grabber card, or with the Radius Studio software. All the brochures and reviews say that it is using an "adaptive JPEG". Probably it means adaptive rate control as described in their patent 5,621,820. It is a slight variation of JPEG.


A quick look at the header of the frames tells the following:
[http://web.archive.org/web/20001008224911/http://radius.com/Products/VideoVisionPCI.html Original product page] on archive.org.
   32bit always zero?
 
   32bit always zero?
There are two versions of the codec known which can be distinguished by 16-bit (big-endian) field at offset 8 of the frame data.
   16bit ? (was 0001)
 
   16bit ? (was 0020)
Version 0 frame header (all values are big-endian):
   32bit ? (was 00000008)
   4 bytes - first field size
   32bit always zero?
  4 bytes - second field size (0 for progressive images)
   32bit ? (an incrementing field, in the only sample: 480, 512, 680, 1284, ...)
  2 bytes - version (0)
  32bit always zero?
  1 byte  - unknown
  32bit always zero?
  1 byte  - quality
  4 bytes - unknown (frame flags?)
 
Version 1 frame header:
   4 bytes - zero
   4 bytes - second field size (0 for progressive images)
   2 bytes - version (0)
   1 byte  - unknown
  1 byte  - quality
  4 bytes - unknown (frame flags?)
   4 bytes - unknown
  4 bytes - first field size
  4 bytes - unknown
   4 bytes - unknown
 
After the header the first field data follows, then padding to multiple of 2048 and the second field data.
 
Field data is almost standard JPEG data organised per macroblock with two luma and two chroma blocks per macroblock. The coefficients are coded almost the same, only chroma DC values are interpreted slightly differently (DC difference bits are stored as sign+value, not as two-complement value).


[[Category:Video Codecs]]
[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]

Latest revision as of 07:00, 30 October 2023

PGVV is apparently a video codec generated by either the Video Vision hardware grabber card, or with the Radius Studio software. All the brochures and reviews say that it is using an "adaptive JPEG". Probably it means adaptive rate control as described in their patent 5,621,820. It is a slight variation of JPEG.

Original product page on archive.org.

There are two versions of the codec known which can be distinguished by 16-bit (big-endian) field at offset 8 of the frame data.

Version 0 frame header (all values are big-endian):

 4 bytes - first field size
 4 bytes - second field size (0 for progressive images)
 2 bytes - version (0)
 1 byte  - unknown
 1 byte  - quality
 4 bytes - unknown (frame flags?)

Version 1 frame header:

 4 bytes - zero
 4 bytes - second field size (0 for progressive images)
 2 bytes - version (0)
 1 byte  - unknown
 1 byte  - quality
 4 bytes - unknown (frame flags?)
 4 bytes - unknown
 4 bytes - first field size
 4 bytes - unknown
 4 bytes - unknown

After the header the first field data follows, then padding to multiple of 2048 and the second field data.

Field data is almost standard JPEG data organised per macroblock with two luma and two chroma blocks per macroblock. The coefficients are coded almost the same, only chroma DC values are interpreted slightly differently (DC difference bits are stored as sign+value, not as two-complement value).