Stable 35Mbps low-light MJPEG patch with in-camera playback

So I did some quick and dirty tests of the MJPEG changed to 24fps and couldn't see any real difference. Shot the same stuff as 30fps tests. No motion artifacts to my naked eye. Was very stable. Reads as straight 24 not 23.976. I think I will try it for awhile. Did notice bit rate dropped 5-7 Mbits (from mid-30's to 27-28 Mbits). This was expected but still looked as good as 30 fps stuff. Is it possible that with the additional bit rate headroom created by going to 24 fps, we could tweak lpowell's settings to get it back to the mid-30's range? lpowell? Anyone?
 
you sure you dont see dropped frames>?when this came up a few weeks ago,many said that its not real 24p because all it is was 30p with dropped frames...
 
35Mbps MJPEG in broad daylight

35Mbps MJPEG in broad daylight

While the 35Mbps MJPEG patch is explicitly tuned to optimize low-light video, it can produce high quality images in daylight as well. What seems to work best are well-lit scenes with bold, evenly-colored objects. Small, highly intricate details are likely to suffer from JPEG macro-block encoding, while large, cleanly-defined objects stand out beautifully. Here are several images to illustrate these principles.

Close-focus flower arrangement (36Mbps):
P1000673.jpg

400% magnification:
P1000673x4.jpg


Hillside scenery (32Mbps):
P1000678.jpg

400% magnification:
P1000678x4.jpg


LUX mausoleum (34Mbps):
P1000684.jpg

400% magnification:
P1000684x4.jpg
 
sammysammy said:
you sure you dont see dropped frames>?when this came up a few weeks ago,many said that its not real 24p because all it is was 30p with dropped frames...
Click to expand...

Hmmm, yeah I've heard that too. Dropped frames from what though? Is the camera recording 30 fps then dropping every fourth frame (at least that's what the Ptool pop up says)??? I put it on a Final Cut timeline and scrolled through it frame by frame. I didn't any jumps or skips in the shots, that would indicate missing frames, and this was with camera movement including pans and tilts. If it's there I couldn't see it. It's certainly not perceptible to my eyes when a clip is running normally. There was no audio drift either (though not sure there would be?). But then again I wouldn't call any of this definitive. I'm just not seeing anything unusual. I'm of the school that if you don't see it then it's not an issue (at least for me). Video is a visual medium and if you can't see a problem then who cares what's actually going on. Anything can be pixel-peeped to death and problems found. The only real problem I saw is that it's true 24P rather than 23.976 video.

As I mentioned it does seem to lower the overall bit rate. I would be curious if we adjusted lpowell's settings we could up the bit rate and improve what is already looking like a great set of stable settings for MJPEG. I'm asking lpowell or anyone else with the knowledge to take a look at it and see what they think. I haven't a clue how to adjust the MJPEG settings so am afraid I wouldn't be much help.

Cheers.
 
Cinesota, I modified my MJPEG patch to record 720p @ 24fps as you suggested. I also found an online stopwatch and recorded a video of its displayed millisecond counter (the "88" in the lower right corner):

Stopwatch-1.jpg


Then I imported the video into Premiere Pro in a 24p timeline, and stepped through the frames, one by one. Each frame displayed the elapsed count of the millisecond timer in the following sequence:

frame:.....00.....01.....02.....03.....04.....05.....06.....07.....08.....09
msecs:...088...121...156...189...221...289...322...356...388...455
elapsed:......33.....35.....33.....32.....68.....33.....34.....35.....67

Notice how the elapsed msecs between frames 4-5 and frames 8-9 is about twice the duration of the other frames? That's where the MJPEG encoder dropped a frame in order to chop its hard-wired 30fps rate down to 24fps...
 
Last edited:
Ah that is clever. Yep I see it. I like that your answers are simple and straight to the point.

Still is that perceptible to the human eye when played back at 24 fps? What would be the issues with those dropped frames? I ask because 24 fps is far more useful to me than 30 fps. I guess one could shoot 30 fps and conform to 24 but isn't that process the same thing the camera is doing? Neither seems to be a great solution. Don't want to derail your original posting but would be interested to know. Not much on the forum regarding this. Thanks for testing that by the way. Either way will keep using your settings for MJPEG going forward.

Any suggestions on what I might want to adjust my MJPEG settings to if I decided to stick with 24 fps?

Cheers.
 
Cinesota said:
I guess one could shoot 30 fps and conform to 24 but isn't that process the same thing the camera is doing? Neither seems to be a great solution.
Click to expand...
Yes, it's the same frame-dropping process, regardless of whether you do it inside the GH1 or with your video editor. If you must have 720p @ 23.976fps, you'd probably get better results shooting in AVCHD 720p @ 59.94fps and down-converting it in post. I've seen very good results using After Effects with its Motion Blur filter to convert 59.94fps video into 29.97fps.
 
35Mbps MJPEG daylight exposure tests

35Mbps MJPEG daylight exposure tests

Here are thumbnails of daylit videos taken at several levels of f-stop exposure, illustrating the amount of shadow and highlight details the 35Mbps MJPEG patch can capture.

F/5.6, 1/60 sec shutter speed, ISO 100:
F56_0661.jpg


F/2.8, 1/60 sec shutter speed, ISO 100:
F28_0663.jpg


F/11, 1/60 sec shutter speed, ISO 100:
F11_0662.jpg
 
I just loaded ipowell's settings. Three short (30s) clips worked just fine. I got a write error after 20s on the fourth clip. I started shooting the same shot again and it recorded fine for 2:30. I stopped it and played it back and got a read error after 20s. I pulled the battery turned it on and got write errors after 4s on every shot.

I am using sandisk extreme III, 14-140 kit lens. I was shooting at shutter of 4, aperture 4.0, iso 400. When I changed the shutter to 15, write errors did not happen until after 10s. When I bumped the shutter up to 30, write errors were gone.

I was shooting on a tripod. The shot was my gf on the couch. Nothing too high detail. The only changes to ipowell's settings were version increment and third party battery.
 
You may say, just don't shoot at 1/4. I would agree. I am used to live events using pro ENG type cameras where I shoot 1/60 all day. I was getting mud and banding above iso 400 with my gh1 so I thought I would experiment and the shot that I was getting the write error on actually looked really good despite the shutter effect.

I am also use to lower frame rates = lower bandwith, bitrate, file size etc. I thought it was worth noting that if I am getting errors at low shutter speeds, is this in any way related to the problem with 24pN? I was scratching my head with 24pN not working because my intuition would lead me to believe that if the cards are fast enough for 30P, than they are definitely fast enough for 24P.
 
don romolo said:
I was scratching my head with 24pN not working because my intuition would lead me to believe that if the cards are fast enough for 30P, than they are definitely fast enough for 24P.
Click to expand...

AFAIK, you cannot use 30P mode in 1920x1080 AVCHD mode. Did you mean 60i wrapper? In this case it's still similar, since original 24p footage is divided into smaller packages.
 
sorry, I should probably delete that last post (me thinking -- not very well -- out loud). Point was I got write errors on sandisk extreme III with lplowell's known stable mjpeg 720p 30p settings when I messed with the shutter. I don't know if this is documented or not.
 
I've used shutter speeds down to 1/30 sec with the 35Mbps MJPEG In-Camera Playback patch with no errors. Below this shutter speed, my understanding is that the camera will cut its sensor frame sampling rate in half to 15fps in order to hold the shutter open for longer than 1/30 sec. The video will still contain 30fps, but each frame will be doubled after being sampled at 15fps. Since I've not tested it myself, it's quite possible that this altered frame sampling rate could produce SD card write errors with the 35Mbps patch.
 
Hi LPowell, I'm looking for a patch which allows me to play back my recorded mjpeg-videos in camera.
This Patch here seems to be the best choice.
But also I'd like to use a higher resolution than 720p.
But the anamorphic 1920x810 mjpeg patch cannot be played back in camera, if I've understood everything right.

So I'm wondering if it might be possible to combine this 35mbps low-light mjpeg-Patch with the 1920x810 resolution settings? Or would it be senseless because of the lower bitrate, which makes the higher resolution worthless?


Hope you could understand me, English is not my native language :)

Greetings,
Tobi

edit/ using a gh1, btw
 
Last edited:
faultiersid said:
I'm wondering if it might be possible to combine this 35mbps low-light mjpeg-Patch with the 1920x810 resolution settings?
Click to expand...
Yes, you can set the 1920x810 anamorphic resolution on the 35Mbps MJPEG patch and it will play back in camera! (There is a momentary visual glitch when playback starts, but the video itself is not corrupted.) The only drawback, as you suspected, is that the lower bitrate does not produce as high an image quality as my 65Mbps MJPEG patch. While 35Mbps is excellent for 1280x720 videos, the widescreen 1920x810 frame uses a lot more bits.
 
Ipowell's low light 35 Mbps settings work great for me. I have tested with the lowest shutter speeds noting zero errors.

I also found that the .MOV files obtained look decent when remuxed to MP4 (H.264 super high). Resulting MP4 files suffer relatively minimal loss of image fidelity compared to original .MOV, even at high magnification, yet are significantly more compressed.

Kudos to Ipowell.

Example 01 (MOV) : http://www.youtube.com/watch?v=jhpGIrmQAvE&hd=1
Example 01 (MP4) : http://www.youtube.com/watch?v=JGT53QXMw38&hd=1

Example 02 (MOV) : http://www.youtube.com/watch?v=WVNk4Mxi3Og&hd=1
Example 02 (MP4) : http://www.youtube.com/watch?v=sePe5i-xZYE&hd=1

(Original files offer better comparison through common BS.Player)
 
bullocks!!! the lpowell - Reliable In-Camera Playback Patch.zip doesnt work on Mac OS.. the unknown file is called setj.ini (4k) u are supposed to unzip it onto your ptool folder whetever that may be after using winebottler!! anyway cant wait to get it sorted tomorrow with my mates PC.. =D
 
Last edited:
Perrona said:
...the lpowell - Reliable In-Camera Playback Patch.zip doesnt work on Mac OS...
Click to expand...
Sorry about the unfriendliness of the Mac OS to PC utilities. As a workaround, if you use a text editor to open the setj.ini file, you'll be able to read the patch settings and enter them directly into PTool.
 
Lumix GF-1: Stripes on video induced by fluorescent lighting

Lumix GF-1: Stripes on video induced by fluorescent lighting

I've been using lpowell's settings for several months now and I've found them to be quite good. However, I've also been suffering with strange horizontal stripes on my video. Being fed up with it, I conducted a test today for about an hour. My tests show that strong fluorescent lighting causes it. It does not happen with natural light. Furthermore, fluorescent lights that are labeled "natural light" (they tend to be warmer in color) make the problem much worse. And in mixed lighting situations, especially in scenes of high contrast, the resulting video is almost unusable it's so bad.

Here are some examples of video and photos I've taken:

http://www.youtube.com/watch?v=CiZnA1RnrkM
http://www.flickr.com/photos/66071596@N00/5596989648/

The stripes are always horizontal (from left to right when viewing the screen on the GF1 normally -- widescreen). So if you flip the camera 90 degrees, the stripes flip 90 degrees too.

I tried changing many different settings, including white balance and ISO. In fact I don't think there was a setting I didn't change today! But nothing helps except changing the light source. But sadly, and especially here in Japan, you cannot always escape fluorescent lighting, nor can you escape mixed lighting situations where fluorescent lights are used inside, and you are shooting inside, yet there is sunlight entering from multiple windows. It wreaks havoc on the video.

Furthermore, as you can see in my example video, the stripes don't stay fixed. The move slowly up the screen, almost like when you video an old CRT TV and the refresh is out of sync with the camera. The stripes are mostly Yellow in color, but sometimes there are other colors too, like Magenta, which you can see in my example video.

I simply cannot believe that I am the lone GF-1 user on the planet who has experienced this. Therefore, I am posting here in hopes of hearing the experiences of others, curious to know what is causing it and if there is a fix.

Thank you.


lpowell said:
With the following settings I've optimized MJPEG encoding to produce a stable bitrate of 35Mbps across a broad range of illumination, from dim incandescence to shaded daylight. I've found this to be close to the highest MJPEG bitrate that can be reliably played back in-camera:

  • MJPEG E1 Quality = 150
  • MJPEG E1 Table = 86
  • MJPEG E2 Quality = 130
  • MJPEG E2 Table = 56
  • MJPEG E3 Quality = 115
  • MJPEG E3 Table = 26
  • MJPEG E4 Quality = 100
  • MJPEG E4 Table = 4

These settings work at the standard 720p/30fps MJPEG rate with the enhanced 4:2:2 color patch. I've recorded dozens of test videos on both Class 6 Transend and Class 10 SanDisk 16Gb SD cards without error.

I've published an easily installable settings file, combining my 40Mbps AVCHD High Reliability Patch with my 35Mbps MJPEG In-Camera Playback Patch, in the pinned Settings Sharing thread:

http://www.dvxuser.com/V6/showpost.p...80&postcount=5
Click to expand...
 
You must log in or register to reply here.
Back
Top