Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
GH2 - MJPEG resolution findings and Myth Busting
  • 54 Replies sorted by
  • @duartix My hunch has been that E1/F1 pushes Q chrominance and E4/F4 pushes Q luminance. Lessen the table values for better Quantisation (closer to 0 is better quality low compression but requires more bitrate in Quality setting, higher table values = higher compression, poorer quality but uses less bitrate).

    Judge allocating bitrate in the quality settings according to how low your tables go. Too high on the Quality bitrate/low on the tables will hinder recordings/stop them prematurely.

    Use jpegsnoop to look at the jpegs produced (does a first frame snapshot when you first hit record) in the DCIM Folder to judge how your settings should look in terms of chroma/luma/quant - as in the tables you posted above.

    If your recording never gets past the snapshot youre using too low a table setting/too high a Quality setting!

    See some of the Quantum patches for an indication of measured quality/table settings.

    Hope this helps any mjpeg testers.

  • Okay lets see... AVCHD has much better Luma/Y resolution, and 1080p MJPEG has much better U and V resolution than AVCHD (so this may be the go for green screen).

    Working through the rest of the image set now.

    Can't spot a luma difference for MJPEG @ 2048x864 resized to 1920x1080 vs 1080p MJPEG, but 1080p MJPEG has slightly finer (hard to spot) U and V.

    Pulling up a 1080p MJPEG frame to 2048x1152 and the 2048x864 up to 2048x1152 (so nothing is thrown out from either). the 1080p frame is better due to better U and V. 2048x864 is a touch better horizontally in Y. I didn't take a 2048x1152 'native' shot to compare.

  • @Athiril: That's what I meant when I said "losslessly transform", I just changed the container to AVI.

    @driftwood: Thanks for the heading, but...

    @all: For the time being, I declare an IQ tie between AVCHD and MJPEG 2048x864. Please disregard my previous comments (I'll be editing them out) about bigger contrast on MJPEG and more color grading leeway on AVCHD, there must have been a color transformation error in my screen grabbing workflow.


    Pictures are similar when it comes to color after all, sorry!

  • I'm going to upload these images (may take a while).

    AVCHD has a clear resolution/detail lead. MJPEG however has significantly better U and V. I also took an "ideal" 1080p shot (RAW still, 16:9, down sized to 1920x1080) - Y, U, and V are all crystal clear and as much info as you can possibly store in a 1920x1080 RGB or 4:4:4 frame.

    The MJPEG U and V frame come no where it's U and V frames, and of course look quite jaggy, but much better than AVCHD. Yet no where near the ideal RGB/4:4:4 frame (which I made from a RAW still, extacrted YUV compoments and downsized to 1920x1080).

    Meaning sub-sampling is much worse on AVCHD than MJPEG, yet MJPEG is no where near ideal, so AVCHD by deduction is much less than 4:2:0.

  • If my interpretation of JPEGSnoop's output is correct and going by this: then this particular case of MJPEG could be 4:1:1.

    Is that possible? The same wiki notes MJPEG as using 4:2:0.

  • I'll upload a PSD with all the layers of the diff images from this test, think that might be less work for me :P

    Anyway, here's a quick gander

    AVCHD U component:


    MJPEG 1080p U component:


    Ideal 1080p U component:


    This half/2 U component is still legible for much of it, MJPEG is not legible, but is still significantly better than AVCHD which is just a smear.

    Now while you may say of course MJPEG will do better in YUV, since it's stored in YUV (iirc), and AVCHD Y'CbrCr, that doesn't matter, as the Y vs Y' component are still basically full resolution greyscale images, and the remaining two components colour differentiation, if -both- U and V are significantly better on MJPEG, if I converted AVCHD and MJPEG to Y'CbCr components, the same difference should still be seen.

    Perhaps 4:2:0 YUV (if that's how MJPEG is being stored) has an advantage over 4:2:0 Y'CbCr, I seriously doubt it, but in any case, even though MJPEG is winning here, even it doesn't look like 4:2:0 at all, but much less (at least for the 2 part).

    Ideal 1080p U component reduced to 1/4 resolution (half linear resolution, ie: 4:2:x):


  • Going by just the pixelation, I'd say it's 1/8th the resolution and don't forget that on top of that, it needs to be quantized (which could be much harder to simulate)!

  • Haven't replied in a while due to suddenly having no internet at home (no idea what's happening with it, in housemate's name).

  • Well, it's better then your LARGE DATA HDD dying on you... It's been a painful weekend. :(

  • I see some of the patches have MJPEG at 2K, 2048x1152. What is the maximum X and Y values (2048x1152) can be raised, and/or is there a point you go beyond and upscaling occurs? Thanks

  • @WhiteRabbit:

    One pill makes you larger

    And one pill makes you small

    And the ones that mother gives you

    Don't do anything at all

    Go with me: it's the magic pill or nothing: 2048x864.

  • @duratix I saw Alice sitting on the bank of the river. I approached and offered her a blue or red pill, and explained the consequences thereof. Alice chose, then followed me down the rabbit hole.

    My question, which remains unanswered, maximum X and Y values, pertains to some future tests I may experiment with adjusting a patch. I use an anamorphic front lens, and it is not a typical ratio, being 1.75x or there abouts, whereas many others are traditional 2x, 1.33x and even some 1.5x. When capturing to 16:9 with a 2x anamorphic, say at 1080p, you can not extract 2.39:1, resulting in something around 3.55:1 when you transform the height down, making the footage extremely wide screen. If you can capture to 4:3 sensor, a 2x anamorphic results in 2.66:1 and you lose some of the sides bringing it back to 2.39:1, and a 2K source (2048x1152) is less than 1920 wide after this process to result in 2.39:1, resulting in some upscaling.

    I agree, your formula is a good direction to head, however, does this apply to anamorphic users? My question remains, the maximum X and/or Y values before the GH2 starts upscaling? @duratix, thank you for your interest and reply. I will test your settings soon.

  • @whiterabbit: I can't provide evidence, but from what I've gathered, 2048x864 is the top of the line. Many people have reported trying superior resolutions but the resulting image is of very poor quality not even compatible with FHD upscaling. From memory I'd say sometimes it's as soft or even softer than 720p.

  • @WhiteRabbit Its all about balancing quality with res size. The bigger the rez the lower values for E1 to E4 etc... you'll have to make it to work. The 2k sized mjpeg patches in most of the latest Driftwood settings (which are the same) maximise the bandwidth available and provide the best quality mjpeg settings Ive seen.

  • @driftwood : thank you for your reply. I had posted a question in the Low Rider thread regarding MJPEG and the resulting pixel aspect ratio of the recordings. I changed the Low Rider default MJPEG 1920x1080 (which records vertical stretched footage, I assume 2x for anamorphic users?) to @duartix suggested 2048x864 parameters, which, when using a non-anamorphic lens produced footage that appeared closer to normal 1:1 ratio (closer) when viewed with QT player. I might be wrong, however the stretch appear less, or I am to tired to interprete this at the moment.

    Does PTool have locked off pixel aspect ratio, or can this be modified from your patch build or is there another I way I can control this and/or enter my own specific values?

    It is late here, I will investigate further tomorrow, and try a different Intra patch with your 2K MJPEG and see what aspect ratio the footage provides, then actually check it out in an editing app, not just QT player.

  • @WhiteRabbit: I suggest you change both these settings to the resolutions you wish to test:

    720p30 width=1920

    720p30 height=1080

    480p30 width=1280

    480p30 height=720

    This way you change modes on the camera and test and compare 2 different resolutions at a time without repatching. ;)

    Happy hunting.

  • But has anyone tried higher resolutions? For example 3840x2160? You could maybe try 2488 * 1400, a friend suggested that it would be the ideal resolution for this system ..

    I do not know, maybe there's the risk of asking stupid questions, but maybe keeping compression values ​​to their original levels, you can push up the resolution .. or not? Certainly, the moiré in mjpeg is evident.

    I also wanted to ask, has anyone tried to extend the fps from 30 to 60 in mjpeg mode?


  • Higher FPS will not work. Optimum resolution question is answered by Driftwood 3 posts above. Guess you can change values to your need as long as you ruffly stay at the same amount of pixels and don't exeed 2048.

  • Back when I did this, I got 4K in MJPEG @ 2fps iirc to work on my card.

    Luminnance Resolution did not improve (AVCHD still a fair bit better), but U and V resolution did significantly.

  • This sounds quite interesting! Would you mind sharing the setting?

  • So: you can.

    Which card did you use? The best?

  • I've been following this thread with interest for awhile and I have some questions. I know that Driftwood is using 2048x1152 for his mjpg settings and even though I turned off the 1080p in mjpg to force 720p, I've decided to try his 1080p formula ratio to hopefully maximize 720p resolution. I divided 1920 into 2048, then multiplied that number times 1280 and 720 to get 1365.33x768. I rounded to 1365x768 and without frame grabs, yet, my initial/gut observation is that yes there seems to be an increase in resolution. Should I be rounding to 1366x768 instead? Also, @duartix, this is off topic, but is there a way to overcome the 4gb limit that I've ran into using 2fps in mjpg?

  • @coors: None that I know of. I suppose it's a FAT32 limit that can't be cornered around. AVCHD does it by spanning across multiple files, something MJPEG wasn't designed to do...

  • 2 fps was the fastest I could get it to work on my Transcend Class 10 32gb and my Sandisk Class 10 32gb UHS-I 45mb/sec.

    It was for investigative purposes to gain information about chroma sub-sampling. I am sure it is tied to the specified resolution as a variable in the processing pipeline somewhere.

    I can't remember the settings exactly it was a long time ago, but probably 4096x2304 for res setting. And I'm waiting on a new charger for my GH2 (orig battery only, and flat, left charger behind somewhere else :/) so I can't re-explore it right yet, I've got the DC-coupler kit, but can't update firmware on that I think.

  • @duartix Thanks, very much, for your reply! I'd definitely like to give your setting a go but unfortunately I'm stuck in GF2-land, for now.