Radius Studio Video: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(Wikify MJPEG-B.)
(fill codec information)
 
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 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. There are some lossless conversion utilities to [[MJPEG-B]], thus it should be very similar to standard JPEG.
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.


[http://web.archive.org/web/20001008224911/http://radius.com/Products/VideoVisionPCI.html Original product page] on archive.org.
[http://web.archive.org/web/20001008224911/http://radius.com/Products/VideoVisionPCI.html Original product page] on archive.org.


A quick look at the header of the frames tells the following:
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.
   32bit always zero?
 
   32bit always zero?
Version 0 frame header (all values are big-endian):
   16bit ? (was 0001)
   4 bytes - first field size
   16bit ? (was 0020)
  4 bytes - second field size (0 for progressive images)
   32bit ? (was 00000008)
  2 bytes - version (0)
   32bit always zero?
  1 byte  - unknown
   32bit ? (an incrementing field, in the only sample: 480, 512, 680, 1284, ...)
  1 byte  - quality
  32bit always zero?
  4 bytes - unknown (frame flags?)
  32bit always zero?
 
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).