MJPEG Encoder Research, no questions here

Martin Koch · Jun 14, 2010

Downloaded an original 720p MJPEG clip from vimeo (clip 12515307) with the following settings:

Quality settings (E1 to E4) - 352, 220, 200, 184
Table settings (E1 to E4) - 24, 24, 24, 24

MediaInfo says 54.5 Mbps

Code:

JPEGsnoop 1.2.0 by Calvin Hass
  www.impulseadventure.com/photo/
  -------------------------------

  Filename: [C:\WINDOWS\Desktop\tester13\720p MJPEG.mov]
  Filesize: [292424830] Bytes

Start Offset: 0x00007F00
*** Marker: SOI (xFFD8) ***
  OFFSET: 0x00007F00
 
*** Marker: DQT (xFFDB) ***
  Define a Quantization Table.
  OFFSET: 0x00007F02
  Table length = 132
  ----
  Precision=8 bits
  Destination ID=0 (Luminance)
    DQT, Row #0:   2   2   2   2   5   4   9   9 
    DQT, Row #1:   2   2   2   2   4   7   9   9 
    DQT, Row #2:   2   2   4   4   4   7  12  11 
    DQT, Row #3:   2   4   4   5   9  11  16  16 
    DQT, Row #4:   2   4   5   9  11  12   9  18 
    DQT, Row #5:   7   5   9  11  12  16  12  16 
    DQT, Row #6:   4  11  14  12  16  18  16  14 
    DQT, Row #7:  11  12  14  14  18  18  16  16 
    Approx quality factor = 92.07 (scaling=15.85 variance=15.32)
  ----
  Precision=8 bits
  Destination ID=1 (Chrominance)
    DQT, Row #0:   4   2   4   4  16  16  16  16 
    DQT, Row #1:   4   4   7   9  16  16  16  16 
    DQT, Row #2:   4   7  11  16  16  16  16  16 
    DQT, Row #3:   4  16  16  16  16  16  16  16 
    DQT, Row #4:  11  16  16  16  16  16  16  16 
    DQT, Row #5:  16  16  16  16  16  16  16  16 
    DQT, Row #6:  16  16  16  16  16  16  16  16 
    DQT, Row #7:  16  16  16  16  16  16  16  16 
    Approx quality factor = 91.74 (scaling=16.51 variance=8.99)
 
*** Marker: SOF0 (Baseline DCT) (xFFC0) ***
  OFFSET: 0x00007F88
  Frame header length = 17
  Precision = 8
  Number of Lines = 720
  Samples per Line = 1280
  Image Size = 1280 x 720
  Raw Image Orientation = Landscape
  Number of Img components = 3
    Component[1]: ID=0x01, Samp Fac=0x22 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y)
    Component[2]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cb)
    Component[3]: ID=0x03, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cr)

vladszp · Jun 16, 2010

http://www.dpreview.co.uk/maint/print.asp?type=reviews&content=nikond2x&page=13
anything beyond quality factor 90 is just a waste of bitrate....
http://www.impulseadventure.com/photo/images/quality_irfan.gif
the big one...

Vitaliy Kiselev · Jun 16, 2010

vladszp said:
http://www.dpreview.co.uk/maint/print.asp?type=reviews&content=nikond2x&page=13
anything beyond quality factor 90 is just a waste of bitrate....
http://www.impulseadventure.com/photo/images/quality_irfan.gif
the big one...

OK, and how this relate to MJPEG encoder research?
Quality factor is just subjective number made from Q table.
Any Q table is used to remove some DCT info.
So, it is never waste of space.
If anyone shoots highly detailed nature scenes even very high quality JPEG images can show artefacts.

Grunf · Jun 23, 2010

Hello!

I just noticed one thing you might find interesting: entry "MJPEG Encoder 30fps->Xfps" is somehow affecting AVCHD recording as well.

I use AVCHD Bitrate "C" settings and it works perfectly in 1080p25 ("Native 24/25p" enabled). But as soon as I enable "MJPEG Encoder 30fps->Xfps" with "25" as entry (I live in PAL country), I get problems with AVCHD and camera stops recording after couple of seconds. MJPEG recording works (MJPEG bitrate was tuned to "manageable" levels I know camera would support, like 60Mbit or so) but it's able to record only couple of seconds at the time. It will record for longer time but as soon as I stop recording, it will hang for 10 secs and then ask me to reboot the camera by switching on/off.

Keeping "MJPEG Encoder 30fps->Xfps" unchecked will let AVCHD work. Checking it will make AVCHD fail with same bitrate.

Hypotesis: "MJPEG Encoder 30fps->Xfps" set to 25 seems to be affecting more than MJPEG.

cbrandin · Jun 24, 2010

I think you're on to something. If I set both the 30fps->24fps, and the 30fps->Xfps to 24, and nothing else, StreamEye displays the video on a split screen with squashed versions of the clip on the top and bottom of the screen. Windows Media Player, however, shows it correctly. Obviously something changed that StreamEyE deals with differently than Media Player.

Chris

Martin Koch · Jun 25, 2010

All tests are made with
GH1 + 20 mm 1.7 pancake in M and manual focus mode
Shutter 1/50, Arperture f5.0, ISO 100
STANDARD -2, -2, -2, -2
Card: 16 GB Sandisk Extreme Class 10 card

JPEGSnoop doesn’t work reliable with alalyzing the GH1 MJPEG files so the 1280 x 720 JPEG thumbnail that accompanies any movie file was analyzed. As Vitaliy already said those thumbnails have the very same compression quality applied as the movie file. The only lossy process in (M)JPEG compression is the quantisation step after the Discrete Cosinus Transformation (DCT). Low values in the 8 x 8 Quantisation Tables result in higher image quality. A low detail scene and a high detail scene was recorded for each setting and the JPEGSnoop quality factor as well as the bitrate was noted.

Setting quality only

Code:

QUESTION: Does setting quality alone affect quantisation table?
ANSWER: No

FACTORY SETTINGS Firmware 1.32
Q: Factory (128, 110, 100, 92)
T: Factory (133, 146, 150, 155)
Low detailed scene: 83.09
High detailed scene: Only 19.16 !!!
Playback in camera: YES

REVERSED quality settings Firmware 1.33
Q: 92, 100, 110, 128
T: Factory (133, 146, 150, 155)
Low detailed scene: 83.09
High detailed scene: 19.16
Playback in camera: YES

EQUAL quality settings Firmware 1.34
Q: 128, 128, 128, 128
T: Factory (133, 146, 150, 155)
Low detailed scene: 83.09
High detailed scene: 19.16
Playback in camera: YES

CONCLUSION
Setting Quality alone has no effect on quantisation table used
Camera chooses very high compression for high detailed scenes.
GH1 uses a variable MJPEG compression to avoid too high bitrates on high detailed scenes. Low detailed scene scenes are less compressed. High detailed scene ones more.

Setting table only

Code:

QUESTION: Do table settings affect quantisation table?
ANSWER: Absolutely

FACTORY SETTINGS Firmware 1.32
Q: Factory (128, 110, 100, 92)
T: Factory (133, 146, 150, 155)
Low detailed scene: 83.09 / 8 mbps
High detailed scene: only 19.16 !!! / 37 mbps
Playback in camera: YES
Note: Very high compression on high detailed scene to bring data rate down to 37 mbps. 

REVERSED TABLE FACTORY SETTINGS Firmware 1.35
Q: Factory (128, 110, 100, 92)
T: 155, 150, 146, 133
Low detailed scene: 80.06
High detailed scene: 19.16 
Playback in camera: YES
Note: no effect

EQUAL TABLE SETTINGS Firmware 1.36
Q: Factory (128, 110, 100, 92)
T: 133, 133, 133, 133
Low detailed scene: 83.09 / 0.6 mbps
High detailed scene: 19.16 / 35.7 mbps
Playback in camera: YES
Note: no effect

LOW TABLE SETTINGS Firmware 1.37
Q: Factory (128, 110, 100, 92)
T: 24, 24, 24, 24
Low detailed scene: 97.33 / 28 mbps !!!
High detailed scene: 19.16 / 35.7 mbps
Playback in camera: YES
Note: Only compression of low detail scene  is improved

LOWEST TABLE SETTINGS Firmware 1.38
Q: Factory (128, 110, 100, 92)
T: 0, 0, 0, 0
Low detailed scene: 100!!! / 62 mbps / Movie OK
High detailed scene: 100!!! / 63 mbps / Movie is black!!!
Playback in camera: NO!!!
Note: “Lossless”, Luma and Chroma quantisation tables are filled with the number one

2,2,2,2 TABLE SETTING Firmware 1.39
Q: Factory (128, 110, 100, 92)
T: 2, 2, 2, 2
Low detailed scene: 100!!! / 60 mbps  / Movie OK
High detailed scene: 79 / 63 mbps  / Movie is black
Playback in camera: NO
Note: Camera starts to increase compression on high detailed scene. 

4,4,4,4 TABLE SETTING Firmware 1.40
Q: Factory (128, 110, 100, 92)
T: 4, 4, 4, 4
Low detailed scene: 98 / 52 mbps  / Movie OK
High detailed scene: 56 / 63 mbps  / Movie OK
Playback in camera: NO
Note: Even more compression on high detailed scene

5,5,5,5 TABLE SETTING Firmware 1.41
Q: Factory (128, 110, 100, 92)
T: 5, 5, 5, 5
Low detailed scene: 98 / 37 mbps  / Movie OK
High detailed scene: 45 / 56 mbps  / Movie OK
Playback in camera: LOW: YES, HIGH: NO
Note: max. clip length with this settings: 7 minutes - 2 GB

CONCLUSION
Table settings have direct influence on the quantisation table used. With 5,5,5,5 low detailed scene compression quality is very good (98). For high detailed scenes the camera still chokes the bitrate by choosing a lower quality quantisation table but quality improves from 19 - 37 mbps to 45 - 56 mbps.
Only low detail scenes play back in camera. There seems to be a limit around 37 mbps with my card. Clips below this limit play back fine.

Setting quality and table

Code:

QUESTION: Is the quality settings sequence “128,110,100,92” the bitrate choke?
ANSWER: It seems so. Doubling the values makes the bitrate choke less aggressive and allows lower compression of high detailed scenes

NO CHOKE? QUALITY SETTING Firmware 1.42
Q: 128, 128, 128, 128
T: 5, 5, 5, 5
Low detailed scene: 98 / 37 mbps  / Movie OK
High detailed scene: 44 / 56 mbps  / Movie OK
Playback in camera: NO
Note: Fail. Has no effect on quantisation table chosen

DOUBLED QUALITY / T5 SETTING Firmware 1.43
Q: 256, 220, 200, 184
T: 5, 5, 5, 5
Low detailed scene: 100!!! / 61!!! mbps  / Movie OK
High detailed scene: 86!!! / 88!!! mbps  / Movie OK
Playback in camera: NO
4:2:0 chroma subsampling
Note: Excellent low detail and better high detail compression

4:2:2 + DOUBLED Q / T5 SETTING Firmware 1.44
Q: 256, 220, 200, 184
T: 5, 5, 5, 5
Low detailed scene: 100 / 67 mbps  / Movie OK
High detailed scene: 82 / 77 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: NO
Note: Not much difference. Camera seems to record fine.
max. Individual clip length with these settings: about 4 minutes - 2 GB 
16 GB card will store 32 minutes of footage.
Real live scenes show 92 / 70 mbps

PappasArts + 4:2:2 SETTING Firmware 1.46
Q: 384, 330, 300, 276
T: 24, 24, 24, 24
Low detailed scene: 97 / 34 mbps  / Movie OK
High detailed scene: 81 / 75 mbps  / Movie recording stopped after 3s!!!
4:2:2 chroma subsampling
Playback in camera: LOW: YES, HIGH: NO
Note: No improvement over DOUBLED Q / T5 SETTING plus camera failed to record high detailed secene after 3s.

4:2:2 + DOUBLED Q / T4 SETTING Firmware 1.47
Q: 256, 220, 200, 184
T: 4, 4,4, 4
Low detailed scene: 100 / 80 mbps  / Movie recording fails after a few seconds!
High detailed scene: 85 / 80 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: NO
Note: Fail

4:2:2 + 1.5 X Q / T4 SETTING Firmware 1.48
Q: 192, 165, 150, 138
T: 4, 4,4, 4
Low detailed scene: 100 / 55 mbps  / Movie OK
High detailed scene: 74 / 82 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: NO
Note: High detail better than with DOUBLED Q / T5
Real live scenes show 94 / 70 mbps

4:2:2 + 1.75 X Q / T4 SETTING Firmware 1.49
Q: 224, 192, 175, 161
T: 4, 4,4, 4
Low detailed scene: 100 / 72 mbps  / Movie OK
High detailed scene: 81 / 84 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: NO
Note: Similar to DOUBLED Q / T5 setting
Real live scenes show 85 - 97 quality

CONCLUSION
The table / quality relationship remains a mystery to me.
At the moment I use the 4:2:2 + 1.75 X Q / T4 SETTING without problems.

We would need a much better source image before the MJPEG compression to fully qualify such high compression quality settings. The video source image is quite soft and degraded because of the fast downsampling method (pixel binning?) used. The still photo source is much better downsampled.

Vitaliy Kiselev · Jun 25, 2010

I can only applaud to this testing work.

Martin Koch · Jun 26, 2010

More tests and still no clue.

Code:

4:2:2 + Paul Shields  SETTINGS Firmware 1.50
Q: 256, 256, 256, 256
T: 5, 5, 5, 5
Low detailed scene: 100 / 89 mbps  / Movie OK
High detailed scene: 82 / 100!!! mbps  / Movie recording failed after a few seconds
4:2:2 chroma subsampling
Playback in camera: NO
Note: 

4:2:2 + 128 / 5  SETTING Firmware 1.52
Q: 128, 128, 128, 128
T: 5, 5, 5, 5
Low detailed scene: 95 / 28 mbps  / Movie OK 
High detailed scene: 36 / 52 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: LOW: YES, HIGH: NO
Note: Bitrate choke is still active and seems to be implemented somewhere else

4:2:2 + 0 / 5  SETTING Firmware 1.53
Q: 0, 0, 0, 0
T: 5, 5, 5, 5
Camera refuses to record. Corrupted movie files on card. No thumbnail files
Note: Display shows 29 min 59 sec recording time (European PAL Limit)

4:2:2 + 10 / 5  SETTING Firmware 1.54
Q: 10, 10, 10, 10
T: 5, 5, 5, 5
Low detailed scene: 19 / 0.5 mbps  / Movie OK BUT VERY LOW QUALITY
High detailed scene: 19 / 0.5 mbps  / Movie is BLACK!!!
4:2:2 chroma subsampling
Playback in camera: LOW: YES, HIGH: NO
Note: Display shows 29 min 59 sec recording time 

4:2:2 + 256, 256, 220, 200 / 5  SETTING Firmware 1.55
Q: 256, 256, 220, 200
T: 5, 5, 5, 5
Low detailed scene: 100 / 83 mbps  / Movie OK
High detailed scene: 82 / 85 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: NO
Note: Display shows about 4 min recording time 

4:2:2 + 256, 256, 256, 220 / 5  SETTING Firmware 1.56
Q: 256, 256, 256, 220
T: 5, 5, 5, 5
Low detailed scene: 100 / 85 mbps  / Movie recording failed after a few seconds
High detailed scene: 82 / 85 mbps  / Movie recording failed after a few seconds
4:2:2 chroma subsampling
Playback in camera: NO
Note: Same tables but Movie recording failes after a few seconds

4:2:2 + 200 / 5  SETTING Firmware 1.57
Q: 200, 200, 200, 200
T: 5, 5, 5, 5
Low detailed scene: 98.15 / 56 mbps  / Movie OK
High detailed scene: “only” 69 / 77 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: NO
Note: Display shows about 5 min clip recording time
Should be a very stable setting


4:2:2 + 215 / 5  SETTING Firmware 1.58
Q: 215, 215, 215, 215
T: 5, 5, 5, 5
Low detailed scene: 98.32 / 77 mbps  / Movie OK
High detailed scene: 74 / 83 mbps  / Movie OK
4:2:2 chroma subsampling
Playback in camera: NO
Note: Display shows about 5 min clip recording time
Quantisation table of low detailed scene is filled with “Ones” and “Twos”
Quality 74 is nice for high detailed scenes

The last 4:2:2 + 215 / 5 SETTING should be a very stable setting for any Class 10 card
Tested with Film mode Smooth -2 -2 -2 -2, continuous autofocus (AFC) and 1/50 shutter speed. No problems. Real life scenes are around 70 mbps
To me this 720p MJPEG looks as good as 720p50 with "c" settings.

modulr · Jul 4, 2010

I understand this thread is aggressively moderated, but I wanted to post some findings that you may or may not find useful. I was unsure if testers really sift thru the noise on the main hack forum, so I'm providing a repost. Jpegsnoop is suggesting very high quality results.

Observations...

T = 1, resulting jpeg is roughly 1/4 complete.
T = 2, resulting jpeg is roughly 1/2 complete
T = 3, restulting jpeg is roughly 3/4 complete

As previously noted, using any tables 0-3 result in a quicktime which is black on playback. So obviously, T = 4 is the lowest setting that provides a completed and valid jpeg + mov. Might T have something to do with how the image is scanned? Anyway, I used this as my base point, as low T values always seem to perform well.

My initial goal was to figure out what quality settings could provide continuous playback on a Sandisk 8GB Extreme Class 10.

Q1=188, T1=4
Q2=188, T2=4
Q3=188, T3=4
Q4=188, T4=4

This resuted in recording of the star chart and real world examples with no errors at 75+mbps for complex scenes. There was still a fair degree of compression though, so I began to think about the logic of the system.

Q=188, T=4 for all stages 1-4 suggests the codec is always operating against the same threshold when dealing with it's variable bit rate. It suggests that for complex scenes, this is the max is can handle (on my card), however it leaves less complex scenes wanted more bits thrown at it. Odds are, the codec is constantly trying to get the most bits in there until there is a overflow and it must test the next lower Q level.

So what if we up the thresholds on Q1-Q3, and let Q4 be our last line of defense?

I came up with these settings...

Q1=400, T1 = 4
Q2=300, T2 = 4
Q3=250, T3 = 4
Q4=188, T3 = 4

The idea was to keep the thresholds very high (and throw more at simpler scenes), but if necessary back them down to the maximum my card could handle when a scene gets too complex. It seems like the codec is always trying to keep the threshold as high as possible.

Sorry for the lack of wonderful shots with flowers in bloom. It was gloomy outside morning, however I've tested these setting with complex natural scenes as well. Thus far, it's been working flawless.

Nostalgic Film Mode: Contrast -2, Sharpness -2, Saturation 0, Noise Reduction 0

----------

Precision=8 bits
Destination ID=0 (Luminance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=2.99 variance=6.13)
----
Precision=8 bits
Destination ID=1 (Chrominance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=1.54 variance=1.58)

Compression stats:
Compression Ratio: 5.13:1
Bits per pixel: 4.68:1

----------

Precision=8 bits
Destination ID=0 (Luminance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 2 2
DQT, Row #3: 1 1 1 1 1 2 2 2
DQT, Row #4: 1 1 1 1 2 2 1 3
DQT, Row #5: 1 1 1 2 2 2 2 2
DQT, Row #6: 1 2 2 2 2 3 2 2
DQT, Row #7: 2 2 2 2 3 3 2 2
Approx quality factor = 98.22 (scaling=3.57 variance=4.57)
----
Precision=8 bits
Destination ID=1 (Chrominance)
DQT, Row #0: 1 1 1 1 2 2 2 2
DQT, Row #1: 1 1 1 1 2 2 2 2
DQT, Row #2: 1 1 2 2 2 2 2 2
DQT, Row #3: 1 2 2 2 2 2 2 2
DQT, Row #4: 2 2 2 2 2 2 2 2
DQT, Row #5: 2 2 2 2 2 2 2 2
DQT, Row #6: 2 2 2 2 2 2 2 2
DQT, Row #7: 2 2 2 2 2 2 2 2
Approx quality factor = 98.80 (scaling=2.39 variance=0.91)

Compression stats:
Compression Ratio: 5.74:1
Bits per pixel: 4.18:1

----------

Precision=8 bits
Destination ID=0 (Luminance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=2.99 variance=6.13)
----
Precision=8 bits
Destination ID=1 (Chrominance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=1.54 variance=1.58)

Compression stats:
Compression Ratio: 5.93:1
Bits per pixel: 4.05:1

----------

Precision=8 bits
Destination ID=0 (Luminance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=2.99 variance=6.13)
----
Precision=8 bits
Destination ID=1 (Chrominance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=1.54 variance=1.58)

Compression stats:
Compression Ratio: 5.24:1
Bits per pixel: 4.58:1

----------

Precision=8 bits
Destination ID=0 (Luminance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=2.99 variance=6.13)
----
Precision=8 bits
Destination ID=1 (Chrominance)
DQT, Row #0: 1 1 1 1 1 1 1 1
DQT, Row #1: 1 1 1 1 1 1 1 1
DQT, Row #2: 1 1 1 1 1 1 1 1
DQT, Row #3: 1 1 1 1 1 1 1 1
DQT, Row #4: 1 1 1 1 1 1 1 1
DQT, Row #5: 1 1 1 1 1 1 1 1
DQT, Row #6: 1 1 1 1 1 1 1 1
DQT, Row #7: 1 1 1 1 1 1 1 1
Approx quality factor = 100.00 (scaling=1.54 variance=1.58)

Compression stats:
Compression Ratio: 8.01:1
Bits per pixel: 3.00:1

Martin Koch · Jul 4, 2010

FACTORY SETTINGS
Q: 128, 110, 100, 92
T: 133, 146, 150, 155
Low detailed scene: 83.09 / 0.6 mbps / PLAYBACK OK / MOVIE OK
High detailed scene: 19.16 / 36.15 mbps / PLAYBACK OK / MOVIE OK
4:2:0
Clip recording time display: 8m 20s

CUT AFTER E1
Q: 128, 110, 100, 92
T: 133, 146, 150, 155
Low detailed scene: 83.09 / 0.6 mbps / PLAYBACK OK / MOVIE OK
High detailed scene: 19.16 / 37.12 mbps / PLAYBACK OK / MOVIE OK
4:2:0
Clip recording time display: 8m 20s

Cut after E1 doesn't seem to have an effect.

Vitaliy Kiselev · Jul 4, 2010

Martin Koch said:
Cut after E1 doesn't seem to have an effect.

Try two other cut patches.
Main quality definition is E1, so testing must include really big changes in detail.

Martin Koch · Jul 4, 2010

CUT AFTER E2
Q: 128, 110, 100, 92
T: 133, 146, 150, 155
Low detailed scene: 83.09 / 0.6 mbps / PLAYBACK OK / MOVIE OK
High detailed scene: 19.16 / 37.34 mbps / PLAYBACK OK / MOVIE OK
4:2:0
Clip recording time display: 8m 20s

CUT AFTER E3
Q: 128, 110, 100, 92
T: 133, 146, 150, 155
Low detailed scene: 83.09 / 0.6 mbps / PLAYBACK OK / MOVIE OK
High detailed scene: 19.16 / 36.80 mbps / PLAYBACK OK / MOVIE OK
4:2:0
Clip recording time display: 8m 20s

CUT AFTER E1 Q400 / T4
Q: 400, (110, 100, 92)
T: 4, (146, 150, 155)
Low detailed scene: 100 / 64.08 mbps / PLAYBACK NO / MOVIE OK
High detailed scene: 96.39 / 180.28 mbps / PLAYBACK NO / MOVIE CANCELLED
4:2:0
Clip recording time display: 2m 39s

CUT AFTER E1 Q300 / T4
Q: 300, (110, 100, 92)
T: 4, (146, 150, 155)
Low detailed scene: 100 / 62.83 mbps / PLAYBACK NO / MOVIE OK
High detailed scene: 83.44 / 137.28 mbps / PLAYBACK NO / MOVIE CANCELLED
4:2:0
Clip recording time display: 3m33s

CUT AFTER E1 Q200 / T4
Q: 200, (110, 100, 92)
T: 4, (146, 150, 155)
Low detailed scene: 100 / 59.76 mbps / PLAYBACK NO / MOVIE OK
High detailed scene: 83.44 / 96.15 mbps / PLAYBACK NO / MOVIE OK
4:2:0
Clip recording time display: 5m 21s

Lpowell · Jul 6, 2010

Vitaliy Kiselev said:
Try two other cut patches.
Main quality definition is E1, so testing must include really big changes in detail.

Thanks for the new patches, Vitaliy. Can you give us a short technical description of what effect the new Cut after E1-3 have on the MJPEG encoder?

garhodes · Jul 14, 2010

A thought: I wonder if removing audio record from the firmware would allow for significant gains in image bitrate... I have noticed that increasing audio sampling will cause the camera to freeze up, perhaps the inverse is true-- dumping audio bitrate or removing audio record would free up bandwidth and processor in mjpeg...

park25 · Jul 17, 2010

billy fattey said:
When I first opened the .mov with JPEGsnoop it said, "NOTE: File did not start with JPEG marker. Consider using [Tools->Img Search Fwd] to locate embedded JPEG."

So I searched forward 2 or 3 times until it found a frame.

I think JPEGSnoop has found a thumbnail image recorded simultaneously by the GH1, not a frame inside the Mov file.

Deleting the jpg thumbnail file will support my doubt.

spamrakuen · Jul 25, 2010

Hi guys, I don't know if it will be useful (for you) or not, but I've made a small application for extracting JPGs from inside MOV files.

Application can be found here;
http://www.dvxuser.com/V6/showthread.php?t=217884

It uses direct stream copy, so no recompresion is done and it's very fast.

Eftegarie · Aug 2, 2010

Finding the Relationship between the MJPEG NUMBERS LOGIC on GH1 Hack project

Finding the Relationship between the MJPEG NUMBERS LOGIC on GH1 Hack project

Martin Koch said:
More tests and still no clue.

Dear Martin and other Pros,
Because many Pro's (including myself) don't have a clear clue to the EXACT working logic between the Quality and Table NUMBERS, I have started special interest in these eight numbers and hope to find the truth behind the relationship.

For this I have begged our "data expert" here in the office to take an alternative look into these numbers. He suggested to VISUALISE them as well as COMPARE them with at least 10 other good settings. From this he said, the logic will slowly appear... After comparing five favourite famous settings we stopped, so that you can reply what complementary good settings are missing.

These graphs SHOULD be seen SIDE BY SIDE, to compare them DIRECTLY:
1 * Martin Kochs Settings (famous for impeccable good tests, far edges)
2 * Pappas Settings (famous)
3 * Andrew Reid settings (famous artistis video, makes us forget the numbers)
4 * ModulR (pushing things to the far edge)
5 & Default Panasonic (most reliable yet)
6 -10 * ... need 5 more complementary good settings before continuation...

RESULTS SOFAR:
http://aster.nu/gh1.php

These graphs tend to show the RELATION or DISTANCE between Qx/Tx in relation to each other as well as the other three input terms. Bit complex to explain to newbies I guess. NEW graphs will be added in the current row of five, all in one clean clear and easy to find place, as soon as you have your reliable favourite settings, post that valuable data in here, and I will beg my colleage again to put it into visually representable graphs. After that we ill individually connect the ten settings graphs, with the uality and reliability outputs each of the settings.

I will keep coming back to this place reading your extreme quality data that still is reliable enough on class 10 cards.

Power to the people :thumbup:
Cheers, Eftegarie

crunchy · Aug 2, 2010

Have you mixed the numbers? Check graphs. I suppose that green and violet numbers should be the opposite as they are now. Since some numbers are very small (4) and other large it would be easier to draw them in logarithmic scale?!?

Edit: Are Martin Koch's and Panasonic's settings the same (according to graphs?)?

For example see attached log-scale graph.

Eftegarie · Aug 2, 2010

crunchy said:
...Since some numbers are very small (4) and other large....

Thats what we also thought, at first. But the experts have far far other ways of reasoning...
From what i understand the images should be right. I havent made them, some wise math nerds in the office figured it out during and some time after lunch. I put the question on their table, as a proud GH1 owner, and they asked for the stuff above. Our data analyst intern said that: If distance between the items is non-linear, then the amount is best visualised as a cross-relationship, in order to emphasize the Qx/Tx distances from each other. Also, the size of the balloons show their numeric content (so don't look at the heights of the balloons) 4 is small balloon, 250 is big ballon. From what i understand the RELATION is what we are after, NOT the exact numeric value in a linear or logarithmic or any other scale for that matter. THATS why the logic is so mysterious... we have to find out... Since tome use T=4 and some T=100, BOTH producing SAME high Mbit/s, that amkes your graph not valuable since the relation or distance between each Qx/Tx setting is not apparent, while it is THIS relation which is accountable for the quality differences, which in the end what we're after: HiDef lossless video...

Keep sending valuable data please Martin Koch and other testers, and don't waste your time, my time or our data analysts who are hungry for more data input by those who went to various extremes producing same high bitrate and reliability. it is THAT data that our data analyst wants.
Cheers!

Eftegarie · Aug 5, 2010

PROS: Be sure to check AVCHD as according to our quality tests (resolution+contrast in controlled environment) and motion tests (city life in uncontrolled and chancing weather environment with more or less constant speed of cars passing by) it seems that AVCHD is sharper than MJPEG though less smooth in motion!

We achieved AVCHD 61 mbit as averaged(!) output: visibly sharper than MJPEG.
Updating now our settings chart in my office (whenever boss is not around):
http://www.aster.nu/gh1.php

Cheers and happy filming.
Power to the People.

MJPEG Encoder Research, no questions here

Well-known member

Well-known member

Bronze Member

Active member

Well-known member

Well-known member

Bronze Member

Well-known member

Active member

Well-known member

Bronze Member

Well-known member

Veteran

Member

Member

Active member

New member

Well-known member

Attachments

New member

New member