Messages

Also, note that the Rec. 709 primaries are almost identical to the Rec. 601 ones (red and blue are identical and the green primary is only very very slightly different); the only problematic difference is the matrix.  (Before realising this, I spent two hours trying to work out how to use Rec. 709 primaries with the Rec. 601 colour matrix.)  Therefore, it should be fine to load a Canon MOV using "PC.601", i.e. Rec. 601 primaries and colour matrix, but full range levels (0-255).

That is how I load them in AviSynth.  FFMpegSource (aka FFMS2) seems to be good for this.  It even reports the colour space (FFCOLOR_SPACE) and the levels (FFCOLOR_RANGE) correctly; excellent for batch automation.  A word of warning though: FFMS v2.17 had problems with video artifacts on Canon MOVs, then v2.18 produced completely silent audio tracks!  However, the latest version, v2.19, seems to work OK now.

@ N / A :  I can't think why you would be getting rolling shadows with tungsten lighting.  Are you sure you don mean fluorescent / energy saving?  A tungsten light doesn't cool down sufficiently between the phases of the alternating current to cause a visible variation in light level, whereas fluorescent does.  In any case the frame rate shouldn't matter; it is the shutter speed that can cause problems, so try a shutter speed of 1/60 (for USA and 60Hz supplies) regardless of frame rate.

CBR 3.0x will fail/stop as soon as the picture becomes suitably complex

Sorry, I should have said: CBR 3.0x with GOP set at 3 or whatever GOP makes it most stable.  That would be interesting to compare, because it might not be significantly better than high CBR values with GOP, deblocking, etc, tweaked.

It goes Qscale (-16 to 16) - canon parameter then
Slice QP (several values at 1 qscale in CBR, usually 1 value at fixed qscale)
Frame QP (55-10) - depends on above. Slice from X-X is one step of QP.

So, are you saying you can adjust each of these three independently without changing the value of the other two?  I had been assuming that Qscale -16 to 16 was just part of the standard CQP 0-51 scale taken and rescaled to be over -16 to 16.  No?

0 or 1 or 2 should be huge but perfect.

lol, yeah, let's not go there.  You'd be way better off dumping raw 422 data by that point!

BTW, is A1ex's MJPEG any nearer public light?

Also - sorry if I'm missing something - people seem to be comparing the new encoding to the original FW at CBR 1.0x, but would it not be much more appropriate to be comparing it to CBR 3.0x / 2.0x or whatever the card can manage?  (We already know that CBR 2.0x is better than CBR 1.0x.)  Can people see a difference between the new encoding and "normal" CBR 3.0x?

@ 1% :  What confuses me is the difference between Q-value (which I'm assuming is effectively the same thing as quantiser value in x264) and this new "slice" value, which doesn't seem to exist in x264, or at least not as a user-settable value.  Can you explain the difference and why both values exist?  Can you change one without changing the other?

If slice is like Q-value, could we establish a "safe" value for a certain GOP, e.g. by incrementing the slice quality value and record TV static noise until it can't cope reliably, then using a value that was safe?  Of course this wouldn't give you the "best" quality for low-complexity scenes (since you could have pushed slice harder then), but I'm guessing they'd still look better than the firmware default, and you'd still have "best" quality for high-complexity scenes, where you most need it.  It would also give you your upper limit (or lower limit, whichever way you look at it), which you should never want to go beyond.

(Personally, I'm ultimately hoping to see a feature where I can use something vaguely equivalent to Constant Rate Factor in x264, where very high bitrates are available for complex scenes, without overrunning the buffer, but lower bitrates can automatically be used for low-complexity scenes/frames.  Whilst super-high bitrates may be useful sometimes, I won't want to use them all the time.)

Right, I have no idea why the forum decided to out this as a new topic – I just went to post on a thread and I suddenly appeared here...

Can't see any way to delete it.. 

@1% :  I still don't understand what this jpslice thing is or actually does, but could it be used to improve the quality of "normal" CBR encoding?  (ie encoding at CBR1.0-1.5x with GOP 12.)  Or do you need to drop the GOP to be able to improve jpslice at all?

Sorry for the tangent, but has anyone tested increasing the GOP to perhaps improve CBR 0.8x, etc?

In burst mode, there isn't any zooming though, is there?  It's only managing to write 2MB per second in silent frames to my camera when I use burst mode.

Seems so strange that it would waste processing encoding to jpeg and then decoding it to send it to the H264 encoder, unless it is somehow forced by the way their hardware is wired up and communicates.  If the jpcore part is already a bit compressed, maybe that can be written directly to the card bypassing x264.  We only need a 7:1 compression overall (or 4:1 compared to 4:2:2) to get 1080p down to being 20MB/s.

Sorry guys, I've just found I can already do this by using HDR with Intervalometer, but setting the exposure bracket to 0 EV.  I didn't realise there was a 0 EV option!

EDIT:  Sorry guys, I've just found I can already do this by using HDR with Intervalometer, but setting the exposure bracket to 0 EV.  I didn't realise there was a 0 EV option!

If I use Hi-Res Silent Picture with the Intervalometer then I have a problem if there is motion in the image, because the hi-res image is taken in panels that are out of sync with each other.  Even fast-moving clouds or blowing trees are a problem.  My solution to this would be to take several photos consecutively and average them, so it approximates one long shutter image.  This could also be used creatively, giving the effect of an ND filter.

In fact, why not have this as an option for "normal" silent images?  A pseudo-long-shutter option achieved by averaging several/many silent pictures?  You could also combine this with HDR, but it would be good to have it as an option without HDR.

Another time when multiple-shots intervalometer would be good is to be able to eliminate things from the scene, e.g. a timelapse of a beach, where a seagull flies across the scene or a child runs across.  If you have two images with them in different places in the frame, you can easily delete them with little effort.

I could actually see the following being useful personally:

Automatically take two photos consecutively (using continuous shutter), one at a wide aperture and one at a medium aperture (e.g. f/5.6).  If the focus is just slightly off on the wide aperture shot, then it will probably be fine in the medium aperture shot.  Other times, the medium aperture one may have too much noise due to high ISO, or motion blur due to a longer shutter speed.

Focus bracketing won't work with manual focus, whereas alternating aperture would.  With action you could use this with continuous shutter.

This could be used creatively too; I'm trying to imagine what would happen if you ramped between two apertures during a movie (whilst the ISO was automatically adjusted to maintain exposure)...  It could be quite cool to see the background magically blur, or come into focus, while the subject remains unchanged.

@1% : I think the "5x5" part only applies to Hi-Res.  If you select "Simple" it seems to completely ignore whether it is 5x5, 2x1, etc.  I just had a wee play with the options, and an 18MP Hi-Res 5x5 comes out at 34MB, so it does seem to be uncompressed with 4:2:2 subsampling – I got something muddled up before and thought the full-res pics were much smaller.

Can burst not be done at higher quality and faster?  With a UHS-1 Class 10 card, I only get 1.6 fps at only 1056x720 resolution.  If the H.264 encoder is getting 1080p (or are they 972p at this point?) .422, can these not be written directly to the card?  What's limiting?

So if the .422 files aren't compressed, and they are the "input" to the H.264 encoder, what is this jpcore slice qp setting that controls "input" quality, and why does it not seem to exist for x264?

Size of Simple 5x5 .422 is ~3mb

What is a "Simple 5x5"?

Has anyone seen any way of preventing the frames being upscaled from 1728x972 to 1080p.  I reckon that's not helping either.  It should also help with using micro-moire removal filters in post, etc.

Has anyone worked out why including audio, which is only 1.5 Mbps, and is completely uncompressed, has such a massive effect on the maximum video bitrate?  It seems really strange.

@1% : Why are you changing settings for slices?  Slices, AFAIK, are only used to help decoding on multi-thread decoders, which is qhy BluRay asks for 4 slices...  Increasing the number of slices decreases the quality, which is why the default is 0 in x264...

See http://forum.doom9.org/showthread.php?t=148826 (regarding BluRay compatibility):

With "Slices" they mean that each frame should consist of at least 4 slices (parts), that can be decoded/processed independently.

If a stream consists of several slices, this allows (but doesn't enforce) slice-level multi-threading.

So if an encoder relies on slice-level multi-threading, but the stream doesn't consist of several slices, that encoder will fail to decode the stream (at an acceptable speed).

I guess they included the "4 slices" requirement in the BD specs, because they wanted to make sure that even such decoders will be able to decode the BD streams.

Anyway, all the state-of-the-art H.264 decoders (ffmpeg-MT, CoreAVC, DivX H.264, etc.) use frame-level multi-treading and hence work with single-slice streams just fine.

It appears that also the hardware decoders used in "stand-alone" BD players are capable of decoding Level 4.1 H.264 streams without multiple slices.

Also it was found that slices reduce compressibility. In case of x264 the loss was around -0.1 PSNR for 4 slices (link). And: The more slices/threads, the bigger the loss!

Frame-based multi-threading not only gives more speed-up, also the loss in quality/compressibility is very small - even at high number of threads.


Or is it something else you're calling a "slice"?

Are the .422 files uncompressed 4:2:2 YUV (which is 16 bits per pixel, I think)?  It's just that they should be 4.15MB each if that's the case...

Uncompressed 8-bit YUV 1920x1080@25 FPS is around 103 MB/sec, MJPEG at 7:1 would give about 15MB/sec or 120 mbit/sec.

For 4:2:0 chroma subsampling, there are 12 bits per pixel.  That would give a bitrate of 1920*1080*25*12 = 622 Mbps, or 78 MB/s.

JPEG compression ratios are based on size before chroma subsampling, so for 15MB/s you'd need a compression ratio of 10:1, which would be quite feasible, and of course much less compression could be used.

4:2:2 video would certainly be nice!

What about getting silent picture video to work properly?  Those .422 files would presumably make a good video?  The main problem when I tried it months ago was that the .422 files often are a mixture of frames (eg top third is one frame, bottom two thirds the next), and there isn't audio.  Perhaps they could somehow be dumped into a .MOV (or any other file), along with audio, even if you had to use a special program on the PC afterwards to convert it into something useable...

I'd also be interested in a 550D-compatible build.  Perhaps with sharpness -1 added in too?

[I use TV static]

I use TV static to test reliability of different CBR values with different SD cards, with the camera on a tripod.  It's very repeatable and I figure it's about as complex as a scene can get.  Analogue TV is no longer broadcast in my area, so I can switch my TV to analogue tuner and select any station and I just get that snowy erratic static.  Horribly difficult to encode 

My set-up is:

• Set TV to detuned analogue static
• Mount camera on tripod ensuring it is perpendicular to centre of TV and at a distance where the static fills the whole frame.  (I always use the same lens, the 50mm f/1.8 for consistency.)
• Set ISO high (I've been using 3200 but 6400 might be better)
• Set aperture to something like f/8 to f/11 to ensure the picture will be crisp with as much detail as possible (but ensuring exposure is correct)
• Perhaps controversially, I set shutter speed higher than usual (1/100) because I think this should capture even more detail (less temporal motion blur) and be harder to encode
• Set PictureStyle (eg Neutral 0,-4,-2,0) and ensure HTP is off.  Probably should turn off ALO too but I haven't bothered.
• I keep audio on because I'll almost always want it on, even just as an emergency backup or for synching audio from my external recorder.  (Mostly I just have my external recorder plugged in and the quality's good enough.)
• I've been testing at 30 fps, on the basis that if it can do that it will be fine with 25 or 24, and 30 fps is sometimes useful to slow down action a bit or reduce the effect of camera shake.
• Lastly, but importantly, I ensure the focus is very accurate, by using live-view Contrast Detection AF rather than "fast" phase detection AF.

From this (with the December 2011 firmware) I established that my "Class 6" Verbatim card could only manage CBR 0.8x reliably.  My UDMA 1 SanDisk manages CBR 1.4x (with audio) and my Class 10 Transcend is variable, managing 1.1x sometimes and 1.3x other times depending when it was formatted.  Of course setting a lower GOP will probably improve these.

[the I/P ratio is how much it increases the *quantiser value* (not bitrate) for I-frames compared to P-frames.]

Unless I'm misunderstanding you, I think your "2 ways to stop the encoder" are the same thing:

If you encode at a certain quantiser (Q-scale value) then it uses as much bitrate as it needs to maintain a constant "quality" (amount of information loss) within that macroblock (16x16 part of the picture).  If not much is happening then it does not need much bitrate so you don't fill the buffer.  As soon as you present it with a complex scene it suddenly requires much more bitrate to maintain the quality.  Increased bitrate is caused my increased complexity.  Complex patterns, motion and noise (including high ISO) all contribute to increasing complexity.

I also wanted to clarify something about I/P ratio:  In x264, the I/P ratio is how much it increases the *quantiser value* (not bitrate) for I-frames compared to P-frames.

In x264, the quantiser runs from 0 (lossless encoding) to 51 (very poor quality), with 18-20 being sensible for DVD encoding and about 22 being used for 1080p BluRay encoding.  (Of course you would normally encode using a Constant Rate Factor (CRF) rather than a Constant Quantiser Parameter (CQP), which Canon DSLRs almost certainly use.)  Changing the CQP value by 1 usually affects filesize by about ~9%.  Therefore using CQP 17 is about 1.09 * 1.09 * 1.09 times bigger (about 1.3x bigger) than using CQP 20.  Canon is of course using its own scale (no surprise, lol) and the increments of Q-scale may be quite different.

Did you work out what D1 and D2 are?  Maybe they are values for the inter/intra luma quantisation deadzone?  If so, then lowering the threshold would likely improve fine detail considerably but increase bitrate.

See:  http://mewiki.project357.com/wiki/X264_Settings#deadzone-inter.2Fintra

In any case, I would think that all these parameters probably relate directly to parameters that x264 can take.  For example, GOP size is called "keyint" in x264.  Specifically, I wonder what your I and P parameters could be - you can't set the size of I & P frames (only the quantiser ratio).  Setting the GOP tells you when your I-frames are, so all your other frames must be P-frames (since there are no B-frames).

See this page for all the x264 options: 

http://mewiki.project357.com/wiki/X264_Settings

Right.  So if you use "CBR" but "lock" the quantiser at -16, will you not get exactly the same output as using Q-scale with quantiser at -16?  (And still set GOP, etc.) 

I think they should be exactly the same thing, and it would then make sense to call it a modified Q-scale rather than CBR.  (Unless I'm missing something?)  If this works with audio it would be really cool (not that it isn't already really cool ).

What would also be cool, in the future, is to have an option where you can set Q-scale and the firmware will automatically vary the I/P ratio to ensure the buffer doesn't overrun.  This would allow more efficient compression, than say using GOP 3 all the time, but still allow use of low quantisers, and not worrying about setting the GOP manually depending on the speed of each of your cards.  (Even if you have to leave a large margin of error, such as trying not to go above 20% full.)

@1% :  Where can I download your build?  The closest I could find after 15 minutes searching was:  https://bitbucket.org/hudson/magic-lantern/downloads

When you say it will only work at 24fps, is that only if I change the GOP or I/P frames stuff, or will it also not work properly at 25fps or 30fps even if I only change Q-scale values?

Would I be better compiling a more up to date version myself?

Ta.

If there is no way to smoothly adjust exposure whilst recording, how are others managing exposure changes during recording?  Just use Auto ISO when the exposure/lighting could change, or just let it be over/under exposed and correct it in post, or do they just jump the ISO and try to smooth it in post?  Ta.

Sorry to just drop into the conversation – I thought it better to just ask than start a new thread – but I'd like to experiment with using CBR whilst setting a maximum Q-scale value and a minimum Q-scale value.  Is there an easy way to do this?  (My programming ability is limited but not non-existent.)

My reasoning is:

• Perhaps setting a minimum quantiser (e.g. -8) will reduce buffer overruns whilst maintaining a good quality.  With some of my "Class 6" cards I currently have to use CBR 0.8x for reliability, but maybe I could get away with CBR 1.0x limited to -8.

• Perhaps I can establish a maximum quantiser, maybe something like 0, where I never get buffer overruns and could improve quality by using that as another limit.

While I'm asking, does anyone know if -16 to +16 are equivalent to certain CQP quantiser values in x264?

Thanks!

A1ex, are smooth changes in ISO currently available?

Sounds useful.  Is this in main release ML 2.3 or need to get a new build?  If it's in the main one, how do you access it?